octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GUI Window short cut preferences


From: Daniel J Sebald
Subject: GUI Window short cut preferences
Date: Wed, 27 Jun 2018 14:54:41 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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

Attachment: Window_drop_down_menu_Screenshot_from_2018-06-27_13-56-11.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]