- Inkscape Devel - Inkscape Mailman

libgdl
by Joel Holdsworth 24 Feb '09

24 Feb '09

Hi All, Just to say that working on the Lumiera project, we've adopted the GDL library for panel management, same as Inkscape. We've found some shortcomings with GDL: it's got a few bugs, the documentation is sparse, and it lacks some features that we need. Right now the Anjuta guys are maintaining it, and I'm submitting patches, and other people seem to be contributing to it from time to time. I notice that Inkscape uses it's own forked version of GDL. I don't know who's maintaining that code, but can I suggest that someone take some time to try and move over to using the shared library? The Anjuta guys are very helpful, and seem happy to accept all kinds of patches, including feature additions, so there shouldn't be too many political problems in merging. If you can merge over, then Inkscape, Anjuta, and Lumiera will all benefit from shared maintenance of the code. The flip side is that I'm squashing bugs, and I'd like Inkscape to benefit from my work! Is this going to be possible, do you think? Best Regards Joel

7 8

Issue with work on new font dropdown
by Milosz Derezynski 22 Feb '09

22 Feb '09

Hello Everyone, I want to discuss one issue with the new font dropdown. I've already begun work on it and it can be seen in action in these 2 videos: http://futurepast.free.fr/out.ogv http://futurepast.free.fr/preview-text-update.ogv It uses threading for generating the preview as not to stall the UI/main application while scrolling, or take too long to startup when generating all the previews at startup of the application. My architecture for this is very pluggable, I defined interfaces for all the classes used and wrote a few sample implementations which you can see at work in those 2 videos. Now I've run into a problem: For the class that generates the actual thumbnails I've initially chosen Pango to render them. Now it seems that Pango is not thread-safe and I wrote another implementation using just cairo which seems to work fine so far. The issues is that with cairo, we don't get proper thumbnails for some fonts, or some scripts. Pango handles this on a higher level and much better. Bulia mentioned to me that tradeoffs might be possible, but I am not sure at which point to make these. I'm not an export on cairo or freetype2 to make this particular backend work properly with all fonts and all scripts/glyphs. Then, there is always the third option of not using threading, but I'd prefer to keep it since it works really well and is an ideal solution for the problem of time-consuming rendering of previews of complex fonts. Please don't worry about "threading" itself, I'm using libsigx in accordance with Bulia, which can be found here: http://www.assembla.com/wiki/show/sigx and is a threading library based on libsigc++ and makes thread programming *very* safe. The question now is: - Keep the cairo-only backend with the tradeoff that we can not render everything properly - Try awkward things with Pango like dlopening() a 2nd ("private") instance of libpango and use this solely for generation of the previews - Drop threading(?) - Does anyone have a 4th solution? To those interested: The details in the problems with Pango lie in that some structures inside libpango are not properly locked or protected, and race conditions occur when simply running the thumbnail generation in a thread with the same libpango instance, and merely simply rendering the application's UI with Gtk+ which uses Pango for text widgets and/or rendering canvas text since layout-TNG uses Pango as well from what I've seen in the code so far. Any suggestions regarding this problem are appreciated. Regards, M. -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

1 3

Created a branch?
by Diederik van Lierop 22 Feb '09

22 Feb '09

Apparently I created a branch in our svn repository by mistake, I only intended to switch to another revision. I was using eclipse without paying much attention to which popup menus I was exactly in. See rev. #20751, we now have a trunk in our trunk :-(. Could someone please delete this? I'm not going to try to do this myself to avoid making even a bigger mess of it. I'm not very familiar with this stuff. Sorry. Diederik

1 0

error compile svn revision 20749
by Valessio Brito 22 Feb '09

22 Feb '09

mv -f $depbase.Tpo $depbase.Po depbase=`echo widgets/gradient-toolbar.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libwpg-0.1 -I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gtkspell-2.0 -I../cxxtest -I./bind/javainc -I./bind/javainc/linux -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -fopenmp -MT widgets/gradient-toolbar.o -MD -MP -MF $depbase.Tpo -c -o widgets/gradient-toolbar.o widgets/gradient-toolbar.cpp &&\ mv -f $depbase.Tpo $depbase.Po depbase=`echo widgets/gradient-vector.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libwpg-0.1 -I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gtkspell-2.0 -I../cxxtest -I./bind/javainc -I./bind/javainc/linux -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -fopenmp -MT widgets/gradient-vector.o -MD -MP -MF $depbase.Tpo -c -o widgets/gradient-vector.o widgets/gradient-vector.cpp &&\ mv -f $depbase.Tpo $depbase.Po depbase=`echo widgets/icon.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libwpg-0.1 -I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gtkspell-2.0 -I../cxxtest -I./bind/javainc -I./bind/javainc/linux -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -fopenmp -MT widgets/icon.o -MD -MP -MF $depbase.Tpo -c -o widgets/icon.o widgets/icon.cpp &&\ mv -f $depbase.Tpo $depbase.Po widgets/icon.cpp: In function 'void sp_icon_fetch_pixbuf(SPIcon*)': widgets/icon.cpp:227: error: 'gtk_icon_theme_get_default' was not declared in this scope widgets/icon.cpp:228: error: 'GtkIconLookupFlags' was not declared in this scope widgets/icon.cpp:228: error: 'gtk_icon_theme_load_icon' was not declared in this scope widgets/icon.cpp: In function 'bool prerender_icon(const gchar*, GtkIconSize, unsigned int)': widgets/icon.cpp:946: error: 'gtk_icon_theme_get_default' was not declared in this scope widgets/icon.cpp:947: error: 'GtkIconLookupFlags' was not declared in this scope widgets/icon.cpp:947: error: 'gtk_icon_theme_load_icon' was not declared in this scope make[2]: ** [widgets/icon.o] Erro 1 make[2]: exit... `.../inkscape/src' make[1]: ** [all-recursive] Erro 1 make[1]: exit... `.../inkscape' make: ** [all] Erro 2

1 0

Bizarro Makefile_insert usage
by Krzysztof Kosiński 21 Feb '09

21 Feb '09

What is the purpose of using Makefile_insert to pretend that everything is in the src directory instead of using the SUBDIRS directive? I'm intending to change the Automake build system to link the executables from single object files instead of static libraries so that we may finally put files in the proper directories (e.g. remove widgets/ and dialogs/ and move those to ui/widget and ui/dialog/, as well as join helper/, util/ and svg/), and I would like to know whether I should also sanitize general Makefile usage while I'm at it. Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Bizarro-Makefile_insert-usage-tp22120462p22120462.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 7

Re: [Inkscape-devel] Corel DRAW-like Snapping
by Diederik van Lierop 21 Feb '09

21 Feb '09

Op Ma, 16 februari, 2009 01:47, schreef Krzysztof KosiÅski: > > > Diederik van Lierop wrote: >> >> Already implemented. Please select "only snap the node closest ..." in >> the prefs. >> > This is great! Why isn't it on the snapping toolbar though? I didn't find > it > at first because I assumed that most of the snapping options will be on > the I didn't want to put everything in the toolbar, because that would be way too much. Currently only the per-document snapping options are in the snap toolbar, and the prefs are not. Maybe we could just add a button to quickly open the preferences dialog, defaulting to the snapping tab? That would make them more easy to discover. > toolbar. Also of note is that the snapping options from the toolbar are > not > present in the prefs dialog - not very intuitive if e.g. someone disables > the toolbar to conserve screen space like I do. They used to be available in the document properties dialog, but it was difficult not make a mess of it using only checkboxes. Now we've got icons, we could use these in the document properties dialog too, but I do not like duplicating functionality (and code) unless really badly needed. > Another thing is that the visualization of the snapping isn't best - while > hovering over e.g. a rectangle, there is no indication of which node will > snap when I drag the rectangle - it only appears when I start dragging, > and > it isn't clear what this little circle means. We could indeed use some better graphics here, I just chose one from stock. The cross (displayed after snapping) is not very noticeable either. > The best thing to do would be > to display text over the node that will snap (e.g. "corner", "midpoint", > etc.) while the user hovers the select tool over the selected shape, and a > similar text when I think text would be a bit too intrusive, but it would indeed be useful to display what will snap in advance. > However, those are just small usability glitches. Again, thanks for this > incredible feature! Thanks. You're welcome! Regards, Diederik

3 8

Inkscape + Boost == usage question
by Milosz Derezynski 21 Feb '09

21 Feb '09

Hey guys, In the course of doing the work in cooperation with LinuxFund, one question: Can I fully depend on boost? Regards M. -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

3 3

Typo in current svn - src/helper/sp-marshal.cpp
by Lucas Vieites 21 Feb '09

21 Feb '09

Hi, I'm trying to compile from svn and while doing "make" it complained about not finidng a file. I think I've found a typo in "src/helper/sp-marshal.cpp". On the first line it says: ============================ #include "helperosp-marshal.h" ============================ but should be: ============================ #include "helper/sp-marshal.h" ============================ Cheers, -- Lucas Vieites <lucas@...1852...>

2 1

Idea: Get rid of some .h files by using static signal binding
by Krzysztof Kosiński 21 Feb '09

21 Feb '09

Right now every dialog, extension, etc. has to have a header file - otherwise it's unusable. The underlying issue for dialogs is that there must be an action defined to open them. This means either including the dialog header in verbs.cpp, or wherever the dialog is used. I stumbled over OpenBabel sources some time ago and this gave me the following idea. We put this in some file, e.g. action-manager.h: class ActionManager { ... typedef ActionVector std::vector<Glib::RefPtr<Gtk::Action> >; class GetActionsMarshaller { ... bool marshal(InType x) { _actions.push_back(x); } OutType value() { return _actions; } ActionVector _actions; } ... static ActionManager *get() { static ActionManager *am = new ActionManager(); return am; } Glib::RefPtr<Gtk::ActionGroup> get_document_action_group(Glib::ustring name) { Glib::RefPtr<Gtk::ActionGroup> ag = Gtk::ActionGroup::create(name); ActionVector actions = signal_get_actions.emit(); for(ActionVector::iterator i = actions.begin(); i != actions.end(); ++i) { ag.add(*i); } return ag; } sigc::signal<Glib::RefPtr<Gtk::Action>, GetActionsMarshaller> signal_get_actions; friend class GetActionsMarshaller; }; template<typename T> class ActionManagerEntry { ActionManagerEntry() { ActionManager::get()->signal_get_actions.bind(sigc::ptr_fun(T::create)); } }; Then in the dialog file we put this: class ShowSomeDialogAction : public Gtk::Action { ... virtual void on_activate() { SomeDialog::show(); } static Glib::RefPtr<Gtk::Action> create() { return Glib::RefPtr<Gtk::Action>(new ShowSomeDialogAction); } } ActionManagerEntry<ShowSomeDialog> ame_show_some_dialog; And to construct the action group we do this: ActionManager *am = ActionManager::get(); Glib::RefPtr<Gtk::ActionGroup> document_actions = am->get_document_action_group(document_name); What happens here: Each ActionManagerEntry adds a callback to the ActionManager object. This way, the actions are not actually created until GTK is initialized and a document is opened. When we want to create an action group for a document, we send the get_actions signal. The GetActionsMarshaller class marshals the responses we get from the registered callbacks and creates a vector of actions, which are then added to an action group and returned. A similar approach can also be used to get rid of headers and centralized initialization for e.g. extensions What do you think of this approach? On one hand, it scatters the action definitions across many files, but on the other it removes the need for centralized initialization and improves modularity (everything pertaining to a given dialog is in one file, including its actions). Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Idea%3A-Get-rid-of-some-.h-files-by-using-static-sign… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

Generic cascading in libcroco
by Robert Staudinger 20 Feb '09

20 Feb '09

Hello, I've finally gotten around to add a generic interface to the libcroco selection engine. Pretty much just exchanging libxml calls to invocations on an vtable provided by the API consumer. On top of that I reinstated the libxml-based API and made sure the tests (the selection engine is only used by test5) work as before. Are you inkscapers still interested in eventually using upstream libcroco? Your internal copy seems to have deviated pretty much from upstream, it would be good if we could at least exchange fixes, things were not quite obvious looking at the raw rdiff. We (Thomas Wood + yours truly) actually tried to extract just the selection engine patch(es) from your svn repository, but it proved quite hard to make any sense of it. My branch is at http://bzr-playground.gnome.org/~robsta/libccss-selection-engine/ but will go to trunk within the next few days, as the tests already work as they should. Best, Rob

3 3