- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] calligraphic lines
by bulia byak 30 Nov '03

30 Nov '03

> Does it actually do anything? I just get a spew of console output when I try to use it. > > x_order_2: colinear! > colinear! > ... Oh, and I just suggested to Bryce that we remove the "colinear" from Release Notes :) Indeed this warning is now only triggered by the calligraphic tool. As for the tool, why, it does draw nice lines and it's fun to play with. I'm not sure about its practical usefulness, but I did not play with it too much. Besides, there are some fixes for this tool in Sodipodi which we need to port over (the person who created this tool originally is now working with Lauris on Sodipodi). -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

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

30 Nov '03

> Do you really want to drop years of serious UI design work(gimp) just > because > the kde people haven't done their work yet? I never suggested to "drop" anything, only _add_. > Wouldn't it be better to > push hard for the freedesktop standard? Of course it would be better! So, are you doing it already? When can we expect to see the unsinkability option for utility windows in, say, KDE? > no offense intended, but inkscape is pretty much useless for professional work as it is right now. > Take a look at the inkscape screenshot i've made, there are 13! dialogs open. And it's just version 0.36. Please don't dodge the subject. Dialogs reorganization is in our plans (see DialogsReorganization on our Wiki), it's completely irrelevant to what I've been discussing in Gimp. > Where are you going to put them so that they're immidiatelly accesible? If i click on freehand, > i'd like to immidiatelly set the thickness or color of the curves i'd like to draw, How will i do that? See SecondaryToolbar on our Wiki. > Depending upon which tool you choose in inkscape another (sub)toolbox shows up on the top, > so it's either there or it's not, you'll end up looking at a jumping canvas which is just disturbing. Jumping already fixed. > Besides, what's the purpose of having the main toolbox on the left while having the other one on the top? It makes no sense. It makes perfect sence as they are the primary and secondary toolbars, directly linked (change tool on the primary and get all relevant controls on the secondary). This is the approach taken by (at least) Photoshop and Xara, and it's very convenient. > It's not clear which tool is selected. I guess this will be fixed when we return to the standard button widget. > The A4 rectangle in the canvas window is horribly disturbing. It helps me, but you can switch it off easily. In a next version this preference will be saved for future sessions. > > Second, users coming from Windows or Mac will never... > > If you want those users to migrate, the first thing you should do is to look at the UI of all those apps. As i said, > they all look pretty much the same, except that gimp doesn't do WiW and gtk doesn't offer that(luckily!). No, WiW is secondary. The biggest problem with Gimp is that dialogs sink. They never do in any Windows or Mac program I've EVER seen. > There's no space left for innovation here. :) > As for the transients - as long as 1.) the toolbox and the docks all behave like one group(for the purpose of minimising, > bringing forward, always on top etc), > and making the image window active switches the images/layers/channels/paths/ dock to that image, it will do a much better job > than WiW has ever done. the images should always be kept as separate objects/windows. Exactly! This is _precisely_ what we're doing in Inkscape and what Gimp refuses to do. > No ofense intended again, but you guys just installed gimp 1.3.x. toying around with it for a few hours, > it seems like it's not sufficient to realise how well designed the gimp UI really is and how efficient it is. No offence in my comments either. Just first impressions of a new user, which should be at least as valuable to a UI designer as comments from a long-time user. I ran the new Gimp and saw severe usability problems at once. You say they can be fixed by changing preferences? Great! But first, not everything can be fixed, and the biggest problem - sinking dialogs - is unfixable. And second, first-time users don't have to go into preferences; they should get the most usable and _standard_ interface by default. Sinking dialogs are not standard in any UI, sorry. > But keep in mind, that through all those years of gimp development, tons of discussions were going on regarding the UI, > so it's really a great piece of work and it just works. Why would you want to go through all that again? :) > Sorry if i sounded rude but i just fear seeing another promising project going the drain just because the > developers didn't trust something that is actually proven. Don't worry for us. We won't go down the drain, I promise :) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

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

30 Nov '03

> '+' is a shift-key for a minority of our users. Do you have any statistics to back this up? Whereas I so have some statistics in my favor. On a default install of Mandrake 9.2, grep /etc/X11/xkb/symbols for layouts containing "[ equal, plus" and those containing "[ plus". You will find 61 layouts where plus is in the shifted position and 52 of those where it's non-shifted. So the majority of layouts seems to be on my side, probably that speaks something about the majority of users too. Besides, don't you think that appealing to the majority is irrelevant here? I'm not asking you to break anything for the "majority" in order to make things better for "minority". I'm just asking to _add_ something that your "majority" won't even notice. As far as I can see, "=" is not used anywhere else in Gimp. Why not make it _another_ shortcut for zoom-in? And finally, you did not give any reasons for not making KP_plus and KP_minus shortcuts for zoom as well. For that, you have no excuses whatsoever :) > You are looking at > this with a very US-centric view. :) I've never been to US. I lived most of my life in Russia and now live in Canada. > But it is tedious to repeat these discussions that we all had on bugzilla and on the > gimp-developer list already. I am not going to argue about The GIMP user interface in > private emails. This should be done on the mailing list. No problem. I will bring it up on the Gimp list after we release 0.36 and collect more usability data and feedback on the new dialogs behavior. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Inkscape Project Status 2003-11-29
by Bryce Harrington 30 Nov '03

30 Nov '03

Inkscape Project Status Saturday, November 29, 2003 ------------------------------------------------------------------------ Much progress has been made towards the 0.36 release; in fact only a handful of tasks (mostly bug fixing and my arrowhead work) remains. The user interface of Inkscape has been completely redesigned, a heap of usability improvements added, and documentation and unit testing development is well under way. Our activity percentile on SourceForge has rarely dipped much below 99% and in fact we've been in the top 100 quite often. It is surprisingly common for an issue to be raised by a user, hashed out, and implemented in CVS within a day or two. Needless to say, the open development process has been paying good dividends. The downside to having such open development is that it's easier for new bugs to creep in, however they're getting identified quickly and added to tracking mechanisms, so we're optimistic that we can apply focus on them during feature freeze and make 0.36 at least as stable as 0.35 (and hopefully more!) Once this release is out, we will turn focus to codebase cleanup, including committing to C++ and dropping support for gcc. Next after that will come an aggressive bug hunt. These two efforts will gain us quality, code documentation, wider familiarity with the codebase, and a testing framework that will make the codebase more pleasant for developers to work in. These efforts will set the stage for a series of major architectural refactorings we will undertake thereafter. Statistics Nov 02 Nov 15 Nov 29 ========== ====== ====== ====== Lifetime Rank on SourceForge: 6103 4391 3676 (56.2%) (68.5%) (73.6%) Max Week's Rank on SourceForge: 6023 62 37 (Nov 16) (56.8%) (99.6%) (99.8%) Lines of Code in src/: 115,754 115,901 116,970 Lines of Docs in doc/: 1,135 1,135 2,100 Lines of content in website: 74 1,173 1,624 Size of the Inkscape wiki: 0 3,700 5,737 Hours since last ChangeLog mod: 90 6 2 Bugs open/total: 0/0 9/15 40/51 Features open/total: 0/0 18/18 23/24 Patches open/total: 0/0 1/ 6 5/20 CVS Commits (as per inkscape-cvs): 148 481 963 Inkscape-devel membership: 4 49 61 Inkscape-announce membership: 0 9 14

1 0

printing doubles
by Robert Crosbie 30 Nov '03

30 Nov '03

I like my svg to be really clean and I always hand tweak my drawings to make sure all objects are where I want them to be. One think i dont like is when doubles are printed like this: x="200.000000" y="200.000000" Is there are reason why we store more precision than necessary here? This value comes from sp_repr_set_double which uses sp_xml_dtoa. Doesn't sp_xml_dtoa do the same thing as printf %f formatting? I have found that if I call sp_repr_set_double_attribute and replace the "%f" with a "%g" It will give a much cleaner output: x="200" y="200" Is there a technical reason why we have a custom dtoa function and keep the extra 0's? Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Is there a gadget-lover on your gift list? MSN Shopping has lined up some good bets! http://shopping.msn.com

3 2

Snap to grid
by Jonathan C. Sitte 30 Nov '03

30 Nov '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was hoping that you developers were thinking about implementing snap to grid? Thus allowing you to move images around and have them line up in an orderly fashion. Another thing is what do you think of the current user interface? Just wondering what you were doing with that. I know that you are talking about making a layers menu. That will be real helpful. The export and save options are really archaic at the moment as well. Overall the program has allot of potential. I was using Sodipodi allot but now that I found out inkscape I really like the direction you want to take it. If there is anything I can do to help let me know. ;) - -- Jonathan C. Sitte <jcsitte@...67...> Digital Arts & Computer Technology http://www.staticnull.org/jcsitte/ 917.414.2559 M-F 8AM-10PM Public Key: http://www.staticnull.org/jcsitte/0x40E69A47-pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/uIlcbzreREDmmkcRAjR/AJ9hyQnN/cWI/4LszNhP9WAprE5r8ACgkbt+ 5R9ZLhUvqJIvtMjexw6fxm4= =9PI8 -----END PGP SIGNATURE-----

5 10

Fast compiling with both gcc and g++
by Bryce Harrington 30 Nov '03

30 Nov '03

I documented a procedure for building both gcc and g++ copies of the codebase from the same cvs checkout. http://www.inkscape.org/cgi-bin/wiki.pl?CompilingInkscape (Down at the bottom of the page) I would highly encourage developers to adopt an approach such as this, so you can help detect and avoid g++ compilation errors. Bryce

1 0

Updated main roadmap
by Bryce Harrington 30 Nov '03

30 Nov '03

I've gone over our long-term roadmap and revised our list of milestones based on where it appears folks want to go. http://www.inkscape.org/roadmap.php M2 - I'm relabeling our current focus from 'features' to 'Interface Redesign' since between Mental and Bulia's efforts, this has been the lion's share of the effort. M3 - Since there wasn't any issues raised to my proposal to make the next release focus on the C++ and codebase cleanup work, I've formalized that as our next priority. As well, I've tentatively listed the layer dialog as the Gtkmmification objective. M4 - For milestone 4, I'm taking the suggestion of focusing on doing a bug hunt, as it really sounds like we need it. Of course, this doesn't mean we should put off bug fixing until this milestone, but rather at this point we should each set aside our feature implementation efforts in favor of focusing on clearing the bug queue. I think by tag-teaming the bugs all together, it'll be much more enjoyable than just tackling them as they sufficiently annoy us. ;-) Additionally for M4 I've committed us to doing a codebase-wide implementation of Mental's new unit testing framework. Doing it at M4 should give us enough time to get that framework well-tested. I figure doing this in parallel with the bug hunt will be synergistic and will readily leverage each other's work. M5 - Gtkmmification M6 - Plugin System M7 - New features. I figure with the new plugin system fresh out of the shop, focusing on implementing features will give it a good road test. M8 - STLification. M9 - Extract SVG Canvas.

1 0

Re: [Inkscape-devel] New win32 cvs build]
by bulia byak 30 Nov '03

30 Nov '03

> Concise descriptions or hints. Good point, I reviewed all tooltips and edited many of them. > Suggested addition to the view dialog. In the real drawing world the "fit > page in window" view is extremely useful. Equally useful is the view "fit > page width in window". This is especially so since much work is done in > portrait mode. Done, there's now a menu command to fit to page width. Someone has to draw an icon for it, then it can be added as a button. Feel free to suggest a keyboard shortcut too. -- ___________________________________________________________ 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 30 Nov '03

30 Nov '03

> 1.) Inkscape Menu - I agree with Bryce in that it should totally be > removed Agreed > 2.) Secondary Toolbar + Annoying Canvas Moving - I really think that the > secondary toolbar should never go away. Exactly, just leave it empty if there's nothing to show there, but I think ultimately all tools will have some secondary controls to put there. > Also, I think that the tools in the secondary toolbar need to be > differentiated as options extending from the primary toolbar's selected > tool. One way to do this might be to give more space on the left of the > secondary toolbar. Maybe the secondary toolbar should have a darker gray > underneath the buttons, or should be a smaller size. I think space at left plus some spacing between buttons plus, if possible, smaller button size on the secondary toolbar will do. > 3. Tool from Toolbar, Selection Not Obvious - It is not obvious once a > tool is selected that it is selected, visually. Not a problem for me, maybe try a different gtk theme? > 3.) Editing Nodes - When selecting objects and nodes in illustrator and > other programs, you usually can constrain whatever is selected by > pushing the shift button. Then when you move the items selected, they Sure, this is in Wiki already. Please view the KeyboardShortcutsToDo page and leave your comments there. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

GNOME HIG menubar
by MenTaLguY 30 Nov '03

30 Nov '03

Due to popular demand and sensible arguments, I've reverted the menubar to conform to the GNOME HIG. -mental

1 0

Re: [Inkscape-devel] [Fwd: Re: inkscape]
by bulia byak 30 Nov '03

30 Nov '03

> A good idea would be to talk to the gimp developers and work > together on UI usability issues in the future, the results would > be included in next revisions of HiG for similar types of apps. I agree with most of Marek's comments. In particular, the monster multisection toolbox is already removed in the latest CVS. As for working together on usability, I'm all for that! So... Today I finally tested the latest development Gimp (1.3.23). Below are my impressions focusing on my area of interest in Inkscape, with my view on what is good and what is bad in Gimp (and what we should or should not borrow). Just a few first impressions, I did not do in-depth testing. Probably I'll have more to say after I've used it for some time. Feel free to forward this to a Gimp list (drop me a note if you do so, so I could track responses). Summary: Sure the new Gimp is impressive. And MUCH more usable than 1.2. But in the usability department, there are still things I strongly dislike. I do not want to say they are necessarily errors, since this is subjective, but I think there are other people out there who would agree with me on at least some of the points below. The majority of palettes (dialogs) are sill 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. Dockable tabs/palettes are cool, no arguing about that. However, they only dock to each other and not to a document window. 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. On the plus side, all floating palettes remember not only position but on/off status and all docks across sessions: when you restart Gimp, it reopens all the palettes it had opened last time. I wonder if we have to do the same in Inkscape (currently only size and position of dialogs is remembered). Weirdly, the single-letter keys for switching tools only work in the document window. When you have focus on the toolbox, you cannot press "t" to switch to text tool, even though the tooltip at the text tool button suggests that you can! This is despite the fact that tools seem to be global, i.e. you cannot have different tools active in different document windows. Similarly, I cannot press crtl-z to undo an action that I just did in a palette (e.g. trashing a layer); I must switch to the canvas (and remember, it's my reponsibility to select the correct document window, if I have several open!) and press ctrl-z there! I think this is another example where the idea that palettes are standalone non-transient windows in their own right plays bad for usability. 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. Moreover, the Images palette only affects those palettes that are docked together with it - if you have e.g. a Layers palette and a Path palette in two different floating windows, you'll have to add an Images palette (or an Image menu) to _both_ these windows and switch images manually in each of them. I think this is very inconvenient. A much better solution is what is being implemented in Inkscape: all floating windows always reflect the active document (i.e. the one whose window has focus). Also, they are re-transientized to the active document when you switch document windows - this means they always stay on top, but are minimized when the _last_ document window is minimized, are restored when _any_ document window is restored, and do not clutter the taskbar. Another problem with Gimp's palettes being too independent is that you can't leave them using keyboard, because a palette does not know who to give focus to. That is, you can pop up a Layers palette from within a document window using keyboard (ctrl-l), but you can't go back using keyboard except with the help of your window manager (e.g. alt-tab). So if, for example, I have edited some value in a text field in a palette and press Enter, it does affect one of the documents, but the focus remains within the palette and the affected document does not pop up if it's buried. Esc also does nothing within a palette. Moreover, there's even no keyboard way to close a floating palette - Ctrl-w only works in a document window but not in a palette (why?). (By contrast, in Inkscape, Ctrl-w closes a floating dialog, Esc moves focus from it to the document that it's currently reflecting/affecting, and so does Enter in text fields.) Misc small things: 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. Distance measurement tool snaps to horizontal if used with ctrl and to verticals if used with alt. More convenient would be using ctrl only to snap to closest n*step angle where step can be set in preferences (e.g. 45 degrees). (This is what we're going to do in Inkscape.) In fullscreen mode, no floating palettes can be seen. If I switch to them by alt-tab, I don't see my document window anymore! I switch back to document and the palettes are hidden again. P.S. Regarding our recent discussion of Gtkmm/Glade, Gimp seems to use what we use now, i.e. plain C. Does this mean that if we switch to Gtkmm we won't be able to borrow code, such as dockability, from Gimp? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

3 3

Bugs
by Bryce Harrington 29 Nov '03

29 Nov '03

The Sodipodi bugs numbered between 775385 and 830500 that I could verify have been copied into the Inkscape tracker. I was able to verify about half of them. Only one was super critical and in need of being fixed immediately (IMHO). To do this I used a spreadsheet. I listed the numbers of all the bugs, then as I had time I went through each, one-by-one, to check them against Inkscape. Once that was done I created new RT tix for the validated ones. I've put the spreadsheet in inkscape/doc/ in case someone else might like to use it. Bryce

2 1

[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

[Fwd: Re: inkscape]
by MenTaLguY 28 Nov '03

28 Nov '03

-----Forwarded Message----- From: Marek Peteraj <marpet@...83...> To: MenTaLguY <mental@...3...> Subject: Re: inkscape Date: Fri, 28 Nov 2003 16:33:14 +0100 On Thu, 2003-11-27 at 08:52, MenTaLguY wrote: > On Tue, 2003-11-25 at 11:40, Marek Peteraj wrote: > > Hi Mental, > > > > i just learned about inkscape, seems to be a very cool project, and as > > i'm not subscribed to the mailing list yet, i'd like to make a few > > suggestions: > > (sorry for the belated reply; I've been buried in mail) np :) > May I have your permission to forward your message to the Inkscape > mailing list? Yes of course, you can also forward this one. > I hadn't seen a recent version of the GIMP for some time; > I wasn't very > impressed with it the last time I used it, but it looks like they've > made some major changes to the UI. I'll have to work with it some more > soon and get a feel for what's new. Check out the latest release(iirc 1.3.22, i'm still on .18) and take your time to organize and dock your dialogs and toy around with it to get the feel of the UI :) Also see my gimp screenshot. Also i've made an inkscape screenshot to demonstrate why the gimp UI is so efficient(i'm a heavy gimp user, it's my everyday tool so to speak, it's been like that since 1.0 versions) Everybody bashing the gimp UI please forget 1.2 :) and check out the latest release of the 1.3.x development cycle, toy around with docking and reorganizing dialogs. So here it is: http://www.pleasewipeyourfeet.com/webtest/pr/inkscape.jpg In apps such as gimp and inkscape, tools and tools options/settings need to be accesible immidiately. Gimp solves that issue by providing a combined dock/tabbed interface. You click on a tool in the toolbox and the appropriate options appear in the tool options dialog, so there are general tool options dialogs which is bound to the toolbox. http://www.pleasewipeyourfeet.com/webtest/pr/gimp.jpg see the brush tool selected in the toolbox on the left, the brush tool options bottomright. The options in inkscape are accesible only through a menu, and thery're not dockable in any way which leads to a mess (13 dialogs open!). Gimp 1.2 suffered from the same problem. Gimp tends to organize the tools and options very efficiently, it seems to me that the key for designing such UI would be to determine what a tool is, isolate it and set the options for it. See the transformation dialog or the text dialog in the screenshot. Can these be tools? Of course they can :) Can Fill/Stroke or align be a tool? I think it can. Then put all those tools in a static toolbox. (and ask jimmac to make some cool stock icons :) Settings should be put else where, see gimps preferences. The toolbox should offer only drawing tools or tools closely related to drawing(as i stated in my previous mail). The current tree-like menu is a misconception and should be removed from HiG IMO. The purpose of hiding the tools should be to save some extra space and to organize tools in a logical way. 1. More nodes will introduce even more space consuption so it's not a win at all to use it for that purpose, and there are lots of tools that are not related to each other so what happens is that you make a node called 'miscelaneous' and put all those unrelated tools in there. This doesn't solve the 'break into categories' issue at all. 2. Gimp 1.3.x has introduced a somewhat shuffled toolbox(new tools added etc), and i had some hard time getting used at that. Node-like organizing introduces continuous 'shuffling' in that you always end-up having different nodes opened and closed, the toolbox changes it's size each time you expand/collaps a node. So the purpose of organizing into categories gets totally broken. 3. In a professional environment, where you need to work fast and reliable, a static toolbox is the most efficient thing you'd find. Once you learn it, it never changes. The tools need to be accesible immidiatelly, expanding and collapsing will just slow down the user and distract him from his work. Besides why would you want to toy around with collapsing/expanding when you just need a tool to work with? 4. If i want to use a tool which i haven't used yet and i'm not quite sure what it does, the category won't help me to understand that, for example "touch up" category won't explain what a smudge tool does. Stock icons should be as self-explanatory as possible, and tooltips should be used. If you still don't know and haven't managed to figure by trial&error, the manual should handle the rest. Another important point is: The C-SDI interface is a perfect replacement for a WiW like environment(window-in-window, see the screenshots in previous mail) when combined with the dock/tabbed UI and should be *enforced* by HiG for apps like gimp and inkscape or DTP apps, not considered to be removed. Compare the gimp screenshot with the other screenshots i've posted. Also once the user learns how to use one app, it's easy to learn how the other one works, which is also the purpose of HiG i guess - to unify the UI experience. A good idea would be to talk to the gimp developers and work together on UI usability issues in the future, the results would be included in next revisions of HiG for similar types of apps. There are 3 major advantages in adopting the gimp UI where possible: 1. unifying the UI in the graphics-aps domain 2. avoid reinventing the wheel, gimp has been developed since 1997(afaik) and can already be considered as a mature professional raster-based app. 3. adopting the UI from an opensource app instead of its proprietary counterparts(no WiW, docking for example). Simply put, it's time for gimp to have a professional vector-based brother :) Marek

1 0

[Fwd: inkscape]
by MenTaLguY 28 Nov '03

28 Nov '03

-----Forwarded Message----- From: Marek Peteraj <marpet@...83...> To: mental@...58... Subject: inkscape Date: Tue, 25 Nov 2003 17:40:51 +0100 Hi Mental, i just learned about inkscape, seems to be a very cool project, and as i'm not subscribed to the mailing list yet, i'd like to make a few suggestions: It seems that inkscape could become the gimp of vector graphics, that's why i think it would be really cool to design the UI to be as close to gimp as possible, since the gimp is pretty mature to date and it can already be considered as a porfessional tool for raster image manipulation. I took a look at the HiG and it's suggesting the same type of toolbox as sodipodi/inkscape offers. Honestly i must say that i *hate* that kind of organizing. :) The gimp toolbox is pretty slick and offers only drawing tools or tools closely related to drawing such as selections. The idea to organize them in collapsible "trees" seems completely broken to me since actually hiding the tools which you want to see in a toolbox, if expanded it makes the toolbox bigger, and a user that doesn't understand what each button/tool means has to learn it whether it's organized or not, the stock icons are rather self-explanatory and describe the tools in an understandable manner. So things i would suggest to avoid: 1. remove all items that aren't drawing tools or tools related to drawing, such as save as, open etc 2. avoid organizing in trees such as stated in HiG(unfortunately) 3. keep all buttons directly in the toolbox, hide them in pop-up colums(such as the dynahand in sodipodi) This is basically what gimp does. Next thing i'd like to suggest is to organize features in dialogs that are either dockable or organized in tabs. I've collected a few screenshots when i wanted to look at how all apps manage their features and functions. If you take a look at all of them, you'll find that they all look pretty much the same, dialogs on the right, toolbox on the left. Except that *only* gimp doesn't do WiW(window in window). And *only* gimp does provide a reasonable way to manage a lot of dialogs, namely 1) docking them and 2) organizing them in tabs. Gimp does manage tool/functions very carefully, it provides a UI model that is perfectly customizable, and groups features and functions in a clever way. http://www.pleasewipeyourfeet.com/webtest/pr/gimp.jpg http://www.pleasewipeyourfeet.com/webtest/pr/scribus.jpg http://www.qmedia.co.za/image/screen32791.jpg http://www.activewin.com/reviews/software/graphics/adobe/illustrator10/imag… http://www.suse.de/en/private/products/suse_linux/winerack/images/photoshop… http://www.activewin.com/reviews/software/graphics/adobe/pagemaker7/images/… A very important thing to consider here is whether to design the UI of those apps to be as close as possible to each other. This is perfectly possible since only gimp is a mature app to date and it's an app which provides an even more clever ui than it's proprietary counterparts. If we had 2-3 powerful apps that would create a professional linux graphics studio they would probably be: * gimp for raster image editing, photo retouching * inkscape for vector image editing * passepartout for DTP (it's in early devel stage currently so i can't tell right now) Keeping their UIs as close as possible is the key to build a pro linux graphics studio since the user isn't forced to get use to another type of ui. :) Marek

1 0