- Inkscape Devel - Inkscape Mailman

Re: Bug: Number type warning in help.c
by Robert Crosbie 14 Nov '03

14 Nov '03

Ok, so I turned off digest mode. In the mean time, excuse the cut and paste below: This patch doesn't really fix the problem, it only masks the compiler warning. If gtk_window_set_default_size is expecting gints, then sp_document_width should return a gint instead of a gdouble and the document structure should store its width and height as gint. I don't have the source accessible to me right now, so I can't see how it is defined. If a width was defined that exceeded INT_MAX, then when the gdouble was cast to a gint, data would be lost. A user would see a windo much smaller than they exected being displayed. Now, the other way round is fine, you can cast away if you're going from a gint TO a gdouble. Rob, From: Jon A. Cruz <jon@...51...> Bug: Number type warning in help.c 2003-11-12 10:01 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 Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 2

keys, unsinkability
by bulia byak 14 Nov '03

14 Nov '03

I've collected shortcut suggestions from recent discussions; please see the top of TODO on the KeyboardShortcuts wiki and comment/add as appropriate. There's also a new proposal on keys for editing control points in node editor. Has anyone tested the unsinkable dialogs (toolbox and ctrl-shift-f)? Use the UnsinkableDialogs page to report. -- __________________________________________________________ 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

Re: [Inkscape-devel] two patches
by Robert Crosbie 13 Nov '03

13 Nov '03

>I've activated CVS access for you as well as permissions in the tracker. >You can now take ownership of bugs and feature requests directly, and >help review/integrate patches. > >Bryce > Thanks! I'm also looking into the the two crash bugs regarding undo and deleting nodes. There's something not right in the SPRepr architecture. It's quite difficult to figure out the code, but now that I'm looking at the sodipodi Architecture document, it's making more sense. It seems that in the case of the of the undo, the code is not properly traversing the list and recognizing when child->next is null. I noticed there are a lot of asserts in the code. I find it actually makes it more difficult to trace problems. It think that instead of adding the asserts, the source of the condition should have been traced and prevented from occuring. Anyway, It's a good learning experience. I work with perl in my day job and haven't coded in c++ in years. Rob. _________________________________________________________________ STOP MORE 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…

2 1

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