- Inkscape Devel - Inkscape Mailman

toolbox & misc
by bulia byak 13 Nov '03

13 Nov '03

One-toolbox-only patch is committed. Please test. Now the command to call toolbox is in the dialogs submenu. Any ideas on what key to assign it to? I tried to assign context menu to a single alt press, but this made alt-shortcuts unusable because it fired the menu no matter if any other key is pressed with alt or not. Does anyone know how to fix this? Another weirdness: I wanted to assign space to selector - it's used this was on Xara and it's very convenient. But the verb does not work with GDK_space. Looks like someone steals this key. So for now it's shift-space - this way it works fine. Thomas: Multiple instances of the program work for me, as do command line arguments. I agree that buttons should send focus to canvas, and maybe not only buttons. I will look into that. -- __________________________________________________________ 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/

3 2

Icons problem for win32
by Mael 13 Nov '03

13 Nov '03

Hello, Just for information I think I've found why some icons get broken on my win32 build Sometimes when creating dialogs Inkscape uses gtk_image_new_from_file (INKSCAPE_GLADEDIR "/icon_name.xpm"); I've specified a relative INKSCAPE_GLADEDIR ("./glade") The problem arises when you open or save a file in a directory other than the inkscape.exe root dir, This must change the current directory, and the next time you open the dialog it is created but can't find the image with the relative path Maybe this will be solved by use of GtkIconFactory .. (or dialogs created once at startup and show/hide) Concerning the interface I also found it quite inconsistent : some icons open dialogs, others are for tool selection, others are list of icons, some just perform one action (and can be clicked even if the action is impossible in the context..) etc etc.. Lot of work to do here ! good luck :) M

3 2

do we need multiple toolboxes?
by bulia byak 13 Nov '03

13 Nov '03

Do we really need multiple floating toolboxes? I think the toolbox should be treated as any other dialog, i.e. only exist in a single copy. If a user requests a toolbox for the current window, it's only created if it didn't exist, otherwise it's brought on top. This does not apply to docked toolboxes; these may exist one per document window. I think it's saner and more intuitive that way. I have a patch that implements this. As a side effect it fixes some callback problems that resulted in crashes and failed asserts when I plugged in my unsinkability code into the toolbox (and quite probably some other problems too). If there are no objections I will commit. -- __________________________________________________________ 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/

3 2

Re: [Inkscape-devel] Escaping Dialogs
by T Ingham 13 Nov '03

13 Nov '03

I believe it's due to the fact that shift+tab ( to get into the to: field and eliminate people's names, substituting them for inkscape-devel ) constantly is a character in unix ( or something like that ) Either that or shift+delete creates characters now. Try this: ( Shift+Tab five times ) Or this: ( Shift+Delete five times ) Let me know please. thanks, -t

1 0

Re: [Inkscape-cvs] inkscape/src
by T Ingham 13 Nov '03

13 Nov '03

Can I just say Kudos! This is actually the first thing you learn in building apps that conform to Apple's HIG. -Thomas ps. Opening documents from the command line isn't working for me, but it could be os related. On Nov 13, 2003, at 6:50 AM, bulia byak wrote: > Update of /cvsroot/inkscape/inkscape/src > In directory sc8-pr-cvs1:/tmp/cvs-serv28382/src > > Modified Files: > main.c > Log Message: > if no document on command line and gui mode, create new upon startup > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Inkscape-cvs mailing list > Inkscape-cvs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-cvs >

1 0

Re: Escaping dialogs
by bulia byak 13 Nov '03

13 Nov '03

> So that's what I'm here to do, in reference to the patch > which applies the Escape key event to hiding the currently > selected dialog. No problem, this was just an experiment. > When I am editing a value in a dialog, and I type > the wrong value into a text field, I would immediately think > "Escape that command" or "Revert" this results in me hitting the > Escape key, where I expect that I can then type in the > appropriate value into the text field. Instead, Inkscape will > kindly void my transaction and hide the input mechanism. This > results in me having to open the dialog again, and enter the new > value. Good point. But in fact, some of the widget (e.g. drop-down lists) will do exacly this: they will catch the Esc event and close, and the dialog itself will not close then. > - Revert any currently focused field to it's previous value. > - If no fields are currently focused, send the main focus of the > application to the Canvas window. The first point needs to be pursued with each specific widget. I'll see what can be done about that but it may take some time. The second point is easy, I just did it. Please test CVS for the ctrl-shift-f dialog and see if you like this better. Anyone's comments are welcome, of course. Another thing: all widgets, when changed, must return focus to the canvas. The only exception is a text field - it must do so too but only when Enter is pressed or the field is left (ie. the user is done editing the value). With this provision, esc-closing of dialogs may indeed become much less necessary because they will rarely if ever steal focus. > #2. Spatiality > When aiming to provide users with a consistent and > workflow-friendly interface, it is of the utmost importance that > we allow the user to decide what is placed where, and when. This > means that palettes really should respond to meta-keys at all ( > save for undo and enter for application of current edit ) "should" or "should not"? Anyway, now ctrl-shift-f already passes any keys it can't handle to the canvas. > The dialogs in Inkscape are non-modal, and therefore > closing them is not a trivial thing. It is forseeable that in the > future, a dialog such as the Object Properties window will remain > open for the duration of a work cycle. It would be used to > monitor a drag operation for placement of a shape in the current > document, as well as other utilities. Agreed. > When dialogs become not only mechanisms to edit > information, but also to view information, the location on the > screen simply *must* be maintained. Dialogs that move and > disappear are of only moderate usefulness. Sure, it's in my plans to make sure dialogs remember their position and status. It's a separate issue from closeability, though. "Hiding" and "closing" will actually be the same from user's viewpoint if all closed dialogs remember their position and status. (See the wiki page on InkscapeTamed.) > #3. Alternatives > In Illustrator, you can hide all dialogs by hitting "Tab", this > provides you with a quick device for previewing your work without > interface clutter, or maximizing your work area regardless of tool > panels. Tab again will show the dialogs that were hidden in the > last operation. I propose that we implement this with one > addition: Shift+Tab, or Shift+~ would be used for closing the > currently selected ( focused ) dialog. Good idea, I thought about it too, but not tab! Tab is used for cycling through canvas objects and it's very convenient and intuitive for that. Perhaps ` for toggling visibility and shift-` for closing the current dialog (or vice versa). > While I don't believe that users will often want to > close dialogs such as Object Style, or Properties, Or color palette. We badly need this one. Anyone can volunteer to create it? Oh no, better wait until I finish TamingTheInterface :) > operate in a near modal fashion: Transformation ( which could be > seen as a single cycle operation ) "Open Transformation > Dialog"->"Apply Transformation"->"Close Transformation Dialog" > however these sorts of operations should be grouped > together. Perhaps we could spend some time identifying which > palettes would most likely remain open, and which would be single > cycle operations, group them together, and apply different UI > characteristics for each group. Perhaps, but I still think all dialogs must behave consistently. > If those key commands are reserved, I'm sure we > could find an equally appropriate set of actions to assign to > this process. I don't think it's without cause that the patch was > applied, however I do think that we should be aiming at producing > dialogs which the user will keep open and assign locations > to. This is the sort of thing that increases productivity with > any application, without much effort from the user. Yes. > I believe that the term Dialog is being misused here, and perhaps > that is where most of the problem is coming from. To be > effective, we should class out the windows that should be > palettes apart from the dialogs. Exactly. They're called dialogs in the source and that may have unfluenced us :) Let's find some other term. It will be necessary for producing a readable documentation anyway. > We could then provide some form of modality for the dialogs that are > left, and windows would behave differently depending on what was to be > done. Do we need anything to be modal at all? I think even things like "save us" and "export" can be non-modal, and it can even be convenient even if nonorthodox from the win/mac viewpoint. But nobody forces us to exactly imitate win/mac conventions, if we can find something which is better. -- 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

unsinkable dialogs
by bulia byak 13 Nov '03

13 Nov '03

See http://www.inkscape.org/cgi-bin/wiki.pl?UnsinkableDialogs for a description of my today's update. Please use wiki to leave comments. -- __________________________________________________________ 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/

1 0

transient dialogs
by bulia byak 13 Nov '03

13 Nov '03

I've just checked in an updated dialogs/object-properties.c which makes this dialog (ctrl-shift-f) transient. This means it always stays on top of the canvas window (if there are several, it attaches to the one which was current when the dialog was created) and minimizes/maximizes together with it. What can I say? I'm absolutely astonished by how simple it turned out to be, and really baffled by the fact that nobody did it before. It's been in the Sodipodi programming tasks for ages, and it's actually just two lines of code. The difference in usability however is enormous. Judging by the fact that GIMP's interface, despite being almost universally hated, has never attempted to use transient windows (at least in the stable series, I did not try their development series) made me think that this problem is somehow unsolvable on linux - but no. At least, it works for me (on KDE 3.1). Please test the CVS HEAD with this change and report any problems you may have with this dialog (ctrl-shift-f). If there are none, I will make all other dialogs and the toolbar transient too. And by the way, the dialog can now be closed by esc - please test this too, and if there are no problems with that I will change all other dialogs likewise. Misc: I made the zoom field (in the bottom right corner of the canvas) unfocusable, so it never steals focus any more. Now arrows should work reliably. I also changed the treatment of keypad arrows - now they hopefully work both with and without shift (so far only in selector). Please test this and report any problems. If anyone can test this on Windows or Mac that would be great. -- __________________________________________________________ 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/

6 6

Re: transient dialogs
by bulia byak 13 Nov '03

13 Nov '03

Please review my writeup on transient windows and related issues: http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeTamed Comments, additions, answers welcome. Several more dialogs are transientized today. More to follow. -- __________________________________________________________ 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/

3 2

Re: [Inkscape-devel] Bug: Number type warnings
by Robert Crosbie 12 Nov '03

12 Nov '03

Similar to my last post, You will loose precision when casting from float to int or NRShort (whatever that is). In desktop-snap.c if all the code is doing is figuring out the slope, then perhaps dx? and dy? should be floats as well. What happens if the slope is less than 0.5? Would we catch it? I don't know what dx and dy are used later for, so maybe it has to be this way. When doing transformations you want to keep numbers as floats for as long as possible and only convert them to ints when they finally need to be plotted to the screen. Otherwise you loose precision and you may find that after a few rotate transformations, your object is not only rotated, it has also shifted position slightly. Cheers, Rob. http://members.rogers.com/rcrosbie >From: "Jon A. Cruz" <jon@...18...> >To: inkscape-devel <inkscape-devel(a)lists.sourceforge.net> >Subject: Re: [Inkscape-devel] Bug: Number type warnings >Date: Wed, 12 Nov 2003 11:02:47 -0800 > >Jon A. Cruz wrote: > >>Bryce Harrington wrote: >> >>>Noticed some warnings during the build... >>>Someone want to look into this and make a patch? >>> >> >>Sure. Me. > > >Here are patches for 840539 and 840543 > >(I noticed more problems, since I compile within emacs and it's easy to >search the scrollback. I'll probably get on those too) > >Index: libnrtype/nr-rasterfont.c > >=================================================================== > >RCS file: /cvsroot/inkscape/inkscape/src/libnrtype/nr-rasterfont.c,v > >retrieving revision 1.1.1.1 > >diff -u -r1.1.1.1 nr-rasterfont.c > >--- libnrtype/nr-rasterfont.c 30 Oct 2003 02:22:53 -0000 1.1.1.1 > >+++ libnrtype/nr-rasterfont.c 12 Nov 2003 18:50:17 -0000 > >@@ -315,16 +315,16 @@ > > if (nr_font_glyph_advance_get (rf->font, glyph, &a)) { > > switch (slot->type) { > > case NRRF_TYPE_TINY: > >- slot->glyph.tg.advance.x = >NR_MATRIX_DF_TRANSFORM_X (&rf->transform, a.x, a.y); > >- slot->glyph.tg.advance.y = >NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y); > >+ slot->glyph.tg.advance.x = >(NRShort)(NR_MATRIX_DF_TRANSFORM_X(&rf->transform, a.x, a.y)); > >+ slot->glyph.tg.advance.y = >(NRShort)(NR_MATRIX_DF_TRANSFORM_Y(&rf->transform, a.x, a.y)); > > break; > > case NRRF_TYPE_IMAGE: > >- slot->glyph.ig.advance.x = >NR_MATRIX_DF_TRANSFORM_X (&rf->transform, a.x, a.y); > >- slot->glyph.ig.advance.y = >NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y); > >+ slot->glyph.ig.advance.x = >(NRShort)(NR_MATRIX_DF_TRANSFORM_X(&rf->transform, a.x, a.y)); > >+ slot->glyph.ig.advance.y = >(NRShort)(NR_MATRIX_DF_TRANSFORM_Y(&rf->transform, a.x, a.y)); > > break; > > case NRRF_TYPE_SVP: > >- slot->glyph.sg.advance.x = >NR_MATRIX_DF_TRANSFORM_X (&rf->transform, a.x, a.y); > >- slot->glyph.sg.advance.y = >NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y); > >+ slot->glyph.sg.advance.x = >(NRLong)(NR_MATRIX_DF_TRANSFORM_X(&rf->transform, a.x, a.y)); > >+ slot->glyph.sg.advance.y = >(NRLong)(NR_MATRIX_DF_TRANSFORM_Y (&rf->transform, a.x, a.y)); > > break; > > default: > > break; > >Index: desktop-snap.c > >=================================================================== > >RCS file: /cvsroot/inkscape/inkscape/src/desktop-snap.c,v > >retrieving revision 1.1.1.1 > >diff -u -r1.1.1.1 desktop-snap.c > >--- desktop-snap.c 30 Oct 2003 02:20:11 -0000 1.1.1.1 > >+++ desktop-snap.c 12 Nov 2003 18:19:18 -0000 > >@@ -116,8 +116,10 @@ > >/* Determine which way a set of three points winds. */ > >{ > > int dx1, dx2, dy1, dy2; > >- dx1 = p1.x-p0.x; dy1 = p1.y - p0.y; > >- dx2 = p2.x-p0.x; dy2 = p2.y - p0.y; > >+ dx1 = (int)(p1.x - p0.x); > >+ dy1 = (int)(p1.y - p0.y); > >+ dx2 = (int)(p2.x - p0.x); > >+ dy2 = (int)(p2.y - p0.y); > >/* compare slopes but avoid division operation */ > > if(dx1*dy2 > dy1*dx2) > > return +1; // ccw > > > > > >------------------------------------------------------- >This SF.Net email sponsored by: ApacheCon 2003, >16-19 November in Las Vegas. Learn firsthand the latest >developments in Apache, PHP, Perl, XML, Java, MySQL, >WebDAV, and more! http://www.apachecon.com/ >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

2 1