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 typethe 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 theapplication 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 thereforeclosing 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 editinformation, 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 toclose 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 wecould 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