- Inkscape Devel - Inkscape Mailman

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