November 2003 - Inkscape Devel

[Fwd: Re: [Inkscape-devel] New win32 cvs build]
by unknown＠example.com 29 Nov '03

29 Nov '03

Alan Horkan wrote: > On Thu, 27 Nov 2003, Mael wrote: > ... >>You still need to install gtk2 runtime from dropline >>(http://www.dropline.net/gtk/) first, then run the setup and run >>inkscape.exe (and enjoy :) > > > I've installed GTK-Runtime-Environment-2.2.4.1.exe which seems to be the > most up to date version available but I'm not having any joy. Basically I > dont think Inkscape is finding my copy of GTK properly. > Best you can do is add foo/GTK/2.0/lib to your path in the autoexec. A proposed by Mael (using batch file). > I get the following two errors > INTL.DLL is linked to missing export > ICONV.DLL:libiconv_set_location_prefix. > > and > > C:\Program Files\inkscape\inkscape.exe > A device attached to the system is not functioning > > I've tried unsuccessfully both > inkscape-0.36cvs-setup.exe and the earlier > inkscape-0.36-pre0-w32.exe > > I'm running windows 98, but I will probably be able to test against > windows 2000 this evening (and maybe Windows XP later in the week). > > Sincerely > > Alan Horkan I already tried the new one on Win98 and Win2K and it works ok in this point. The problem with the font I already described. There is this one bitmap <print direct> garbage. (BUG) The latest (beta2) sodipodi crashes on the file open dialog, but this is an other point. Adib.

2 1

New win32 cvs build
by Mael 29 Nov '03

29 Nov '03

Hello, For win32 people who want to test the new ui here is an inkscape build from cvs. I've done a *very basic* installer with nsis (http://nsis.sourceforge.net/). Download http://195.221.122.126/tmp/inkscape-0.36cvs-setup.exe [1.65 Mo] You still need to install gtk2 runtime from dropline (http://www.dropline.net/gtk/) first, then run the setup and run inkscape.exe (and enjoy :) Preferences are still saved in directory of install, this could easily be changed to save in user home dir Translations are included in the package I join the basic nsis script, in case someone want to polish/improve with : - create start menu entries and desktop icon - use more eye candy modern_ui from nsis - display of licence - option to launch inkscape at the end - safer uninstaller (be careful currently it removes the dir of install whatever is in..) ..etc.. I've not the time to do extensive tests right now, but some dialogs seem to generate lot of warnings in the console. I'll try to make a list of problems this week-end. M

3 2

Re: Addition: Inkscape
by Bryce Harrington 29 Nov '03

29 Nov '03

On Sat, 29 Nov 2003 webmaster@...86... wrote: > Your entry Inkscape has been added to > > http://www.linuxlinks.com/ > > It will appear after the next update (under 24 hours), and is listed in > both the category "Software/Graphics/Drawing" and in the What's New section, > http://www.linuxlinks.com/New/ Thanks. > To keep our database accurate we would appreciate it if you would let > us know of any changes to your listing, including any change in URL. > > If you would like us to announce new versions of Inkscape please > send information to announce@...86..., or alternatively you can post > details at our Linux news service, http://www.linuxlinks.com/portal/news/submit.php Okay, I've added 'announce@...86...' to our announcement list. > If you haven't already done so, you are more than welcome to add a > reciprocal link to us. I've added LinuxLinks to our Links to Us page. http://www.inkscape.org/cgi-bin/wiki.pl?Links_To_Us Thanks, Bryce

1 0

Re: GIMP user interface discussion
by bulia byak 29 Nov '03

29 Nov '03

> > I have never heard before about "the utility window type hint". > > It is defined in the Free Desktop window manager specification. IIRC > the KDE window manager claims to adhere to that spec: > > http://www.freedesktop.org/Standards/wm-spec It may be aware of it internally, but there are no configuration controls available to the user. Most importantly, I cannot set utility windows to stay on top within their app or be hidden on the taskbar. The freedesktop specification is bright and wonderful, but looks like we (Inkscape) will have to use transients until that specification is better supported in WMs. (Even though transients have their problems, too.) > > For example, if you add a third option, "transient", to the "window > > type hints" list in Preferences and make that the default (both for > > toolbox and for docks), I think the default Gimp will behave in a > > more expected way for the majority of new users (while remaining > > usable for those who prefer another behavior.) > > Transient implies a parent and there's no parent window the toolbox or > docks coule be transient for. Wrong. First of all, when a dock "follows active image", I see no reason why the active image cannot be considered its parent. And when you switch images, re-transientizing all docks to the new active document window actually works pretty well. Test the Inkscape CVS to see what I'm speaking about. And second, even when a dock does not follow active image, it is logical to consider all open document windows a "collective parent" for all docks, so that docks and toolbox stay on top of the topmost document. This is what we're doing in Inkscape, and the feedback has been very positive so far. Which is understandable, given that our approach is a good approximation of what Windows/Mac users come to expect. (And if you feel your document is cluttered with dialogs, we'll soon have a global key that toggles all dialogs and toolbars off and on.) Which brings us to the point, do you want to really win user share from commercialware? After all, in many cases what is required is just change a few defaults, and I don't see any reason not to do that because it won't affect power users who have their preferences set differently anyway. > > I noticed that menu option and it was indeed on, but it did not do > > anything for me. As I now see, there's one more thing I had to do: > > "Activate the focused image" in Preferences must be on. Please make > > that setting on by default, too. > > We discussed this recently on the mailing-list. And the outcome so far > was that the default should be off since it is almost possible to work > with this setting with a window manager that does focus-follows-mouse. First, I may be missing something but I have just tested "Activate the focused image" with "Focus follows mouse" in KDE, and it's very convenient. I see no problems with taht so far. Second, users coming from Windows or Mac will never have "focus follows mouse" set. This is counterintuitive for them. Those who use this setting are more likely to be power users, and power users will be able to configure this in Gimp as they see fit. > Please note that all it changes is the behaviour when you click the > window decorations. There are other ways to activate an image. Not only click. Many use alt-tab as the primary way to switch windows. > > Sure, but zoom keys are the first any user will try to use, why not > > make them more convenient by default? > > It's a convenient setting for most users and it is a logical binding > as well. Surely a lot better than '='. Have you done usability tests with newbies? Do you think they will be relieved to know that zoom out is a no-shift key while zoom in needs a shift? Why argue when we can just test? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: GIMP user interface discussion
by bulia byak 29 Nov '03

29 Nov '03

Hello Sven, Thanks for taking time to answer my comments. I hope you don't mind if I cc my response to the Inkscape list. As I wrote, I only spent one day playing with the new Gimp and did not claim to be able to discover everything it's capable of doing. I'm glad to hear Gimp is so configurable, however the first impressions are important, and maybe you can use the feedback of the fresh-eye, first-time users to change some defaults. > The majority of palettes (dialogs) are still not transient and > "sink" readily when you switch to the document window that overlaps > them. Working with a maximized document window is therefore next to > impossible. Some of the dialogs/palettes are transient, though - I > think it's those that can only apply to the current document and are > more or less "modal", i.e. you cannot do anything on the canvas > while such a window is active (examples are Levels, Color balance, > etc.) Making such modal windows transient is indeed a step in the > right direction, as in Gimp 1.2 even they could be buried easily > (and confusingly for most users). However, having to dig out my > primary toolbox from under a pile of windows still drives me crazy. > > Some people prefer the toolbox and the docks to stay on top, others > hate this. So it's up to you to set the utility window type hint in > the GIMP perferences and to configure your WM to keep these windows on > top. Most window managers seem to handle utility windows like this by > default. I have never heard before about "the utility window type hint". My KDE (3.1.3) does not seem to be aware of such windows at all, I don't see how I can configure that. If you use the hint that most WMs are unaware of, you must either bug the WM developers to implement it (the high profile of Gimp does give you some power to do that, IMHO) or offer some better supported ways to do the same. For example, if you add a third option, "transient", to the "window type hints" list in Preferences and make that the default (both for toolbox and for docks), I think the default Gimp will behave in a more expected way for the majority of new users (while remaining usable for those who prefer another behavior.) > The main toolbox is also exempt from docking. This means that > although you now have a way to reduce the number of windows on your > desktop, you still have at least three windows (document, toolbox, a > group of docked palettes) that you'll have to alt-tab your way > through. > > That is simply wrong. You can dock to the bottom of the toolbox just > like to any other dock. The only difference is that the toolbox > doesn't offer an image menu. We suggest to dock the tool-options to > the toolbox but it's up to you to configure your preferred setup. Indeed! However, unlike tabs, I could not drag-and dock the toolbox to another dock, which is why I did not realize how it can be docked. That is, unlike tabs, you cannot grab the toolbox at an empty menubar space and drag it to another dock. Also, there's no way to add a toolbox to a dock via the "Add tab" menu. I think the interface must be consistent: if the toolbox is dockable, it must behave exactly like all other dockables. > Weirdly, the single-letter keys for switching tools only work in the > document window. > > We hope to get the problem of the global accelerator table sorted out > before 2.0. Things will definitely become a lot better with the UI > manager that will be part of GTK+-2.4. So GIMP-2.2 is supposed to > have a much better global handling of shortcuts. Glad to hear that. It's important. In Inkscape, global keys really work everywhere now, while in Gimp, I cannot even press Ctrl-q to exit if I'm inside a dock! > The palettes are so "independent" that they don't even care to track > the current document. Switch from one document to another and watch > your Layers palette, for example. Does it show you the layers of the > new document? Nope! You have to use another palette called Images to > select what document is being displayed. > > That's simply not true. You can set each dock to "Auto Follow Active > Image" in the dockable menu and it will update with the active > image. If you add an image menu, there's that "Auto" button next to it > which gives the same functionality. Please note that this is the > default configuration that The GIMP will start with when it is > launched for the first time. I noticed that menu option and it was indeed on, but it did not do anything for me. As I now see, there's one more thing I had to do: "Activate the focused image" in Preferences must be on. Please make that setting on by default, too. Still, even with "Auto follow", I see no way to move focus from a dock to the active image using keyboard. > Zoom shortcuts are inconvenient. "-" on the keyboard zooms out > without shift, but to zoom in I have to press "+" with shift. Keypad > - and + do not work at all. > > It may be inconvenient on your keyboard layout, but why don't you > reconfigure it then? Go to the Prefs dialog and enable "Dynamic > Keyboard Shortcuts", hover your mouse over the Zoom menu entry and > press your favorite key. Sure, but zoom keys are the first any user will try to use, why not make them more convenient by default? > Fullscreen mode is actually designed as a way to view your document > w/o any distracting user interface elements. It's not supposed to be > used for editing. However since some people prefer to do the latter, > you can configure the fullscreen appearance of the image window in > Preferences. If you follow my advice to set the utility window type > hint, your toolbox and docks should also float on the image window in > fullscreen mode. Wonderful, but see above on the "utility type hint". -- bb -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: Menu layout feedback [Re: [Inkscape-devel] Snap to grid]
by bulia byak 29 Nov '03

29 Nov '03

> I'd be prepared to write a few simple introductory pages to get things > started, explaining Vector versus Raster graphics for one thing. But that one is already written by me :) Thanks for reminding me, I just put it up on Wiki (replacng Sodipodi by Inkscape - it was written for Inkscape originally). Feel free to edit, or add more documentation :) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Object and XML trees
by MenTaLguY 29 Nov '03

29 Nov '03

Just a quick note ... I think tomorrow (or later today, after I get up, depending on your timezone) I will start work on an object ("layers") view, and a reworked XML view. The plan is to have both of the new views derive from SPView and their corresponding widgets derive from SPViewWidget. -mental

1 0

ANNOUNCE: New Scribus Website
by Peter Linnell 29 Nov '03

29 Nov '03

Hi all, I wanted to announce a complete redesign of the Scribus website. Many thanks to Craig Bradney for helping set this up and nurturing my newbie php skills. We still have a few tweaks to make, but its up and running. www.scribus.net or www.scribus.org.uk There is also a nice surprise waiting on the front page... Scribus complements Inkscape by importing most Inkscape created SVG when saved as "plain SVG" and exporting it to print, PDF or EPS. Scribus also supports CUPS directly for enhanced printing support including the CUPS-Gimp-Print Drivers. Enjoy, Peter

1 0

Re: [Inkscape-devel] saving files
by Robert Crosbie 28 Nov '03

28 Nov '03

>On Thu, 2003-11-27 at 19:29, Robert Crosbie wrote: > > I have fixed the problem with the save dialog dropping back a directory >each > > time you "Save as", but it seems the system module is not saving the the > > docname, docbase and a lot of other attributes to the file. This means >that > > inkscape keeps prompting you for the file name to save as every time you > > save. > >The problem appears to be that the first time a file is saved, the "pure >SVG" output module is being used instead of the "SVG with extensions" >module (meaning no inkscape: or sodipodi: attributes are saved). > >I'm not sure why this is yet... it's causing all sorts of problems. > >Ted, any insights? > >-mental Yeah, I figured this out after my last post. Perhaps, even in "pure SVG" mode we could still store some important attributes, like docname and modified. Do we really need docbase? Couldn't it be determined from docname? docname always seems to have the complete path for me. I'm a big fan of having minimal, clean svg. Cheers, Rob. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

Re: [Inkscape-devel] DOM SVG Canvas
by Ian Grant 28 Nov '03

28 Nov '03

> Yes Inkscape does have such an internal structure. A few months ago > Mental had begun work on breaking this out into a separate SVG Canvas > but I don't think the work reached a completion point. Does this mean it will be C++ classes? -- Ian Grant, Computer Lab., William Gates Building, JJ Thomson Ave., Cambridge Phone: +44 1223 334420

3 2