- Inkscape Devel - Inkscape Mailman

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

Font fix patch
by T Ingham 12 Nov '03

12 Nov '03

This patch is taken from the fink unstable branch. Perhaps someone can evaluate it to see what it's doing? I believe Pogma wrote it. Currently I can't use fonts at all in Inkscape. -thomas

1 0

Bug: Number type warnings
by Bryce Harrington 12 Nov '03

12 Nov '03

Noticed some warnings during the build... Someone want to look into this and make a patch? Thanks, Bryce nr-rasterfont.c: In function `NRRFGlyphSlot* nr_rasterfont_ensure_glyph_slot(NRRasterFont*, unsigned int, unsigned int)': nr-rasterfont.c:318: warning: assignment to `NRShort' from `float' nr-rasterfont.c:318: warning: argument to `short int' from `float' nr-rasterfont.c:319: warning: assignment to `NRShort' from `float' nr-rasterfont.c:319: warning: argument to `short int' from `float' nr-rasterfont.c:322: warning: assignment to `NRShort' from `float' nr-rasterfont.c:322: warning: argument to `short int' from `float' nr-rasterfont.c:323: warning: assignment to `NRShort' from `float' nr-rasterfont.c:323: warning: argument to `short int' from `float' nr-rasterfont.c:326: warning: assignment to `NRLong' from `float' nr-rasterfont.c:326: warning: argument to `int' from `float' nr-rasterfont.c:327: warning: assignment to `NRLong' from `float' nr-rasterfont.c:327: warning: argument to `int' from `float' http://sourceforge.net/tracker/index.php?func=detail&aid=840539&group_id=93…

2 3

Bug: Number type warning in help.c
by Jon A. Cruz 12 Nov '03

12 Nov '03

Here's a patch for bug [ 840545 ] Number type warning in help.c Turns out that it was a very simple case. Now I'm onto bugs 840539 and 840543 Oh, and I've dusted off my Sourceforge user ID of joncruz Index: help.c =================================================================== RCS file: /cvsroot/inkscape/inkscape/src/help.c,v retrieving revision 1.2 diff -u -r1.2 help.c --- help.c 30 Oct 2003 05:52:06 -0000 1.2 +++ help.c 12 Nov 2003 17:45:34 -0000 @@ -47,7 +47,7 @@ w = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_window_set_title (GTK_WINDOW (w), _("About inkscape")); - gtk_window_set_default_size (GTK_WINDOW (w), sp_document_width (doc), sp_document_height (doc)); + gtk_window_set_default_size (GTK_WINDOW (w), (gint)(sp_document_width(doc)), (gint)(sp_document_height(doc)) ); #if 1 gtk_window_set_policy (GTK_WINDOW (w), TRUE, TRUE, FALSE); #endif

2 1

arikkei-token.c:83: `malloc' undeclared
by Bryce Harrington 12 Nov '03

12 Nov '03

I got this error when trying to build the code this evening. I fixed it by putting an include for stdlib.h in arikkei-token.c. arikkei-token.c: In function `gchar* arikkei_token_strdup(const ArikkeiToken*)': arikkei-token.c:83: `malloc' undeclared (first use this function) arikkei-token.c:83: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [arikkei-token.o] Error 1 make[3]: Leaving directory `/home/bryce/src/Inkscape/inkscape-integration/src/libarikkei' make[2]: *** [all-recursive] Error 1 $ cvs log src/libarikkei/arikkei-token.c RCS file: /cvsroot/inkscape/inkscape/src/libarikkei/arikkei-token.c,v Working file: src/libarikkei/arikkei-token.c ---------------------------- revision 1.3 date: 2003/11/11 20:03:20; author: magnethead; state: Exp; lines: +1 -2 Patches to make compile on OSX/Darwin. malloc.h replace with unistd.h and Wl in src/Makefile.am removed at --export-dynamic ---------------------------- Looks like this was introduced due to the OSX/Darwin patch. Hopefully my fix doesn't break that. Bryce

3 4