- Inkscape Devel - Inkscape Mailman

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