- Inkscape Devel - Inkscape Mailman

MediaWiki skin
by Krzysztof Kosiński 17 Dec '10

17 Dec '10

Hello Can we please change the MediaWiki skin used on wiki.inkscape.org to the default, as seen on Wikipedia, but with our logo? The current one is no good and it would be more work fixing it than writing a better one from scratch. I know there is a website redesign in progress, but this is a simple change that would immediately improve the lives of wiki users. Here's how to do this. http://www.mediawiki.org/wiki/Manual:Skin_configuration Regards, Krzysztof

1 0

sp-color-wheel-selector.cpp:138:22: error: missing binary operator before token "(", inkscape trunk@...2518...
by Jeff Kowalczyk 17 Dec '10

17 Dec '10

I get the following compile error with inkscape trunk rev 9964: CXX widgets/sp-color-wheel-selector.o widgets/sp-color-wheel-selector.cpp:138:22: error: missing binary operator before token "(" widgets/sp-color-wheel-selector.cpp:223:22: error: missing binary operator before token "(" widgets/sp-color-wheel-selector.cpp: In function ‘void resizeHSVWheel(GtkHSV*, GtkAllocation*)’: widgets/sp-color-wheel-selector.cpp:135:42: error: ‘gtk_hsv_set_metrics’ was not declared in this scope widgets/sp-color-wheel-selector.cpp: In member function ‘virtual void ColorWheelSelector::init()’: widgets/sp-color-wheel-selector.cpp:169:26: error: ‘gtk_hsv_new’ was not declared in this scope widgets/sp-color-wheel-selector.cpp:170:40: error: ‘GTK_HSV’ was not declared in this scope widgets/sp-color-wheel-selector.cpp:170:49: error: ‘gtk_hsv_set_metrics’ was not declared in this scope widgets/sp-color-wheel-selector.cpp: In member function ‘virtual void ColorWheelSelector::_colorChanged()’: widgets/sp-color-wheel-selector.cpp:275:82: error: ‘gtk_rgb_to_hsv’ was not declared in this scope widgets/sp-color-wheel-selector.cpp:276:42: error: ‘GTK_HSV’ was not declared in this scope widgets/sp-color-wheel-selector.cpp:276:53: error: ‘gtk_hsv_set_color’ was not declared in this scope widgets/sp-color-wheel-selector.cpp: In static member function ‘static void ColorWheelSelector::_wheelChanged(GtkHSV*, SPColorWheelSelector*)’: widgets/sp-color-wheel-selector.cpp:351:40: error: ‘gtk_hsv_get_color’ was not declared in this scope widgets/sp-color-wheel-selector.cpp:356:39: error: ‘gtk_hsv_to_rgb’ was not declared in this scope widgets/sp-color-wheel-selector.cpp:367:94: error: ‘gtk_hsv_is_adjusting’ was not declared in this scope I'm using Gentoo Linux ~amd64, let me know if there are any dependency versions you need to know. Thanks, Jeff

1 0

Merry xmas + InkViewer as previewer?
by Mark T 17 Dec '10

17 Dec '10

All the best for your seasonal festivities. Especially those enduring the norther climes. WIn-users are a phussy lot. When introducing them to a new graphics program where there is not preview, the impact is low. Is there a path of possibility of the InkViewer being used as a preview.er in a Windows explorer preview pane? Renesis domain has expired. They did produce a previewer. MarkT -- (+61 4) 0679 5734 :: skype: govirtual.com.au :: チェックアウトが、Jingle だ! ::It's a Jingle Out There!

1 0

0.48.1 release notes
by Krzysztof Kosiński 17 Dec '10

17 Dec '10

Hello I started the 0.48.1 release notes page, available here: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48.1 Regards, Krzysztof

3 2

irc bot
by john cliff 15 Dec '10

15 Dec '10

anyone know whats going on with the irc bot in the jabber room? Cheers John

1 0

Fwd: [Press] PRESS RELEASE: Framework 0.7 is Faster and Open Clip Art 2.8 Goes Creative Commons Zero
by jon＠...235... 15 Dec '10

15 Dec '10

Hi guys, just let you know we making great progress on Open Clip Art Library these days and also plowing on its engine. Its a great time to come help out! Jon ---------- Forwarded message ---------- From: Jon Phillips <press@...2474...> Date: Wed, Dec 15, 2010 at 12:15 PM Subject: Fwd: [Press] PRESS RELEASE: Framework 0.7 is Faster and Open Clip Art 2.8 Goes Creative Commons Zero To: clipart-list <clipart@...330...> Ok, cool, spread the word! We got the release out! ### San Francisco, December 15, 2010 UTC – Aiki Framework (http://aikiframework.org) is ending 2010 on a series of high notes that make up it's latest Release of Version 0.7. Lead Aiki Developer, Bassel Safadi (http://bassel.ws), along with fellow Fabricatorz (http://fabricatorz.com/about) have spent a month leading to the upgrade pushing revisions, planning Aiki's future, and deploying new features to Aiki's growing list of sites. Aiki Framework is a leading open source, web-based content management system. Version 0.7 is marked by a number of enhancements to the package, including revamps of core elements by Aiki Developer, Roger Martin (http://rg1024.wordpress.com). As a result, Aiki processing speed has been supercharged. Bassel has also been working tirelessly to enhance existing features while also killing bugs to improve user experience in the admin panel, as well as allowing developers greater control of the sites they build on the platform. Aiki's flagship site, The Open Clip Art Library (http://openclipart.org), has seen a month of growth and renewed focus on future goals for the project. Open Clip Art Library 2.8 brings over 1,000 new and remixed images into the Public Domain. Going even further to solidify OCAL as a leading provider of Open Source Content, registered users have grown by an astonishing 2,500 since November 1. The ever-expanding Community of artists continues to deliver solid themed content, as the latest Package Release brings a collection of over 75 Winter Holidays 2010 Clip Art (http://www.openclipart.org/packages-holidays2010). This release also sees the update of the site to use Creative Commons updated CC Zero Public Domain Dedication tool. The goal of this tool is to work internationally and take into account concerns by those living in jurisdictions around the world that have other types of rights around the creation of a work. By visiting the site, one will notice now all references to waiving copyright on clip art contributions are using this tool. Fabricatorz and Open Clip Art Library founder Jon Phillips stated, "Open Clip Art Library is used all around the world by Wikipedia, teachers, artists, and plain old Mom's as a key source for graphics. By updating our licensing tool, we are in compliance with the latest Creative Commons recommendation for releasing works into the public domain globally, and leading on the net with trying to increase sharing. This type of sharism is crucial to the open web." Beyond licensing, a new "Collections" system has also been launched. Registered OCAL members now have the ability to aggregate their favorite clip art into created lists. Each created list will appear on the user's profile page. This is only a first step in a larger plan for "Collections", so users are encouraged to test out this feature and report any bugs. Profile editing continues growing more robust and usable, thanks to OCAL Developer Chovynz (http://www.openclipart.org/user-detail/chovynz). Users now have access to their profile by simply selecting their username in the header. Selecting the re-worded 'My Profile' will now lead users to their management page. Improving usability even further, Bassel has invoked "pretty urls" for all clip art uploaded to Open Clip Art Library. With these new updates in place, the Librarians want to open the floodgates for Community involvement. Developers will be pleased to learn that a major behind-the-scenes update has taken place, and The Open Clip Art Library is now backed by the latest Version of Aiki Framework. On top of that, Framework auto-updates are in place, so OCAL will always be on the cutting edge as Aiki rockets toward the future. The Open Clip Art Library's progression has been mapped out on Launchpad (http://launchpad.net/openclipart). Here, users can learn where OCAL is heading and how they can help. All are encouraged to file any suggestions and bugs they find while utilizing The Open Clip Art Library, as well as helping to fix existing issues. Any who are unsure of how best to help are welcome to get started by logging into OCAL's irc chat (#openclipart at freenode.net). The invitation to contribute extends to Aiki Framework, whose future is also mapped out on Launchpad (http://launchpad.net/aikiframework). Aiki's Developers welcome feature requests and bug filing. For those just beginning their Aiki Framework adventure, online documentation is in place (http://www.aikiframework.org/wiki/Main_Page#Documentation) and is continually being updated with definitions, tutorials, and latest feature breakdowns. Aiki's irc channel (#aiki at freenode.net) is also a great place to ask questions and learn from those who are doing. Get started and be a part of a powerful and Open future. Highlights * Aiki Framework 0.7 Release * Faster processing & bug fixes * New Open Clip Art Library 2.8 Release * 2,500+ new registered users last month * Winter Holidays 2010 Clip Art Package Release * Call for Aiki Framework & Open Clip Art Library Developers For more information * http://aikiframework.org * http://openclipart.org * http://fabricatorz.com * http://en.wikipedia.org/wiki/Open_Clip_Art_Library * http://www.facebook.com/pages/Open-Clip-Art-Library/345650985985 * http://aikilab.org Press Contact Jon Phillips press@...2474... +1.415.830.3884 San Francisco + China _______________________________________________ Press mailing list Press@...2475... http://lists.fabricatorz.com/listinfo.cgi/press-fabricatorz.com -- Jon Phillips http://rejon.org/ http://fabricatorz.com/ http://status.net/ http://rejon.status.net + skype: kidproto +1.415.830.3884 (sf/global) +86.187.1003.9974 (china) -- Jon Phillips http://rejon.org/ http://fabricatorz.com/ chat/skype: kidproto | irc: rejon +1.415.830.3884 (sf/global) +86.187.1003.9974 (china) +65.8330.5807 (singapore)

1 0

Abhishek's "refactoring" (r9946) makes things much worse
by Krzysztof Kosiński 15 Dec '10

15 Dec '10

Hello The object of the C++ refactoring GSoC project by Abhishek was to better separate the object tree (interpretation) and the XML tree (representation). But the recent merge of his work made it clear that he potentially made things much worse! Abhishek's patch introduces these functions: void attach(SPObject *object, SPObject *prev); void reorder(SPObject *prev); void detach(SPObject *object); long long int getIntAttribute(char const *key, long long int def); unsigned getPosition(); gchar const * getAttribute(gchar const *name,SPException *ex=0) const; void appendChild(Inkscape::XML::Node *child); void addChild(Inkscape::XML::Node *child,Inkscape::XML::Node *prev=0); void setKeyValue(unsigned int key, gchar const *value); void setAttribute(gchar const *key, gchar const *value, SPException *ex=0); void readAttr(gchar const *key); void removeAttribute(gchar const *key, SPException *ex=0); bool storeAsDouble( gchar const *key, double *val ) const; All of those are public and operate directly on the XML tree - exactly the type of operation that the project was supposed to reduce! What do we do now? At the least, all the functions listed above should be made private. Regards, Krzysztof

6 20

[website] website structure
by Ian Caldwell 15 Dec '10

15 Dec '10

Hello, Also send on behalf of "Steven M. Ottens" Hi all, I've been pondering the site structure using the three focus groups, while keeping in mind that our audience is diverse and groups overlap. To put it simply: New users want to: -know what inkscape is -get it -know how to get started Existing users want to: -get new versions of inkscape -get add-ons -learn how to use it -get involved (user/designer style) -get the latest news Developers want to: -get source code -learn how to develop -get involved (developer style) -get the latest news Note that all three groups want to 'get something', all three want to know/learn something and two want to get involved somehow and get updated with the latest news. Also getting involved means different things to different people. Also the current distinction between developers and community is not entirely valid in my opinion. For a starter, developers are a part of the community :) Also bugtracking is both important for users and developers. In stead of focussing on the different target groups, I'd like to focus on the different activities. When someone visits the site, (s)he will not first think of him/herself as a developer, user, etc. (S)he will have a specific need which (s)he wants to be met. So instead of forcing visitors to think which role they fit, I'd like to meet their questions head on. So my suggestion is to make these 6 toplevels for the menustructure: -*about* (which should meet questions on what it is, who work on/with it, what can you do with it, what can it do) -*downloads* (which should answer all questions relating getting inkscape and related resources) -*learn* (which should answer questions on how to get started, use it and develop for it) -*get* *involved* (which should answer questions on how to get involved in all possible ways) -*news* (which should show what's happening in the community, the development, the wiki) -*donate* (which should bring us money ;) The frontpage should apart from the 6 menu-items provide a direct link to the download which is appropriate for the visitors OS and underneath an 'other version link' which links to the main downloads page, similar to firefox approach. Also it should provide direct access to 'overview' 'features' 'gallery' 'getting started/learning resources' and show the latest news. This probably leaves us some space to be filled on the frontpage. I've not yet come up with appropriate extra content, so if there are any suggestions, please let me know. One question I have is the integration of the wiki within the main site. Obviously being a wiki, we cannot or should not force the same structure as the site. Though different parts of the wiki are interesting in different places in the menu structure. It would be good if we create and link to main wikipages on different subjects. For instance wiki/learn as a starting page for all learning-related wikicontent. This way we can integrate the wiki more into the main site. The rest of the menu structure would then look something like this (note that it is most likely not complete, I'm typing this on the move so don't have access to the website and wiki to check for missing bits): ABOUT -overview -screenshots -gallery -cases -features -supporters/sponsors (?) DOWNLOADS -windows -linux -mac -other -source -addons (palettes, plugins etc) -open clip art (extern) LEARN -books -tutorials -videos -FAQ -wiki/learn -dev docs -user docs GET INVOLVED -forums -mailinglist -bugtracker -irc/jabber -wiki -roadmap -developer -designer NEWS -news -releases -contests -meetings -wiki/recent DONATE (nothing under here, just a direct link to the donations page) I am aware this structure is quite different from the current and as such it might take quite some effort to relocate current content in the new structure. As stated before I haven't looked to each individual page in the current site and checked if it has a proper place in the new structure. I haven't thought very hard and deep on how to integrate the wiki into the main site, other than the linking in the menu, this might need some more thought. Also it is a proposal so I'm open for feedback, comments and improvements. Regards, Steven

2 1

Re: [Inkscape-devel] Embed Python script engine
by Yu-Chung Wang 15 Dec '10

15 Dec '10

Is the link become available in the WIKI? We are actually working on adding scene and animation editor into the inkscape. This will make the inkscape become an environment similiar to the Abobe Flash. So far, we have finished some prototype to edit multi page SVG file and some simple animation support. So far, in the integration is only at the Node and NodeObserver level, therefore, its relationship between inkscape and python VM is quite weak. However, in order to make it easier to use, we need to bind more and more functions into the python. This will make the binding easier to be broken from version to version. This is why we want to make it into the code base. The other possibility is not to put the python into the code base directly. Instead, define an binding interface which should be used by any system like ours so that we can develop our stuff outside the code base safely. You can decide to include our stuff or not until the technical issue is clear. >>I'll list out a few more details on this in the wiki, so that the reoccurring discussion can be captured.

6 21

0.48 trunk compilation bug&fix, launchpad questions
by Robin Palotai 15 Dec '10

15 Dec '10

Hello, Sorry in advance, this is a composite-topic email. 1) Launchpad question - am I ok so far? Being new to bzr/launchpad I'm a bit confused yet. What I would liked to do is to branch the 0.48.x branch and apply/rewrite some of my former patches to there (not the 0.49.x, because unfortunately my libs seem to be too old to compile it). I branched lp:inkscape/0.48.x, and also pushed it to a custom branch atlp:~palotai-robin/inkscape/0.48.x . Now at the bottom of the launchpad page, it tells that it is "stacked on lp:inkscape", where I would expect it to be lp:inkscape/0.48.x. Is this ok? 2) Some compilation errors with the 0.48.x trunk I used 'configure --disable-lcms', gcc 4.3.2, x86, Debian Linux (lenny), glib 2.22.4, glibmm 2.16.4, gtk 2.12.12, gtkmm 2.12.7 (according to the package manager). 2A) The error mentioned here: http://comments.gmane.org/gmane.comp.graphics.inkscape.devel/35338 Solution was to include "io/sys.h" in color-profile.cpp 2B) Gtk::IconTheme::load_icon doesn't have default third parameter on my system, while inkscape uses the two-param version at two places: interface.cpp <http://comments.gmane.org/gmane.comp.graphics.inkscape.devel/35338>- Glib::RefPtr<Gdk::Pixbuf> pb = iconTheme->load_icon( it->second, *it2 ); + Glib::RefPtr<Gdk::Pixbuf> pb = iconTheme->load_icon( it->second, *it2, (Gtk::IconLookupFlags) 0 ); ui/widget/dock-item.cpp - Glib::RefPtr<Gdk::Pixbuf> pb = iconTheme->load_icon( it->second, *it2 ); + Glib::RefPtr<Gdk::Pixbuf> pb = iconTheme->load_icon( it->second, *it2, (Gtk::IconLookupFlags) 0 ); 3) How do I commit these patches? Having these fixed, what is the expected lp/bzr procedure for create bug/commit patch? 4) Is adding new features (those I originally wanted) on the 0.48.x branch is in vain? If it is a corrections only branch, then maybe it is in vain. But I can't compile for 0.49, so maybe creating the patches for 0.48 would make it easier to merge them in 0.49 eventually. Thank you, Robin

2 1