- Inkscape Devel - Inkscape Mailman

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