restore window mode for desktop environments without a system tray area

[Antoine Martin]

This mode should replace the system tray with a control window which allows the same access to the servers/sessions/info menus as found in the system tray.
This should probably be enabled by default when we find a desktop environment which does not support the system tray (ie: fluxbox?)

[Antoine Martin]

r4573 adds a simple window mode (see screenshot) which just re-arranges the menu entries into a vertical box.
Please provide some feedback so that I can finish it..

Known issues:

• The window currently resizes to fit and may overflow the screen, I will change this to a scroll area when the window grows too tall (90% of screen height?)
• the separator between each server entry is just a horizontal line, which isn't very pretty.. suggestions welcome.
• the code currently relies on Configuration -> User Interface -> Use Nested Menus being unset, setting it causes the "shortcuts", "start application" and "start desktop" entries to be shown and this just looks confusing I think. I will probably force nested to be left unset when this window mode is enabled.

Note: there are some important limitations to do with layout: the code has no idea what the buttons contain and just "transforms" the menu into a window, so clever re-arrangement of buttons, grouping, etc.. is not an option without some major code changes.

[Antoine Martin]

shows the new window mode in action

[Antoine Martin]

Forgot to add, to test it use this command line:

winswitch_applet --window-notray

Or set

window_notray=True

in .winswitch/client/client.conf

[Antoine Martin]

r4585 improves things significantly - see commit log message for details

[holycow]

Some comments about this feature request:

ONE -- QUICKIE SOLUTION

What you have up there will work for me. I use Stumpwm, but any tiling window manager will be able to handle what you have there just fine.

The key to the request, for me, has been to request the absolute minimal work for the programmer to enable those of us using tiling window managers without panels to use Winswitch.

I could live with what I see in the mockup just fine. Let's just make sure that this is a feature that the user can turn on and off, there is no need to modify the excellent default behaviour as most users with floating window / panel setups.

TWO -- UI DESIGN CONSIDERATIONS FOR TILING WINDOW MANAGERS

If I put on my ui design cap, while tiling window managers deal well with popup menus, the users of these environments will eventually ask for a tabbed single window layout (with scroll areas), similar to some of the preferences menues.

In essense, one can collapse the entire app into two separate ui modes, a single window mode for standalone users, applet ui mode for panel users.

Of course, a single window tab driven interface doubles the work in perpetuity for the maintainers of the project. This is something that I do not wish to impart on the programmers. My original request is perfectly reflected in this mockup, and while i appreciate the opennes to suggestions on prettying up some of the UI elements, this will work for me.

THREE -- SOME SUGGESTIONS THAT WOULD BE USEFUL GIVEN THE SCREENSHOTS ABOVE

The only feature that I could envision adding here is a keyboard shortcuts to all of the menu items so that a tiling window manager user can do something like:

a) use whatever shortcut / mouse driven method to open up the app manually

b) each window presented needs two methods of input by default: mouse and keyboard shortcut.

c) the current mouse driven event ui works great, if we could add some sort of shortcut system to the menus, I could open the app with a shortcut, navigate via shortcut and pretty much do anything necessary until an app that is NON keyboard oriented pops up.

The most common method for deploying shortcut ui interactions is to either do the ALT / FIRST INITIAL approach a la Gnome/KDE, however, this should be avoided. The reason to avoid this is that ALT / FIRST INITIAL is a unnatural keystroke similar to the why the default keybindings in emacs feel unnatural. As an aside, one of the beautiful lessons from emacs is this natural filtering mechanicsm: those that cannot figure it out leave ... those that get it recognize the default key bindings as faulty and simply remap them to something more ergonomic. If you are not prepared to allow users to remap this keybinding you ought to avoid it. Besides, this keymapping won't scale to extremely large lists, and your app is so useful and powerful I can easily see running many apps on many machines with this, rendering keyboard entry useless.

A more sensible shortcut system would be the NUMBERED / TYPE THE NAME OF THE LINK approach.

You can see this in the web browser called Conkeror (www.conkeror.org). Its shortcut bindigs are a blend of screen and emacs. When you open an html page full of hyperlinks, you press the F key to reveal an overlayed numbered list of hyperlinks. To select a hyperlink, you can either type in the number or spell out the hyperlink.

Of course, the Conkeror implementation is much more sophisticated and has a lot more power, but none of that is needed to implement a shortcut based menu option to this app.

Instead, if we look at each of the menu windows, each menu is essentially a numbered list represented as icons/buttons. Simply NUMBER each of the icons/buttons/links to the left and let the user type in the link number OR let the user type in the menu item. You may need to consider the option of auto completion and highlighting the closest found link, but that would not be necessary.

We can even simplify this further and NOT implement the typing of the named link, but simply presenting numbers for each link/menu item, use some sort of visual suggestion that it is a hyperlink (underline may be gauche perhaps but functional) and let users just type in the numbers to select.

The edgecase here would be to default map CTRL/N and CTRL/P (and the arrow keys) to scroll up and down in the list as that is the convention in most apps that are keyboard / shell driven when a scroll bar or large list is displayed.

FOUR - SUMMARY:

Features:

• number all the icons/links from 1 through infinity
  

• hyperlink all numbers, let the user type in the number of the link for the apropriate window to pop up
  

Edge case considerations:

• map ctrl/n, ctrl/p (and arrow keys) to scroll through the menue windows by default as that is a standard convention.
  

• the current popup menues are fine in their own windows. i don't want to create a huge amount of overhead for you to maintain. if required, i am willing to contribute to maintain the ability to run the app without a panel.
  

• users will inevitably ask for a single window tab driven version of the app. once they clue in that they can turn this on, they will ask why so many small windows. i personally don't care -- if i can get the various menues to come up via keyboard driven interface that would be all i need, but this ought to be something to keep in mind.
  

• the other thing to keep in mind is that i do not know how much work adding a keyboard driven menu interface component will take. this could actually be a fairly substantial effort because if only a few windows have this mode of interaction users will ask why the rest of the app does not have it, resulting in the whole app requiring a rework.
  

I would be happy to offer help, mockups and testing. If required, I can install other tiling window managers other than Stumpwm and test the app on each of them so that we get this right.

I hope the above is helpful, please let me know your thoughts and qeustions. I would be happy to demonstrate the various ideas as required.

[Antoine Martin]

• ONE -- QUICKIE SOLUTION

I could live with what I see in the mockup just fine

Is there some confusion? This is not a mockup but the actual current version as of 7 weeks ago.
Also, can you post the result from:

env | egrep -i "stumpwm|sess"

So I can try to detect stumpwm and make window-mode the default in this case?

• TWO -- UI DESIGN CONSIDERATIONS FOR TILING WINDOW MANAGERS

I believe most of what you request can be achieved by toggling "Use Nested Menus" OFF (in the "Configuration" dialog, "User Interface" tab)
It should be already switched off when you use this new "window mode".

• THREE -- SOME SUGGESTIONS THAT WOULD BE USEFUL GIVEN THE SCREENSHOTS ABOVE

a) use whatever shortcut / mouse driven method to open up the app manually

Isn't this done by the window manager, or am I misunderstanding things? Do you mean bringing the application window up? If you try it, it is always shown and it is down to your window manager to hide/show it based on how you use it.

b) each window presented needs two methods of input by default: mouse and keyboard shortcut.

I've just tried it and although one can navigate around the buttons using tab/arrow-up/arrow-down, pressing space/enter does not seem to fire the button. I'll fix that now.

c) ... if we could add some sort of shortcut system to the menus ...

OK, so this is more than just up/down, and will be tricky to implement.
OTOH, I can't see how this can be done with the current code (which has no idea what the buttons do or what they contain), but I'll try to think of something.
Can you please try it first as it is (with the "nested menus" off), then this gives me a bit of time to think of a better solution.

• FOUR - SUMMARY

Will keep this in mind as I look into the issues above.

[Antoine Martin]

r4771 fixes item "THREE - b)": you can now use "space" or "enter" keys to select items in menus.

[Antoine Martin]

r4773 ensures we don't get two windows when using the mouse! (only fire the event callbacks once when using the mouse by disabling the keyboard one)

[Antoine Martin]

Bump - can I close this ticket?