Hi,
some time ago I thought it would be nice if dialogs could be _toggled_ (as opposed to only be shown) by their corresponding keyboard shortcuts. This is especially true with the new dockable dialogs (great improvement, by the way, in case I haven't mentioned it yet :)) because they don't respond to Ctrl+W any more so that they closing them is only possible by using mouse clicks, not the keyboard alone.
I tried to implement toggling but have two small questions:
- What is the right entry point in the code? Should this be done in the DialogManager::showDialog() function? In this case, is there already a way to test whether a Dialog is currently visible, or do I need to add a new boolean variable to the Dialog class?
- When a dialog is invoked for the very first time after startup, it seems to be present()-ed more than once so that a check for the dialog's visibility wrongly indicates that it is already being shown (thus in order to initially show a dialog, its corresponding shortcut needs to be pressed twice, which is annoying and inconsistent). What is the reason for this? And is there a less cumbersome way to circumvent it than introducing yet another boolean variable just to check whether the dialog was already shown before?
Thanks for any hints, Max
On 9/10/07, Maximilian Albert <Anhalter42@...173...> wrote:
Hi,
some time ago I thought it would be nice if dialogs could be _toggled_ (as opposed to only be shown) by their corresponding keyboard shortcuts. This is especially true with the new dockable dialogs (great improvement, by the way, in case I haven't mentioned it yet :)) because they don't respond to Ctrl+W any more so that they closing them is only possible by using mouse clicks, not the keyboard alone.
I'm still not convinced about the toggle behavior. Yes, Ctrl+W does not work - but this only means it should be fixed :) Similarly, the code must be fixed to move keyboard focus to the dialogs when you call them, and to move it back to the canvas when you press Enter in a field or click a button (there's a special callback for that which I added long long ago, but currently it fails because the docked dialog is not a top-level window).
After this is fixed, working with dialogs will be much the same as before:
strl+shift+f open dialog or give it focus if already open
strl+shift+f ctrl+w close specific dialog
F12 show/hide all dialogs (still works, and even hides dock!)
bulia byak schrieb:
After this is fixed, working with dialogs will be much the same as before:
strl+shift+f open dialog or give it focus if already open
strl+shift+f ctrl+w close specific dialog
Ah, so before the dockable dialogs feature was introduced pressing the same keyboard shortcut twice used to make the dialog disappear again? I am sure I tried that more than once in the past but it didn't work.
Of course, all things you mentioned should work as before. But since pressing the shortcut when the dialog is already open doesn't have any effect (at least that was my impression), I considered it useful to provide it as an additional way to hide it again. I for one am always a (tiny) bit annoyed that I am forced to do some finger gymnastics and use a separate keyboard shortcut to close dialogs (especially if I just want to quickly check the value of some preset in a dialog and then close it again). Of course I can certainly live without this feature, but I believed it wouldn't do any harm (since you wouldn't use the shortcut anyway if the dialog is already open). But if people don't want it, I'll just leave it as it is.
Max
On 9/10/07, Maximilian Albert <Anhalter42@...173...> wrote:
strl+shift+f open dialog or give it focus if already open
strl+shift+f ctrl+w close specific dialog
Ah, so before the dockable dialogs feature was introduced pressing the same keyboard shortcut twice used to make the dialog disappear again? I am sure I tried that more than once in the past but it didn't work.
No. strl+shift+f opens it, and if it's open, moves focus to it. Then ctrl+w closes it.
Of course, all things you mentioned should work as before. But since pressing the shortcut when the dialog is already open doesn't have any effect (at least that was my impression),
It used to move keyboard focus to it, and this should be restored.
anyway if the dialog is already open). But if people don't want it, I'll just leave it as it is.
I'm not saying I'm completely against it. The docking change is profound, and I'm not yet sure of all the ways in which it will change the workflow. Maybe we'll end up with the toggle behavior after all. But for now, at least in my work, moving focus to an already open dialog is a much more frequent action than closing a dialog, so it makes sense to use one key for the former and two keys for the latter.
bulia byak schrieb:
No. strl+shift+f opens it, and if it's open, moves focus to it. Then ctrl+w closes it.
Okay, got it. I completely agree with you that if the focus is away from a dialog then pressing the shortcut should move the focus to it. So I should have been more clear in my "mission statement": Would it be possible to use the same shortcut for closing if the dialog is already visible _and has focus_? At least that's precisely what I wanted to achieve before dialogs were dockable. I must admit that I'm not sure how intuitive this would be for the casual user in the case of a docked dialog (although I personally would still find it useful, and it's certainly as intuitive as Ctrl+W having two different "meanings", namely closing the document/closing the dialog, depending on the focus).
BTW, only now I realized that dialogs have differently colored "captions" depending on the focus. Am I the only one to find it slightly irritating that unfocused dialogs are darker? To me, unfocused has a connotation of "less visible/less apparent" or even "more diffuse", so if I had to make a choice I would reverse the shading. But it's really more a matter of which alternative I find less unintuitive rather than a strong plea for one of them. :) (Please don't get me wrong, though - it is a necessary and very useful feature; it's just that I always need a second or two to deduce from the shading whether a dialog has focus or not).
Max
P.S.: Gustav, many thanks for your fixes regarding Ctrl+W and the doubled call of present().
On 9/10/07, Maximilian Albert <Anhalter42@...173...> wrote:
Okay, got it. I completely agree with you that if the focus is away from a dialog then pressing the shortcut should move the focus to it. So I should have been more clear in my "mission statement": Would it be possible to use the same shortcut for closing if the dialog is already visible _and has focus_?
It's an interesting idea, but I'm afraid it will be an unexpected and unexplained weirdness for a lot of people who pay no attention to the keyboard focus.
BTW, only now I realized that dialogs have differently colored "captions" depending on the focus.
Well, it's because it is that way only since about an hour ago :)
Am I the only one to find it slightly irritating that unfocused dialogs are darker? To me, unfocused has a connotation of "less visible/less apparent" or even "more diffuse", so if I had to make a choice I would reverse the shading.
I agree, I would like to have the colors swapped, too.
bulia byak schrieb:
It's an interesting idea, but I'm afraid it will be an unexpected and unexplained weirdness for a lot of people who pay no attention to the keyboard focus.
I agree reluctantly. :) Although I expect the different behaviour of Ctrl+W to have a similar irritating effect to those people. But it is probably right that pressing Ctrl+W at some point in the workflow is more uncommon than Shift+Ctrl+F, say. Then again, the dialog would only be closed by the shortcut if it's already visible and has focus, a situation in which you normally wouldn't press Shift+Ctrl+F anyway, so the unexpectedness should be reduced to a minimum. But for the reasons you mentioned I'm certainly okay with leaving it as it is, at least for the time being.
Max
participants (2)
-
bulia byak -
Maximilian Albert