October 2009 - Inkscape Devel

Bug in snapping (using pen tool)
by Arcadie Cracan 28 Oct '09

28 Oct '09

Hello, I've found a misbehaviour in the latest svn regarding snapping. Using pen tool, with snap to grid enabled there are times when the first point of a polyline drawn using the pen tool is not on the grid. I have investigated this a little and it seems that at (random?) times the snapping gets "postponed globally"... I don't know why this could happen. Does anybody have a clue? Thanks, Arcadie Cracan

2 2

Re: [Inkscape-devel] [bug tracker] Guideslines for tags?
by ~suv 27 Oct '09

27 Oct '09

On 27/10/09 22:41, Krzysztof Kosiński wrote: > 2009/10/27 ~suv <suv-sf@...58...>: >> ° Wiki page: >> I have moved the section 'bug tracker: tags' to a separate page: >> <http://wiki.inkscape.org/wiki/index.php/BugTagsList> so everyone should >> feel comfortable editing it as it's no longer part of my user page ;-) >> > > Now it's my time to nitpick :) We are using MediaWiki since a long > time already, so please use normal page names instead of WikiWords > (for example, "Bug tags list" of "List of Launchpad bug tags" instead > of "BugsTagsList". You can fix existing pages with WikiWordNames by > using the "move" command, which automatically adds a redirect from the > old title to the new one. Thanks! Will do. I have no wiki experience (be it MediaWiki or whatever used 'WikiWords') and avoiding spaces in file names (or URLs) is just what I am used to and (usually) prefer ;-). So far the page isn't linked to from other pages, but will use 'move' anyway. ~suv (reading <http://wiki.inkscape.org/wiki/index.php/WikiSyntax>)

2 1

Donate mechanism broken
by Chris Boulter 27 Oct '09

27 Oct '09

I go through the Sourceforge 'Donate to Inkscape' process ... get a Paypal page ... am shown the error 'This recipient is currently unable to receive money'. How can I send you money? ;-)

2 1

Regression bug 445790
by unknown＠example.com 26 Oct '09

26 Oct '09

I just fixed a regression bug. https://bugs.launchpad.net/inkscape/+bug/445790 Stroke on text was rendered very noticably wrong; I fixed it. However, now a rendertestsuite test is rendered incorrectly again, but text is rendered correctly again (much more important at this stage I think). Basically the (wrong) 0.46 behavior is back. I could not find a way to fix this properly. Ciao, Johan

1 0

Errors while compiling inkscape for windows devel 22543
by mail＠...2227... 26 Oct '09

26 Oct '09

Hi, i get some errors while compiling the trunk sources for windows (devel 22543). While the command "btool" i get the following error message: Make error line 291: problem compiling: In file included from src/xml/subtr p:15: src/xml/node.h:21:25: error: glib/gtypes.h: No such file or directory In file included from src/xml/node.h:22, from src/xml/subtree.cpp:15: src/gc-anchored.h:14:28: error: glib/gmessages.h: No such file or directory In file included from src/gc-managed.h:17, from src/gc-anchored.h:15, from src/xml/node.h:22, from src/xml/subtree.cpp:15: src/gc-core.h:25:17: error: gc.h: No such file or directory src/gc-core.h:27:24: error: glib/gmain.h: No such file or directory In file included from src/xml/composite-node-observer.h:19, from src/xml/subtree.h:20, from src/xml/subtree.cpp:16: src/xml/node-observer.h:21:25: error: glib/gquark.h: No such file or direct In file included from src/xml/subtree.cpp:15: src/xml/node.h:97: error: ISO C++ forbids declaration of 'gchar' with no ty src/xml/node.h:97: error: 'gchar' declared as a 'virtual' field src/xml/node.h:97: error: expected ';' before 'const' src/xml/node.h:128: error: ISO C++ forbids declaration of 'gchar' with no t src/xml/node.h:128: error: 'gchar' declared as a 'virtual' field src/xml/node.h:128: error: expected ';' before 'const' src/xml/node.h:141: error: ISO C++ forbids declaration of 'gchar' with no t src/xml/node.h:141: error: 'gchar' declared as a 'virtual' field src/xml/node.h:141: error: expected ';' before 'const' src/xml/node.h:165: error: 'gchar' has not been declared src/xml/node.h:190: error: 'gchar' has not been declared src/xml/node.h:201: error: 'gchar' has not been declared src/xml/node.h:201: error: 'gchar' has not been declared src/xml/node.h:383: error: 'gchar' has not been declared In file included from src/xml/composite-node-observer.h:19, from src/xml/subtree.h:20, from src/xml/subtree.cpp:16: src/xml/node-observer.h:140: error: 'GQuark' has not been declared In file included from src/xml/subtree.h:20, from src/xml/subtree.cpp:16: src/xml/composite-node-observer.h:81: error: 'GQuark' has not been declared Can someone figure out what's wrong? Devel 22522 was building fine. Thank's for helping. Sincerely, UweSch

2 3

Re: [Inkscape-devel] Improved image properties dialog (0.48)
by Guillermo Espertino 26 Oct '09

26 Oct '09

Thanks for all the feedback about this specification. I'm collecting the information to improve my blueprint http://wiki.inkscape.org/wiki/index.php/Image_properties_dialog_enhancements Feel free to modify it adding things that I missed. Please keep in mind that the original proposal is to improve the usability of the current image properties dialog, not to provide a complete media manager (there are two extra specifications for that already started). I tried to keep things simple, modifying something that already exist in order to solve some common problems. I'm sure there is a lot of people who is, like me, comfortable with the current behavior of linked/embedded images, and would like just to have a handy way to re-link images or solve broken links easily. It also looks as a solution feasible in short term, being less ambitious than a complete media manager for all the data collection. In my honest oppinion, I'd prefer to have a decent solution for the next version instead of having to endure the current behavior for the next two or three versions waiting for the allmighty media manager. There are lots of minor details that keep being postponed waiting for the next great refactor, but meanwhile mean a hit in usability that can be really dissapointing for regular users. Inkscape 0.47 is great and I love the new features, but there are still minor things that turn into a big headache in everyday use (being unable to choose another type units than pixels, the recent regression in the selection area of clipped objects are clear examples of that). Among those things, the lack of a simple "browse" button in the image properties dialog seems a simple change that would make everyday use much easier. I'm not against big features at all, but maybe it's not the best thing if we define an ambitious, gigantic blueprint for each minor usability fix that comes up. A less pretentious solution could drag the attention of a group of students, like Steren's for instance. An ambitious specification would bump with the usual lack of developers and keep resting as a future project for a long time. Please take this as a constructive criticism and not as an attack to the decisions that inkscape developers have taken. Unfortunatly I'm not able to contribute with code and I can't fix things myself. Gez

1 0

[bug tracker] Guideslines for tags?
by ~suv 25 Oct '09

25 Oct '09

The new 'cloud' rendering of all tags on <https://bugs.edge.launchpad.net/inkscape> shows a total of 287 used tags. Are there any guidelines to follow when adding or renaming tags besides the visible 'official' and 'other' tags of the default interface on <https://bugs.launchpad.net/inkscape>? Is there a more suitable place to ask/discuss questions like this about the bug tracker and bug triage? tia, ~suv

6 17

my latest commit
by bulia byak 25 Oct '09

25 Oct '09

Today I decided to update my Windows build, stale by about a month, and got a crash on startup :( Recompiled from scratch, removed compiler optimization. Still crash. Debugging showed a very strange thing. There was this method in desktop.h: void registerEditWidget (Inkscape::UI::View::EditWidgetInterface *widget) { _widget = widget; } And it was called just before init with a non-NULL pointer: dtw->desktop = new SPDesktop(); dtw->stub = new SPDesktopWidget::WidgetStub (dtw); dtw->desktop->registerEditWidget (dtw->stub); dtw->desktop->init (namedview, dtw->canvas); but inside init(), _widget was NULL, as if some weird optimization made SPDesktop constructor (which NULLs _widget) fire after the registerEditWidget call instead of before. I have no idea what might be causing this and why it worked before. It might be some quite different but elsewhere that manifests itself in this strange way. Or, my Windows laptop may have become borked in some way. However, to be on the safe side, I removed registerEditWidget() (the above was its only use) and just added the widget parameter to init(). This way it no longer crashes for me. For everyone else this should be a no-op change. Still, I would be curious to hear others' ideas on what might be going on here. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Marker bug
by unknown＠example.com 25 Oct '09

25 Oct '09

Hi all, I think I fixed the marker issue in bug 456148. Thanks for committing to trunk, Johan

1 0

tango icon set is not by default
by solaris manzur 24 Oct '09

24 Oct '09

0.47 was supposed to have tango icons but I have downloaded the dev version and it still is not using them

2 1