Re: GUI Window short cut preferences

[Daniel J 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