- Inkscape Devel - Inkscape Mailman

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

Problem with open several .ai files
by gosha-necr 24 Oct '09

24 Oct '09

Hi friends! I don't know, is this right mailing list, but i think it is related to developers. I'm download icons from here http://iconeden.com/download/26/Bright.eps.zip and there are in .ai file. But with inkscape 0.46 on FreeBSD 7.2 i386 it cannot open this file. -- -------------------------------------------- С уважением, Гуляев Гоша.

2 1

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

24 Oct '09

> From: Thorsten Wilms <t_w_@...123...> > As this issue affects all kinds of graphic and sound applications, I > have been thinking about a solution on another level. This would require > linking to objects via IDs, so you can move stuff around without > breaking links. Dependency tracking and automatic bundling once your > stuff leaves your system. I strongly agree. Dependency tracking would be the perfect solution for novice and advanced users. I think that it should be the ultimate goal in image link management, but meanwhile we should implement some minor improvements (like some of the proposed in my blueprint) for making it nicer to work with images in Inkscape. The good thing is that these improvements are compatible with that ideal solution, so it wouldn't be wasted time to fix some annoyances of the image properties dialog now :-) > From: Krzysztof Kosi?ski <tweenk.pl@...400...> > I don't want just to flip the default, I want to change the behavior > of the existing commands (import and paste) so that it follows > intuition, and add new commands that explicitly expose the link > behavior (see below). > Note that the current behavior is wrong on many levels: > - For pasting, we create a PNG file in the same directory as the > edited file with a crazy name like > inkscape_pasted_image_20091023_144102.png ?and link it. > - For importing via drag-and-drop, we embed. > - For importing via the dialog, we make a link. > The defaults are inconsistent, and the paste case is completely bogus > because 1. It attempts to write to the directory where the doc is > located, which may not be permitted (the directory and the doc might > be read-only); 2. It creates a crazy filename; 3. It breaks when the > user relocates the document. More importantly we cannot create links > to things that might not even be in a file (like pasting pixels from > GIMP). > Therefore we should default to embedding on paste and DnD, and have 2 > import commands: Import, which embeds, and Link Image, which creates a > link. Note that this will make Import behavior consistent across all > formats. When importing SVG or other vector formats, we never create a > link. > Serious artist know they want an image link, and most importantly know > the difference between an embedded image and a link, so they will > choose the correct option (insert image link). Newbie users do not > know about this distinction. They just want to put images in the > document, and expect them to stay there when they move the document to > another folder or remove the original images. > Krzysztof: Actually, every image is LINKED. There are no inconsistencies at all. You say importing via drag and drop embeds, and that's wrong. The naming and location of pasted files can be discussed, of course, but you seem to be proposing to change the behavior of something that is common in every program that works with external data (vectorial illustration, page layout, even audio and video editors) because it isn't "intuitive" for new users who didn't read the documentation? It wouldn't be a problem if it is harmless, but changing it brings a lot of problems, as JonCruz pointed out. In my honest oppinion, a switch in the import dialog, a good method for dependency tracking and solving and a better image properties dialog would be the best solution. Dumbing down the program because a part of its users are new to it and didn't read the documentation is shooting to your own foot. An SVG file, as it names stands for, stores VECTOR graphics. If it allows to embed bitmap images, it is an option for cases when it's needed. Links are the proper way to include images, and the most convenient most of the times. Also you're assuming that an SVG file is something that a regular user will send to his friend via email, like a jpeg. Inkscape is a vector illustration program. Its files are comparable to CDR or AI files, that also work with links and embedded images. So I guess it's safe to say that the target public for an application like inkscape isn't a complete newbie that only used MS Paint. By the way, GIMP started to change its focus since a clear target user was defined, and this kind of discussions (if the program is or isn't friendly for the unexperienced users) kinda stopped. Does inkscape have a clear target user group defined? > I don't understand. How do you imagine making an image external > without saving it? :) Re-linking it to the original bitmap file. If you imported it once, you may still have the original file in your disk. If you simply save it again, you'll end up with the original and the "externalized" image in your disk. That's confusing and breaks apart you project's organization. Gez.

7 7

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Krzysztof Kosiński 23 Oct '09

23 Oct '09

(unintended private email, again... -_-) W dniu 23 października 2009 21:37 użytkownik Steren <steren.giannini@...400...> napisał: > 2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...> >> >> When you paste an image into a Word / ODT >> file, it is not a link to that file on your hard disk. > > Actually, OpenOffice.org is sometimes using Links, I'm not an expert but I > used it in the past. > Try out with OpenOffice.org : > - Create a document > - Insert > Picture > From File > - in the dialog, select an image and tick "Link", then Open > A dialogpops-up asking you If you are sure you want to link it. See capture > attached to this email. You can choose to ask again when you will be linking > your next image or you can say "I know what I am doing" by ticking > something. That's the point - when you are making a link, you are explicitly saying this. The default is to embed, and to get links you have to explicitly want them. I don't want to remove the possibility of creating links. I just want to make embedding the default, so there is less confusion by broken documents, and provide different explicit commands for linking. > Then you can edit these Links with Edit > Links. This opens a window that > inspired me for the "Image Links Manager" proposal. > > So this leads us to say that we are not the only one having issues for an > understandable-by-everyone linking strategy. The OpenOffice strategy is reasonable. You only end up with broken documents if you explicitly want it. The default is to embed, but you can create a link if you want. We need to recognise that the concept of creating a link is different from the concept of pasting or inserting, and should be given different commands. Regards, Krzysztof.

1 0

Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
by Krzysztof Kosiński 23 Oct '09

23 Oct '09

(Sorry, resending this to list - the Gmail interface defaults to a private reply and I keep making the mistake) 2009/10/23 Jon A. Cruz <jon@...18...>: > A simplistic approach of a solution is to merely switch the default. > However what generally happens in these cases (and specifically in > this one) is that you are seeing bug reports from those who don't like > the current behavior, but you see no feedback at all from those who > are happy with the current behavior. I don't want just to flip the default, I want to change the behavior of the existing commands (import and paste) so that it follows intuition, and add new commands that explicitly expose the link behavior (see below). > BTW, we have looked at this issue for some time, and there are severe > consequences to making embed the default. We definitely need to > remember to keep those in mind as we make changes. What are those issues? Note that the current behavior is wrong on many levels: - For pasting, we create a PNG file in the same directory as the edited file with a crazy name like inkscape_pasted_image_20091023_144102.png and link it. - For importing via drag-and-drop, we embed. - For importing via the dialog, we make a link. The defaults are inconsistent, and the paste case is completely bogus because 1. It attempts to write to the directory where the doc is located, which may not be permitted (the directory and the doc might be read-only); 2. It creates a crazy filename; 3. It breaks when the user relocates the document. More importantly we cannot create links to things that might not even be in a file (like pasting pixels from GIMP). Therefore we should default to embedding on paste and DnD, and have 2 import commands: Import, which embeds, and Link Image, which creates a link. Note that this will make Import behavior consistent across all formats. When importing SVG or other vector formats, we never create a link. Regards, Krzysztof

3 3

Specification: Improved image properties dialog (0.48)
by Guillermo Espertino 23 Oct '09

23 Oct '09

Hi: I created a blueprint based on some ideas discussed in https://bugs.launchpad.net/inkscape/+bug/172162 It's a specification of an improved image properties dialog that (hopefully) would tackle some annoying aspects of image links management in inkscape. I've received valuable ideas from ~suv and Steren Giannini and the specification is starting to look very good, so I'd like to propose it as a feature for the next version of Inkscape. The blueprint: https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enh… I'd really love to know your oppinions about it, and get as many suggestions, critics, ideas or questions you might come up with to make it better. Gez.

8 10

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

23 Oct '09

About image links being confusing for users... Most of the vectorial illustration programas I know use links. Designers at least are pretty used to the images being linked. Anyway, those other programas also include an option on import to link or embed images, so I agree about adding that feature. Where I do not agree is about making embed default. Embedding is handy in a lot of cases and would help newbies, but a serious artists or designers would want to have those images linked, because usually they have to be edited. Keep in mind that a couple of images embedded won't be a problem, but dozens in high resolution can take the svg size too high. There's also a problem: As far as I know, it's impossible atm to convert an embedded image to a linked image without saving it. So if you imported it and it was embedded, when you extract it you'll have two files in your disk. Of course we can (and should) modify the specification to allow re-linking to an existing file as an option along with extract the embedded image. But I think that we should avoid making embedded images default until we can provide that option. And even in that case, I think we should place a preference for changing that default. Gez

2 1

vertical toolbars
by Albert Cardona 23 Oct '09

23 Oct '09

Hi all, I've found bug/wishlist https://bugs.launchpad.net/inkscape/+bug/171663 ... which suggests that work is in progress to allow vertical toolbars. In a MacBookPro, which has very low screen height, one has to disable several toolbars to enlarge the area dedicated to the drawing enoug that it can be used nicely. Any reports on whether this feature is progressing? Thanks for any info. Albert -- Albert Cardona http://albert.rierol.net

3 2

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

23 Oct '09

I added Rok's suggestion to the specification. About its implementation, I agree with Steren's idea: let's use a button for matching original aspect ratio keeping the larger dimension and modifying the smaller. That would be the very useful to solve a very common situation: You imported an image, then you want to crop it (for instance, you have a sponsor logo with a lot of transparent space around and you want to get rid of that empty space and leave the logo only). Thanks for the feedback. Gez. p.s.: Steren, It'd be great if you could mentor a team of students to work on this feature. It can be made in different stages and it doesn't look too complicated to be finished in a short term.

3 4

Test suite
by unknown＠example.com 22 Oct '09

22 Oct '09

Hi all, Could someone have a look at the testsuite and reprogram it such that (at least when perceptualdiff is used) the results that are marked 'new' are marked 'fail' instead? This is much clearer, and cleans up the daily checks at http://auriga.mine.nu/inkscape/. Thank you very very much! I love the testsuite, but I don't want to delve in to the code and change things myself. Thanks a bunch, Johan

3 6

Patch for Embed Image extension
by Nicolas Dufour 21 Oct '09

21 Oct '09

Hi, I've posted a patch for the following bug: [Bug #386069] Embed extension fails https://bugs.launchpad.net/inkscape/+bug/386069 It fixes a win32 issue when the path or filename has an accent, or any non us ascii character (two bytes encoded in utf-8) . Patch tested on Ubuntu 9.04, OS X, Windows XP and Vista. Please check and commit, or just tell me if you think it's too late for 0.47. Regards. -- Nicolas

1 0

0.47 status
by Joshua A. Andler 21 Oct '09

21 Oct '09

So, We have one blocker left. Apparently some preferences need to be migrated over from 0.46. JonCruz was working on this, but, he just started a new job and doesn't really have the time necessary to finish it. At this point, we need to figure out a list of preferences to see if this really is a blocker issue or what. It makes no sense to hold up the release if no one is going to fix the last problem (we have tons of other issues that we're willing to release with after all). I know of the "recent documents" being one thing that doesn't carry over. What else people? Cheers, Josh

4 3

Broken link to ebuild on wiki CompilingGentoo
by Jeff Kowalczyk 20 Oct '09

20 Oct '09

Does anyone have a copy of the inkscape-9999.ebuild linked at: http://wiki.inkscape.org/wiki/index.php/CompilingGentoo The current link is 404 Not Found. Thanks.

2 2

DVCS take 2
by the Adib 20 Oct '09

20 Oct '09

hello all, for the time after this release we decided to switch to bzr, right? Is there any howto for me as a default cvs/svn user how to create my own local branch and commit back to the mainline branch? A WIKI page would be helpful :-) Thx, theAdib

4 3

[Bug 452568] Significant differences between rendering of markers 0.46 -> 0.47
by ~suv 19 Oct '09

19 Oct '09

Bug [452568] "rotating line with arrow end doesn't rotate the arrow" <https://bugs.launchpad.net/inkscape/+bug/452568> I have little insight into the technical details of markers in SVG 1.1, but from a users POV I am concerned about the differences between 0.46 and 0.47pre in rendering seemingly basic arrowheads. Should this be mentioned more prominently in the release notes or is it a minor detail concerning only a small group of SVG drawings which are either not created with Inkscape or manually edited? Any input from an expert how to triage this bug would be highly appreciated (mainly - is it 'Won't Fix', 'Invalid' or bug 'Confirmed') screenshots showing the differences between 0.46 and 0.47pre on OS X: <http://launchpadlibrarian.net/33941210/452568-markerTest-ss-046-osx.png> <http://launchpadlibrarian.net/33941237/452568-markerTest-ss-047-osx.png> ~suv

1 0

Would like input on a patch from other devs.
by Joshua A. Andler 19 Oct '09

19 Oct '09

Hey All, So, Adib made a patch to address one of the issues that has annoyed many users... saving over a non-writable bitmap type (such as jpg) that they had opened. The patch simply checks to see if we can write the filetype, if not, throws an error message and then proceeds to open a Save As dialog. The problem is that the error message is unclear as it is a standard error message that we have and makes no sense in the context unless you know how our files are handled internally. The message is "No Inkscape extension found to save document (/path/to/file.jpg). This may have been caused by an unknown filename extension." So, the question is, would people be okay with us shipping with the user-unfriendly error message in favor of saving people's data? Yes we could create a custom message for it, but I really don't want to break the string freeze again. After 0.47 is out, we could then make a 0.47.1 branch and have the proper error message that explains what went wrong (obviously adding to trunk as well). Please share your thoughts. Cheers, Josh

3 3