- Inkscape Devel - Inkscape Mailman

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

0.36
by bulia byak 23 Nov '03

23 Nov '03

1. My current status: working on the remaining keys I wanted to enable for 0.36 (esc in the node editor, etc.) 2. Dialog code is finished, but: 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. 2b. The rest of dialog improvements seem to work OK (keys, titles, remembering position) although nobody yet commented. I think I'll go on and copy the code to all dialogs. 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! 3. Thanks to Robert Crosbie for fixing the save crash, but I think the remaining problems he reported are critical and must be fixed before 0.36: > - autodetect fails if no extension is added to filename (.svg) > - on quit, still says I have unsaved changes, even though I saved > - can't open compressed svg unless it has .svgz extension. especially the second one. Please add them to the tracker and/or roadmap. 4. When a consensus is reached on which keys to use for moving to front/back, please add this to the KeyboardShortcuts TODO and I'll implement that. My opinion: f/b with ctrl or shift are clumsy (although this is what Xara uses), and please don't use [] because I plan to use them for rotation (this is consistent with gqview and I think other image viewers). Maybe Home/End with ctrl will work for moving one layer up/down? They appear intuitive for this task. 5. I have no opinion on the mouse scroll modifiers (I have no mouse wheel), but again, when you agree on something please add that to KeyboardShortcuts. 6. I also plan to finish my HandlingPreferences tutorial and comment on some other new pages on Wiki when I have a little time. 7. I noticed I forgot to update Changelog with my changes all this time - sorry! I've prepared a list of everything I've done and will add it now. --bb -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: [Inkscape-devel] transformation innaccuracies
by Bryce Harrington 23 Nov '03

23 Nov '03

Hi Robert, Could you submit this as a bug report? Thanks, Bryce ---------- Forwarded message ---------- Date: Thu, 20 Nov 2003 20:28:21 -0500 From: Robert Crosbie <swingincelt@...19...> To: inkscape-devel(a)lists.sourceforge.net Subject: [Inkscape-devel] transformation innaccuracies I noticed the transformations applied to objects is quite inaccurate: <rect width="200.000000" height="200.000000" x="100.000000" y="100.000000" style="font-size:12;fill:#808080;fill-rule:evenodd;stroke-width:1pt;" id="rect562" /> Opening the transformations dialog and applying 10 horizontal gives this: <rect width="200.000000" height="200.000000" x="112.500000" y="99.9999695" style="font-size:12;fill:#808080;fill-rule:evenodd;stroke-width:1pt;" id="rect562" /> Also, If I take that original square and rotate it 10, I get this: <rect width="200.000000" height="200.000000" x="62.2319183" y="131.691177" transform="matrix(0.984808,-0.173648,0.173648,0.984808,0.000000,0.000000)" style="font-size:12;fill:#808080;fill-rule:evenodd;stroke-width:1pt;" id="rect562" /> Why have my x and y changed? Shouldn't the matrix handle all aspects of the transformation and leave x and y as they were? Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

mouse wheel
by Yemu 23 Nov '03

23 Nov '03

i've just updated my copy of inkscape and i have one suggestion concerning mouse wheel support. inkscape now uses wheel to move vertically, ctrl+wheel to move horizontally and shift+wheel to zoom in/out. in other applications (mozilla, opera, abiword, openoffice, corel draw) ctrl+wheel zooms (i know, i know in gimp shift+wheel zooms :-). so maybe it would be possible to have ctrl+wheel zoom? or both ctlr+wheel or shift+whell zoom, and for example alt +wheel move horizontally. one more think i noticed is a fact that when scrolling, some black horizontal stripes blink during refreshing of a document. this doesn't happen when zooming. best regards yemu

3 5