November 2008 - Inkscape Devel

.dxf input routine
by Alvin Penner 05 Nov '08

05 Nov '08

This is a request for feedback, I've submitted a proposal for a .dxf input routine at https://bugs.launchpad.net/inkscape/+bug/293940 and thought I'd ask for feedback while deciding what to do with it. It is a limited scope input routine, supporting AutoCAD Release 13, designed as a counterpart to the existing Desktop Cutting Plotter output. -- View this message in context: http://www.nabble.com/.dxf-input-routine-tp20336088p20336088.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

Launchpad and "Fix Committed"
by Krzysztof Kosiński 03 Nov '08

03 Nov '08

The current practice is to mark bugs "fix released" in Launchpad when committing to SVN. The rationale for this (given by bulia in another thread) is that this way the "open bugs" count is more useful for the developers. I think this is an abuse of Launchpad bug tracking. IMO the rationale isn't sufficient. It creates confusion for users which re-report bugs that have been fixed in SVN, because "fix released" bugs do not show up in search results. There must be a better way of tracking how many bugs have been fixed. Currently I know about advanced search (just search for all bugs with statuses New, Triaged, Confirmed, Incomplete, In Progress) and milestones which can isolate the most important bugs. Another option is to talk to the Launchpad team to include an "Unfixed" count on the bugs page which would exclude "fix committed" bugs. This will be better than abusing the system and confusing the users in the name of seeing some number. Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Launchpad-and-%22Fix-Committed%22-tp20176935p20176935… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

7 19

Re: [Inkscape-devel] Snapping should only occur at the end of a movement
by Guillermo Espertino 03 Nov '08

03 Nov '08

I really prefer the previous behavior of the snapping. Now it seems to work fine, but you don't get a visual feedback of the snapping until you release the mouse button. I think that it's questionable from the usability point of view. Snapping result should be visible before you release the mouse click, because the user wants to know if the snapping was successful before that, not after. In the previous versions, the shape was atracted to the snapping point when the pointer entered in the snapping threshold, so you could easily see the end result before releasing the mouse button. Now you can't and it feels like you have no control in the process. For instance, if you need to enlarge or shrink a rectangle beyond a guide and you have the snapping on, it is possible that you get the shape snapped to the guide even if you don't want to, and you'll realize that only after you released the mouse button (thinking that the shape wouldn't snap). Besides that, there are still isues when enlarging or shrinking shapes. Some snapping settings will make almost impossible to scale a shape without being atracted to a snapping point (making it go back to the original size or disappearing). I really don't know about the snapping code (in fact, I don't know anything about code) but it "feels" like there should be a "zone" around the mouse pointer to perform the snapping (and the snapping nodes should be aligned to that zone depending on the axis of the transformation to avoid random snapping) and the snapping should be visible before releasing the mouse button. At the end of the movement, right, but not after the mouse button release. IMO, the current behavior shows some improvements but also some regressions. Just my 2 cents. Gez.

4 5

Rendering test results on-line
by Jasper van de Gronde 03 Nov '08

03 Nov '08

If you go to: http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html you will now see an up-to-date list of test results for Inkscape's rendering tests. It now contains one column, each time I run the tests a column will be added (to the left). It's still pretty bare-bones, but I hope I (or someone else) will find some time to improve it in the near future. I plan to run the tests regularly for at least the next two months or so. I have to run the tests more or less manually though (I created a batch file to automate most steps, but I still have to run the batch file manually, on my notebook...), so I'm interested in any suggestions people might have for hosting (more) fully automated tests. You don't see any test for your favorite rendering bug? No problem, if the bug is already in the bug tracker with the required test files (read on), just mail me and I'll add it. If not, create an SVG demonstrating the problem (small and simple please) and one or more of the following: - A PNG of the wrong output. - A PNG of the right output (preferably exact). - An SVG that should look exactly the same, but is rendered correctly by Inkscape. Then attach the files to the corresponding bug in the bug tracker (or create a new bug and attach the files if it isn't the tracker yet) and mail me (or anyone else who has SVN access). Of course, if you have SVN access you can add tests yourself. The bugtracker: http://bugs.launchpad.net/inkscape For more information about Inkscape's (rendering) tests: http://www.inkscape.org/wiki/index.php/TestingInkscape The test suite in SVN: https://inkscape.svn.sourceforge.net/svnroot/inkscape/gsoc-testsuite The directory 'tester' contains the actual rendering tests, the directory ResultViewer contains my clumsy attempt at a GWT project.

4 4

Re: [Inkscape-devel] Snapping should only occur at the end of a movement
by Inkscaper Inkscaper 02 Nov '08

02 Nov '08

I have to agree with Guillermo. While reading the discussion here I was very excieted about new imporvements, but after trying it I missed old behaviour where snapping occured _while_ dragging an object, not after releasing mouse button. It feels somehow more natural to see guidelines working in real time, and in most cases works faster (no waiting for delay or clicking object again because it was not snapped or snapped to wrong guideline). An option to set snapping delay to zero would be very useful for some users... and especially for me :)

2 1

[ndeschildre@...1792...: Ubuntu Brainstorm 8.10 report]
by Bryce Harrington 02 Nov '08

02 Nov '08

----- Forwarded message from Nicolas Deschildre <ndeschildre@...1792...> ----- Date: Sun, 2 Nov 2008 19:09:07 +0100 From: Nicolas Deschildre <ndeschildre@...1792...> To: ubuntu-devel-discuss@...2067... Subject: Ubuntu Brainstorm 8.10 report Hello there! I wrote a small document about Ubuntu Brainstorm trying to summarize what's going on there (with a few stats), what you can expect from it, a summary of the most wanted features from its users, and its impact. I wrote this hoping to give to contributors and developers (not limited to Ubuntu) some clues of the most asked features out there, and what worries our users the most. You can grab it here: http://www.ndeschildre.net/downloads/UbuntuBrainstorm810Report.html Cheers, Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@...2067... Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss ----- End forwarded message -----

1 0

friend declaration problem
by unknown＠example.com 01 Nov '08

01 Nov '08

Hi all, I added a proper constructor for nodepath that does nothing at the moment. It should be private, people should use sp_nodepath_new to create new nodepaths. However, this does not work: namespace Inkscape { namespace NodePath { class Path { private: Path() {}; friend Path * sp_nodepath_new (SPDesktop *, SPObject *, bool, const char *, SPItem *); ... }; } } Inkscape::NodePath::Path * sp_nodepath_new (SPDesktop * desktop, SPObject *object, bool show_handles, const char * repr_key = NULL, SPItem *item = NULL); This gives a compiler error when newing Path in sp_nodepath_new. Can someone else try and see if it works on Linux for example? thanks a bunch, Johan

2 1

0.46.1
by Alexandre Prokoudine 01 Nov '08

01 Nov '08

Hi, Speaking about releases, are we still up to releasing 0.46.1? Alexandre

4 4

Error with inkscape and libpng
by Vladimir 01 Nov '08

01 Nov '08

Good day. I use the following software: inkscape-svn cairo-git poppler-git libpng-1.2.32 cairomm-git freetype2-cvs gtkmm-2.14.1 glibmm-2.18.0 on Slamd64-current. When I try to compile inkscape compilation is aborted on the following: <CONSOLE_LOG> make all-recursive make[1]: Entering directory `$HOME/tmp/src/inkscape-svn' Making all in src make[2]: Entering directory `$HOME/tmp/src/inkscape-svn/src' depbase=`echo sp-image.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE -I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/include/poppler -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -DPOTRACE=\"potrace\" -pthread -I/usr/local/include -I/usr/include/gdkmm-2.4 -I/usr/lib64/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtkmm-2.4 -I/usr/lib64/gtkmm-2.4/include -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I../cxxtest -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 -MT sp-image.o -MD -MP -MF $depbase.Tpo -c -o sp-image.o sp-image.cpp &&\ mv -f $depbase.Tpo $depbase.Po In file included from /usr/include/libpng12/png.h:459, from sp-image.cpp:50: /usr/include/libpng12/pngconf.h:326: error: expected constructor, destructor, or type conversion before '.' token /usr/include/libpng12/pngconf.h:327: error: '__dont__' does not name a type make[2]: *** [sp-image.o] Error 1 make[2]: Leaving directory `$HOME/tmp/src/inkscape-svn/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `$HOME/tmp/src/inkscape-svn' make: *** [all] Error 2 </CONSOLE_LOG> I check the 'pngconf.h' file and found that line-327 tries to avoid repeated inclusion of setjmp.h but this file is included in buildtool.cpp My last successfull build of Inkscape was done 23 Aug 2008 (Help->About Inkscape). I think that from that time something was changed in build chain and, of course, in source. May be I miss some dependencies? I be glad for any advice on problem. P.S. Sorry, if my English is poor. --- WBW, Vladimir Lomov

1 0

Win32 and the recent file list changes...
by john cliff 01 Nov '08

01 Nov '08

Just wondering if theres anyone out there who can confirm if the changes to the recent file list are working for them?I dont seem to have any files showing up in my list, it just always shows the no items found. Anyone else seeing this? or anyone have it working on windows? I'm on Vista Home just for reference. Cheers Sim

6 9