- Inkscape Devel - Inkscape Mailman

bugs
by bulia byak 24 Nov '03

24 Nov '03

1. I fixed 842565 long ago; can anyone please test and if ok, close the bug? 2. I'd like to nominate the new 848355 as critical for 0.36. Along with the other undo bugs it's very annoying. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Mental: Toolbar changes
by T Ingham 24 Nov '03

24 Nov '03

Mental, First off, I freaking LOVE YOU!!! The convenience of having those toolbars contextually show / hide is fantastic. However there is one minor inconsistency that needs attention. When you select a tool which has no sub-toolkit, could you have the "Select" subtoolkit display, but be disabled. This would prevent the panel from resizing, and throwing the document all over the place. Alternatively, we could adjust the current location of the artboard within the canvas window, by and inverse amount to the growth / shrinkage of the panel ( but that seems entirely more complicated and no more beneficial ) Spatiality Rules! -t

1 0

Don't Panic, or "New UI code getting merged in"
by Bryce Harrington 24 Nov '03

24 Nov '03

For those of you who have not been following Mental's work, be aware that he's going to be merging it in soon - probably this evening. The new SDI-based interface feels *quite* *different* from Sodipodi. Confusingly so. Things are in very different locations than you're used to. But this is all by intent. We have discussed the CSDI / SDI technicalities, the importance of HIG compliance, the desire to work like this app or that, etc. etc. This work has been going on in a branch for the past week, with screenshots on the website for about as long, so there's been some time for early testing. We are ONLY going to know whether all this theory will work in reality if we each TRY IT OUT. Some will ask why we are making these significant changes, and that is a good question. Stated briefly there are several reasons: 1. It significantly distinguishes Inkscape from Sodipodi 2. It is in keeping with GNOME HIG standards (the Sodipodi approach isn't). 3. It has been requested by a number of Inkscape users. 4. It forces us to really rethink the UI layout, including little things that we have tended to take for granted but that need to be re-examined. 5. It's better to make the change now while the project is still young and won't disrupt a large existing user base (other than ourselves!) Regarding testing, some tips. Well thought out, fairly worded observations are what we're looking for, moreso than gut reactions. Things are still fluid at this point so well thought out comments can have an important long-term impact. Take some time with your evaluation and think about how we can make it more powerful for skilled users, and intuitive enough to help novices find their way to what they need. You will be able to check it out from developer CVS soonish, or anonymous CVS within a day or so. We also hope to cut a pre-release and RPM's to make testing easier for folks. Bryce

1 0

Re: [Inkscape-devel] Testing feedback
by Robert Crosbie 24 Nov '03

24 Nov '03

----8<---Snip--->8---- > "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 Yeah, This is the problem I was looking into Saturdy Evening. I'll be looking at it again on Tuesday or Wednesday. If anyone else wants to have a go at it, It seems to be around sp_document_undo or sp_document_maybe_done. It seems that if you undo when there is nothing to undo, the undo list doesn't get updated when you create new object. Problem is kdbg was crashing on me when I tried to set a breakpoint inside sp_document_maybe_done to see what was happening there. Cheers, Rob. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

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