GUI Window short cut preferences

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GUI Window short cut preferences

Daniel Sebald
I'm looking for feedback on the behavior of the GUI Window drop-down
menu and short cuts for manipulating the various major widgets of the
GUI.  This question is motivated by the desire to have a shortcut that
will dock/undock a window from the main GUI window.  The issue was that
in some circumstances (that hopefully rarely, if ever, arise as we get a
better handle on Qt window-decoration rules) in which the undocked
widget doesn't have decorations to control the docking of the widget.  See

https://savannah.gnu.org/bugs/?54078#comment21

for some background.

So, the goal would be to add such shortcuts but at the same time address
ways to make the manipulation of the windows much more fluent in terms
of options and shortcuts workflow.

Attached is a screenshot of the current Window drop-down menu.  There
are a couple things that I don't like about it.

1) The use of 0, 1, 2, 3, etc. to represent the various windows as far
as a memory aid.  Secondarily, the use of numbers constrains the list in
to remain exactly in the order it currently is.  I tend to think more
along the lines of associating a letter with a feature.  For example

Command Window -> C
Command History -> H
File Browser -> F
Workspace -> W
Editor -> E
Documentation -> D
Variable Editor -> V

Some key combination with that letter would be easier for me to remember
than numbers.

2) There is a secondary list Show, Show, Show, ...., Command Window,
Command History, File Browser, etc.  To me, that seems redundant and
just obfuscates my understanding of what these actions represent (i.e.,
feature overload).  At the same time, it doesn't add much functionality.
  The first group controls show/hide.  The second group brings the
widget in question front and visible (which inherently does a show if
necessary).  The difference between those is so subtle that I would
actually just prefer making the show/hide action also bring the widget
in question to the front and visible.  That is, I don't like that if I
have a visible window which I then hide and successively show again that
that window goes to the back and is obscured so is not visible.  (Try it
in the current build.)  What percentage of the time is a user going to
want to do that?  Typically what motivates a user to take action is that
she wants to see the window.

3) Sometimes the full memorization of all the windows is too much, so it
would be nice to have shortcuts that act just on the current (focused)
window.

So, how to manage all this?  I'll start by proposing a layout something
like the following:

---------------------------------
E A Command Window
E A Command History               >  ----------------------
E A File Browser                     Show      Ctrl-Shift-H
   A Workspace                        Undock    Ctrl-Alt-H
E   Editor                           ----------------------
   A Documentation
     Variable Editor
---------------------------------
     Hide Current Window    Ctrl-H
     Dock Current Window    Ctrl-D
     Undock Current Window  Ctrl-U
---------------------------------
     Reset Default Window Layout
---------------------------------

In the above, the side context menu takes the actual action.  The
Ctrl-Shift-? will toggle the Show/Hide.  The Ctrl-Alt-? will toggle the
Dock/Undock.  And the action listed in the context menu will display
either "Show"/"Hide" depending on the state and either "Undock"/"Dock"
depending on the state.

Down near the bottom of the Window menu are the shortcuts for
controlling these settings for the current window.  There's no "Show" of
course since there is no way of a hidden widget having focus.

Then, for showing the state I put in place an "E", which maybe could be
an eyeball icon (visible/hidden), and an "A", which maybe could be an
anchor icon (docked/undocked).

Is this getting to be too much info?  Does it create a bind for future
expansion (say minimize/maximize shortcuts...although I don't see those
abilities having the status of hide/show and dock/undock)?  Is there a
better approach?  Any feedback is welcome.

Dan

Window_drop_down_menu_Screenshot_from_2018-06-27_13-56-11.png (160K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GUI Window short cut preferences

Torsten-3
On 27.06.2018 21:54, Daniel J Sebald wrote:

>
> [snip]
>
> 1) The use of 0, 1, 2, 3, etc. to represent the various windows as far
> as a memory aid.  Secondarily, the use of numbers constrains the list in
> to remain exactly in the order it currently is.  I tend to think more
> along the lines of associating a letter with a feature.  For example
>
> Command Window -> C
> Command History -> H
> File Browser -> F
> Workspace -> W
> Editor -> E
> Documentation -> D
> Variable Editor -> V
>
> Some key combination with that letter would be easier for me to remember
> than numbers.

Shortcuts with letters might already be in use. Hoever, if most of the
users find these letter shortcuts more suitable, we can change them.

>
> 2) There is a secondary list Show, Show, Show, ...., Command Window,
> Command History, File Browser, etc.  To me, that seems redundant and
> just obfuscates my understanding of what these actions represent (i.e.,
> feature overload).  At the same time, it doesn't add much functionality.
>  The first group controls show/hide.  The second group brings the widget
> in question front and visible (which inherently does a show if
> necessary).  The difference between those is so subtle that I would
> actually just prefer making the show/hide action also bring the widget
> in question to the front and visible.  That is, I don't like that if I
> have a visible window which I then hide and successively show again that
> that window goes to the back and is obscured so is not visible.  (Try it
> in the current build.)  What percentage of the time is a user going to
> want to do that?  Typically what motivates a user to take action is that
> she wants to see the window.

When we drop the second list and only have show/hide action the follwong
happens. Switching, e.g., to the editor by Ctrl-4: the editor is
possibly unhidden and gets focus. Then we switch to the console (editor
loses focus but is still shown) and back to the editor by Ctrl-4. What
should happen now? Giving Focus to the editor or hiding it?`To my
opinion, both lists of actions are required.

Of course, all this depends on the workflow. I usually do not show or
hide a widget frequently. There is a prefered layout which is almost
fixed. However I always use shortcuts for switching between widgets.

>
> 3) Sometimes the full memorization of all the windows is too much, so it
> would be nice to have shortcuts that act just on the current (focused)
> window.
>
> So, how to manage all this?  I'll start by proposing a layout something
> like the following:
>
> ---------------------------------
> E A Command Window
> E A Command History               >  ----------------------
> E A File Browser                     Show      Ctrl-Shift-H
>   A Workspace                        Undock    Ctrl-Alt-H
> E   Editor                           ----------------------
>   A Documentation
>     Variable Editor
> ---------------------------------
>     Hide Current Window    Ctrl-H
>     Dock Current Window    Ctrl-D
>     Undock Current Window  Ctrl-U
> ---------------------------------
>     Reset Default Window Layout
> ---------------------------------
>
> In the above, the side context menu takes the actual action.  The
> Ctrl-Shift-? will toggle the Show/Hide.  The Ctrl-Alt-? will toggle the
> Dock/Undock.  And the action listed in the context menu will display
> either "Show"/"Hide" depending on the state and either "Undock"/"Dock"
> depending on the state.
>
> Down near the bottom of the Window menu are the shortcuts for
> controlling these settings for the current window.  There's no "Show" of
> course since there is no way of a hidden widget having focus.
>
> Then, for showing the state I put in place an "E", which maybe could be
> an eyeball icon (visible/hidden), and an "A", which maybe could be an
> anchor icon (docked/undocked).

As mentioned above, what would be the shortcut for switching into the
history widget when it is shown but does not have focus? Ctrl-Shift-H
would hide it instead.

> Is this getting to be too much info?  Does it create a bind for future
> expansion (say minimize/maximize shortcuts...although I don't see those
> abilities having the status of hide/show and dock/undock)?  Is there a
> better approach?  Any feedback is welcome.

Since we usually have window decorations around our floating widgets,
the shortcuts for minimizing ans maximizing should be left to the window
manager.

>
> Dan


Reply | Threaded
Open this post in threaded view
|

Re: GUI Window short cut preferences

Daniel Sebald
On 06/27/2018 03:26 PM, Torsten wrote:

> On 27.06.2018 21:54, Daniel J Sebald wrote:
>>
>> [snip]
>>
>> 1) The use of 0, 1, 2, 3, etc. to represent the various windows as far
>> as a memory aid.  Secondarily, the use of numbers constrains the list in
>> to remain exactly in the order it currently is.  I tend to think more
>> along the lines of associating a letter with a feature.  For example
>>
>> Command Window -> C
>> Command History -> H
>> File Browser -> F
>> Workspace -> W
>> Editor -> E
>> Documentation -> D
>> Variable Editor -> V
>>
>> Some key combination with that letter would be easier for me to remember
>> than numbers.
>
> Shortcuts with letters might already be in use. Hoever, if most of the
> users find these letter shortcuts more suitable, we can change them.

The Ctrl-C, etc. probably are, but Ctrl-Shift-C don't seem to appear
anywhere.


>> 2) There is a secondary list Show, Show, Show, ...., Command Window,
>> Command History, File Browser, etc.  To me, that seems redundant and
>> just obfuscates my understanding of what these actions represent (i.e.,
>> feature overload).  At the same time, it doesn't add much functionality.
>>   The first group controls show/hide.  The second group brings the widget
>> in question front and visible (which inherently does a show if
>> necessary).  The difference between those is so subtle that I would
>> actually just prefer making the show/hide action also bring the widget
>> in question to the front and visible.  That is, I don't like that if I
>> have a visible window which I then hide and successively show again that
>> that window goes to the back and is obscured so is not visible.  (Try it
>> in the current build.)  What percentage of the time is a user going to
>> want to do that?  Typically what motivates a user to take action is that
>> she wants to see the window.
>
> When we drop the second list and only have show/hide action the follwong
> happens. Switching, e.g., to the editor by Ctrl-4: the editor is
> possibly unhidden and gets focus. Then we switch to the console (editor
> loses focus but is still shown) and back to the editor by Ctrl-4. What
> should happen now? Giving Focus to the editor or hiding it?`To my
> opinion, both lists of actions are required.

I can see your point.  Someone is very likely to use the "show" action
just to bring a widget front-and-visible, but it isn't exactly the
easiest to tell what window has focus and it may well be that the user
doesn't realize the window s/he wants is already in focus.  So, it would
get hidden and the user would be annoyed by that.  So having a "toggle"
type action might not be good design here.  Something like the following?

---------------------------------
E A Command Window
E A Command History               >  ----------------------
E A File Browser                     Focus     Ctrl-Alt-H
   A Workspace                        Show      Ctrl-Shift-H
E   Editor                           Undock
   A Documentation                    ----------------------
     Variable Editor
---------------------------------


> Of course, all this depends on the workflow. I usually do not show or
> hide a widget frequently. There is a prefered layout which is almost
> fixed. However I always use shortcuts for switching between widgets.

Yes, I know.  Users have their preferences.  But it can vary, especially
for the variable editor.  Sometimes that V.E. is nice to have; other
times it gets in the way and it's better to hide or dock the widget.  I
would guess the most useful shortcut in that regard is Focus (i.e.,
show-and-raise).


>> Is this getting to be too much info?  Does it create a bind for future
>> expansion (say minimize/maximize shortcuts...although I don't see those
>> abilities having the status of hide/show and dock/undock)?  Is there a
>> better approach?  Any feedback is welcome.
>
> Since we usually have window decorations around our floating widgets,
> the shortcuts for minimizing ans maximizing should be left to the window
> manager.

Yes, that's probably a good idea.  Window manager stuff has cause enough
troubles.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: GUI Window short cut preferences

Daniel Sebald
On 06/27/2018 03:52 PM, Daniel J Sebald wrote:

> type action might not be good design here.  Something like the following?
>
> ---------------------------------
> E A Command Window
> E A Command History               >  ----------------------
> E A File Browser                     Focus     Ctrl-Alt-H
>    A Workspace                        Show      Ctrl-Shift-H
> E   Editor                           Undock
>    A Documentation                    ----------------------
>      Variable Editor
> ---------------------------------

Or, just this might be fine too:

---------------------------------
E A Command Window
E A Command History               >  ----------------------
E A File Browser                     Focus     Ctrl-Alt-H
   A Workspace                        Show
E   Editor                           Undock
   A Documentation                    ----------------------
     Variable Editor
---------------------------------

I mean, there is already the show/hide and dock/undock icons and the
drop-down Window menu route.  If those actions aren't used real
frequently, do they need shortcuts?

Dan