Hello all,
Nate suggested that it might be a good idea for me to vocalize my thoughts on a particular recent patch to Ink. I don't think that this is a bad patch at all, as it demonstrates how quickly we can change the behavior of this application, and integrate it with the source base. Not only that but it is a perfect example of how the dev plan works.
Patch now, talk later.
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. The points I am taking issue with stem from both my years of experience using Adobe Illustrator, as well as being a thoughtful user of all manner of software applications. While I don't have any reference handy to any sort of HIG on this behavior, I'm sure you'll take me on my word that using the Escape key in this manner is a "bad thing". Here's why:
#1. Intended behavior. 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. Instead of hiding the dialog, I believe that the event tree should happen in this order: - 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. This will leave the dialog in it's current position, ( which is only a problem until we figure out how to root these dialogs in a constant location ) and perform the Escape routine as expected.
#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 ) 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. 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.
#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. While I don't believe that users will often want to close dialogs such as Object Style, or Properties, there are some dialogs which 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. 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.
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. 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. I welcome any further discussion on this, as I could be totally off-base with the entire thing. I guess we really wouldn't know until we could see it implemented both ways and by then all the work would be done.
Thanks for your time and patience, -Thomas
T Ingham wrote:
The dialogs in Inkscape are non-modal, and therefore closingthem 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.
I wonder if just hiding the dialogs rather than closing them would be a better solution?
njh
The fact that the dialog loses visibility is the main problem.
On Nov 13, 2003, at 4:21 AM, Nathan Hurst wrote:
T Ingham wrote:
The dialogs in Inkscape are non-modal, and therefore closingthem 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.
I wonder if just hiding the dialogs rather than closing them would be a better solution?
njh
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 13 Nov 2003, T Ingham wrote:
<snip>
Patch now, talk later.
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.
The points I am taking issue with stem from both my years of experience using Adobe Illustrator, as well as being a thoughtful user of all manner of software applications. While I don't have any reference handy to any sort of HIG on this behavior, I'm sure you'll
Gnome HIG and Escape, search for the word escape on the following page: http://developer.gnome.org/projects/gup/hig/1.0/windows.html It describes that Escape is used to dimiss message dialogs.
Escape is usually synonymous with Cancel and I would expect Escape to cease the current task in the safest least destructive way (i.e. avoiding data loss).
My mantra will very likely become "If in doubt copy Adobe Illustrator". Consistancy is a poor substitute for well thought out Usability solutions but it is better than making whole new and unusual oddities with which to baffle users.
#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
An alternative keybinding would definately be preferable to using Escape.
If the purpose of Preview is to have the most possible available space available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
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
I would warn you that ~ appears in various different places on peoples (/nationalities) keyboards and could be quite an annoying keybinding.
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.
I think the Gnome HIG encourages the use of non-modal instant-apply dialogs, and I have difficulty imaging or remembering the exceptions where a modal dialog might be really necessary.
I welcome any further discussion on this, as I could be totally off-base with the entire thing. I guess we really wouldn't know until we could see it implemented both ways and by then all the work would be done.
Hope my comments are of use.
- Alan H.
On Nov 13, 2003, at 10:09 AM, Alan Horkan wrote:
Gnome HIG and Escape, search for the word escape on the following page: http://developer.gnome.org/projects/gup/hig/1.0/windows.html It describes that Escape is used to dimiss message dialogs.
Escape is usually synonymous with Cancel and I would expect Escape to cease the current task in the safest least destructive way (i.e. avoiding data loss).
My mantra will very likely become "If in doubt copy Adobe Illustrator". Consistancy is a poor substitute for well thought out Usability solutions but it is better than making whole new and unusual oddities with which to baffle users.
We've already assessed that these things should no longer be called dialogs, they are instant operators, I prefer palettes, but it honestly doesn't matter.
#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
An alternative keybinding would definately be preferable to using Escape.
If the purpose of Preview is to have the most possible available space available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
I was waiting for someone else to bring that up, F to enter fullscreen would be superb!
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
I would warn you that ~ appears in various different places on peoples (/nationalities) keyboards and could be quite an annoying keybinding.
Perhaps Ctrl+W then, those two keys show up in the same place on most keyboards and it's a standard on the mac to close the window ( well, command+w is anyhow ) windows uses ctrl in place of command. I can't stand that but it's gonna have to do.
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.
I think the Gnome HIG encourages the use of non-modal instant-apply dialogs, and I have difficulty imaging or remembering the exceptions where a modal dialog might be really necessary.
The idea as stated above is to make any dialog that operates on shape data a palette or "floater" or "EditBox", functions that produce radically different output ( Transformation, Filters ) could remain dialogs, and be modal, however there are many different methods to use, and I prefer having everything exist in non-modal palettes that can be anchored, or dismissed.
I welcome any further discussion on this, as I could be totally off-base with the entire thing. I guess we really wouldn't know until we could see it implemented both ways and by then all the work would be done.
Hope my comments are of use.
Totally.
T Ingham wrote:
On Nov 13, 2003, at 10:09 AM, Alan Horkan wrote:
If the purpose of Preview is to have the most possible available space available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
I was waiting for someone else to bring that up, F to enter fullscreen would be superb!
Wouldn't control-F be more standard? the only other app I know with a non-control key bound to full screen is gqview with 'v' for fullscreen View.
njh
F is the standard as far as I'm concerned.
Ctlr+F is "Find" in my head ( cmd+f / ctrl+f being interchangeable )
-t
On Nov 13, 2003, at 5:09 PM, Nathan Hurst wrote:
T Ingham wrote:
On Nov 13, 2003, at 10:09 AM, Alan Horkan wrote:
If the purpose of Preview is to have the most possible available space available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
I was waiting for someone else to bring that up, F to enter fullscreen would be superb!
Wouldn't control-F be more standard? the only other app I know with a non-control key bound to full screen is gqview with 'v' for fullscreen View.
njh
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 14 Nov 2003, Nathan Hurst wrote:
Date: Fri, 14 Nov 2003 09:09:24 +1100 From: Nathan Hurst <njh@...5...> To: T Ingham <magnethead@...17...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Escaping Dialogs
T Ingham wrote:
On Nov 13, 2003, at 10:09 AM, Alan Horkan wrote:
If the purpose of Preview is to have the most possible available space available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
I was waiting for someone else to bring that up, F to enter fullscreen would be superb!
Wouldn't control-F be more standard? the only other app I know with a non-control key bound to full screen is gqview with 'v' for fullscreen View.
Well yes and no. I just want to start by saying you are both right but in different ways. We could probably have both F and Ctrl+F.
The great thing about standards is that there are so many to choose from. And then there are defacto standards (which is definately what we are talking about here) and questions of consistancey.
Ctrl+F is usually associated with Find and I am sure that is what the Gnome Guidelines say but Find is not something most Graphics application need so taking it for a more appropriate use is of course acceptable, although in something like Dia it might help you navigate to the right text label in a really huge diagram with lots of text, but I dont think that area is a target of Inkscape just yet. (Dia .shape files are mostly SVG, I'd love to be able to point Inkscape at an arbitrary XML document that contains embedd SVG and have it try to import the SVG and ignore the rest but that is just another random idea I dont have time to work on, which I suggested to Sodipodi ages ago).
Mozila and Internet Explorer and as just about everyone else who uses a browser (a huge userbase) know to use F11 for full screen (I guess someone must have thought that F11 looks like the word Full or something). It might be worthwhile to include F11 for fullscreen _as well as_ whatever other keybinding you decide on.
The GIMP, Adobe and others all use only use single letter shorcuts for the Toolbox items which is a sensible convention and I dont see any reason why InkScape would want to break it. That is not to say that having multiple keybings/shortcuts for the same item would be a bad idea (awkward to program perhaps). It is not the case that single letter shorcuts should never be used but most applications stick to Ctrl or Alt or Cmd or Shift combined with letters because text input is their main priority and single letter keybindings just wouldn't work. For consistancey with other applications it is best to use Ctrl+Letter keybindings. It is best to avoid or at least keep to a minimum the use of Alt keybindings for portability reasons and generally keeping out of the way of the workflow for menu accelarators (Alt+F+N for example is _File, _New).
I would check a bit more thoroughly but I dont have convenient access to Adobe Illustrator. I'll try and grab a full list of the shortcuts used by Adobe Illustrator (I already made a list of most of them while listing Visio keybindings for Dia) and put it on a webpage for future reference.
Sincerely
Alan Horkan
Alan Horkan wrote:
If the purpose of Preview is to have the most possible available space
available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
To implement this, simply call gtk_window_set_fullscreen(document_window); This is a good project for someone new to the code.
njh
participants (3)
-
Alan Horkan -
Nathan Hurst -
T Ingham