- Inkscape Devel - Inkscape Mailman

Testing feedback
by Bryce Harrington 24 Nov '03

24 Nov '03

Some feedback on Inkscape from CVS from a user: "I tried out Inkscape a bit. I was able to set the inkscape:groupmode parameter that allows me to select grouped items. I really like having that available. It doesn't seem to save the setting though." Mental - want to take a look at this one? I've asked for clarification on what he means by "save the setting". "I went to set the stroke width on a path and I couldn't type in the number. It seems to do the hotkeys instead of letting me type into the dialog (focus problem?)." Bulia - I verified this. Looks like the new number-key keyboard shortcuts are stealing focus. Could you take a look? "The undo also seems to have some problems. I was messing around with the layer selection stuff and moved an item which I then tried to undo but it didn't work. It was kinda strange because some things could be undone but not others. I kept pressing undo a whole bunch of times and it crashed." Robert - Sounds like this one feeds into your work; would you mind taking this one? Bryce

1 0

(no subject)
by bulia byak 24 Nov '03

24 Nov '03

> I'm torn between wanting to shamelessly pander to Illustrator users or > decide if doing it differently would be better enought to mitigate the > inconsistancey! Illustrator is far from being the standard. Xara, CorelDraw, Freehand, Canvas all have sizeable user communities, and as a rule they don't imitate Illustrator keybindings but do most things their own way. Besides, there's GIMP and other linux graphic soft that we must take into account. So I think in each case, we should review the existing approaches and either select one of them (not necessarily Illustrator) as the best, or devise our own. And by the way, at least global keybindings should ultimately be user configurable (it's difficult to do that for all keybindings, but at least those in shortcuts.c must be taken from the config file). -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

4 8

Re: [Inkscape-devel] misc
by bulia byak 24 Nov '03

24 Nov '03

> > - ctrl-` and ctrl-shift-` opens the toolbox > > If only one instance of the toolbox is allowed, and will always be on > top, then might it worth having ctrl-` work as an on/off toggle? The same applies to all other dialogs. Do we want to make all ctrl-shift shorcuts toggles? Advantages of toggles: - you can switch off a dialog without first moving focus to it - Illustrator behaves the same way (toggles) Disadvantages: - may be counterintuitive: I see a dialog and I want to move focus to it to use some of its widgets. Now I press e.g. ctrl-shift-f and focus is moved to the dialog. With toggles, I will have to press ctrl-shift-f twice to do the same (once to switch it off and then on again). The same situation is when one dialog obscures another: now I press the shorcut of the bottom one and it jumps to top at once, with toggles I will have to press it twice. Any comments? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: [Inkscape-devel] 0.36
by bulia byak 23 Nov '03

23 Nov '03

> > 2a. Recent reports and testing them under windows show that the > > transiency code is not perfect. Maybe we'll have to switch "unsinkable > > dialogs" off on Windows because it behaves erratic there when you try > > to minimize a document window (maybe this is GTK+ issue). I lean > > towards accepting the current unsinkable dialogs as temporary solution > > for the 0.36 release (but not for windows build), but after that I > > want to explore other options such as GIMP's dockable > > palettes. Dockability is a good thing in any case, and writing it from > > scratch is too much work; maybe they will take care of staying on top > > as well. > > That sounds like a good approach. Can you configure it to not use the > unsinkable dialogs feature for Windows compiles? Also good idea to > investigate dockability; maybe you could add that to the roadmap for > 0.37 or 0.38? Perhaps you and Mental can talk about that. OK > I compiled Inkscape from CVS and played with opening and closing > Inkscape and its dialogs after moving dialogs around. A few dialogs > seemed to remember their screen location when closed and reopened, but > not all. Sure, only toolbox and ctrl-shift-f, as I explained before > None seemed to remember their location between Inkscape > invocations. That's strange - these two should remember position and size, they do on my system. Is ~/inkscape/preferences.xml created/updated after you exit? > Also I noticed many dialogs first popped up in a corner, > whereas it probably would be better for them to pop up either > auto-positioned (if possible) or centered in the screen. OK I'll think about centering those dialogs that don't yet have saved position, but this is minor importance because this position will only be used once - after you drag the dialog to any other place it will remember it and never again pop in the center. > > 2c. I still want someone to test one small change in the transient > > behavior though. It's simple: Please compile the latest CVS/tarball, > > open two document windows, maximize both, and switch between > > them. Does toolbox stay on top? Please report also your window > > manager. Thanks! > > I've tested this on KDE (Mandrake 9.1), the toolbox does not stay on top > of the canvas windows when switching via Alt-tab. If I am switching > between a single canvas and the toolbar, though, it does. That's the problem. Here's the dillemma: - either we have it as it is now, with the problem of dialogs not staying on top when switching maximized windows (at least on KDE), - or I can fix this problem, but then we'll have another: as reported by Tom von Schwerdtner, "the document window is auto-raising itself when it gets the focus. To me this is is counter-intuitive, as every other gnome application I use follows the window manager settings of not auto-raising windows when they get the focus." I don't use raise-on-click so I did not notice this myself; with raise-on-focus everything seems to be OK. So we have to choose which of these two problems is more serious. I can think of no way to fix them both. Maybe some magic dockable windows will solve both, but the current transient windows have to choose. I don't want to make this user-configurable because that would be a rather obscure and confusing option. What do you think? > I don't have an opinion on this one and am not familiar with how it's > done in other applications, but if I were going to try to guess what the > mappings were, I'd probably try ctrl-pgup/dn, then ctrl-up/dn, then > (maybe) home/end, and finally if it wasn't any of those I'd look at the > keyboard shortcuts list. So my vote is for Home/End for top/bottom (as it is now) and Ctrl-Home/Ctrl-end for one layer up/down (instead of current pgup/pgdn). > I'll add 'make this decision' to the roadmap. Who do you think would be > a good person to make the call? (I also don't have a mouse wheel and > also don't have an opinion.) Alan, can you summarize what is the current consensus (if any)? --bb -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: Menu layout feedback [Re: [Inkscape-devel] Snap to grid]
by Robert Crosbie 23 Nov '03

23 Nov '03

> >I'd add a Help menu, even if you only have the About dialog to put there. > In the Help menu we could put a link to the sourceforge site as well as the About dialog. Rob. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 3

[Fwd: [Sodipodi-list] Comments and questions from a newbie]
by Nathan Hurst 23 Nov '03

23 Nov '03

some thoughts for checking against 0.36.

1 0

dialogs memory
by bulia byak 23 Nov '03

23 Nov '03

With the preferences restored, I've implemented remembering size and position for dialogs. Only two dialogs are affected for now, the toolbox (only position) and fill/stroke (size and position). Please test and report any problems. Finally, after this change is tested, I will copy the entire code over to all other dialogs. Preferences are now saved in ~/.inkscape/preferences.xml, instead of simply ~/.inkscape/preferences. I think it's more logical this way. A new signal was added, "shut_down". It is sent by the inkscape object before shutting down inkscape and before saving preferences, so that dialogs have the chance to write their status into the preferences. If anyone else needs to do some housekeeping before program shuts down, they may use this signal. New shortcut: * for the star tool. By the way, the number of star rays was written in prefs, and this now works. Lots of other parameters need to be similarly written and restored. I will soon update the wiki page with instructions on how to handle this. -- __________________________________________________________ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup Search Smarter - get the new eXact Search Bar for free! http://www.exactsearchbar.com/

2 1

misc
by bulia byak 23 Nov '03

23 Nov '03

Have anyone tested the unsinkable dialogs? Any comments? Just to remind you, the two dialogs I've been working on - toolbox and fill/stroke - are now not only transient but unsinkable (stay on top of the topmost document window when there are many). Also they remember shape and position within session so you can turn them off and then on again without losing your layout. (What remains to be done is an all-dialogs-toggle; I will do this shortly.) Inserting the same into all other dialogs is a boring work, and I want to be sure that these new features work perfectly with these two dialogs before I spread them everywhere. So please test heavily and report any problems or concerns. By the way, be prepared for a possible flame from Gnome developers. Here's what Havoc Pennington writes in his book: " A transient dialog is one that appears and is dismissed relatively quickly. (GnomeDialog is really meant for transient dialogs.) Some "dialogs" are just small windows, such as the tool palette in the Gimp. These persistent ("floating") dialogs should be minimizable without minimizing the parent, and they should not be forced to stay above the parent window." Which IMHO is very wrong: it does not matter how long a dialog stays open, it only matters what you do with it. A tool palette makes no sense without a document to apply these tools to, and therefore must be "transient" to stay on top. Unfortunately someone chose this wrong term ("transient" meaning "temporary") and this seems to affect many programmers who underutilize transient windows making their interfaces almost unusable (GIMP is not the only example). Also checked in today: - space switches to selector temporarily; another space switches back. This required writing a new set of functions to switch tools (tools-switch.c) but now it's much easier to do - ctrl-` and ctrl-shift-` opens the toolbox - misc fixes I may be absent for some days - need to reboot to windows to do a project in Xara/Illustrator :) Feel free to leave comments on wiki. --bb -- __________________________________________________________ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup Search Smarter - get the new eXact Search Bar for free! http://www.exactsearchbar.com/

2 1

Status
by Bryce Harrington 23 Nov '03

23 Nov '03

Below are the tasks for our current milestone. For those 20 or so of you just joining us, we're going to try to organize efforts into near-term sets of goals, that we can reasonably achieve every week or so. What we mainly need right now is to get the codebase to pass a 'make distcheck'. In addition to being able to identify any remaining things needing finished for the C++-ification and renaming, we had noticed when working on Sodipodi-hydra that distcheck wasn't passing. If anyone's interested in helping on this, it's straightforward: Get the code from CVS, compile it (with either CC=gcc or CC=g++), run `make distcheck`, and report on what needs to be done to get it to pass. Once it passes distcheck we will cut release 0.35 and create tarballs and rpms. Bryce === Milestone 1 === Inkscape Production * (DONE) Get inkscape to build with a C++ compiler [team] * (DONE) Fix CDATA issue [mental] * Get codebase to successfully complete `make distcheck` * Cut a release of Inkscape 0.35 * Upload release tarball of Inkscape 0.35 to Inkscape SF file manager Inkscape Experimental * Build a new grid options dialog using gtkmm [njh] Inkscape Website * Create logo for Inkscape [mental] * Create look and feel graphical design prototype for website [mental] * Create 3+ screenshots of Inkscape Production * (DONE) Flesh out website more fully [bryce]

6 17

SInce your forking might as well get rid of csdi
by David Adam Bordoley 23 Nov '03

23 Nov '03

One nice interface improvement you could make for inkspace would be to crap the csdi interface in favor of a sdi interface in which toolboxes and pallettes are shared in between windows. There is a gnome HIG bug in which both seth and greg merchan have agreed that csdi should be removed from the HIG http://bugzilla.gnome.org/show_bug.cgi?id=116599. Just a suggestion. dave

3 6