Re: GUI Window short cut preferences

[Torsten]

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