4

I am one of those people that are obsessed with vertical screen real estate. With all the widescreen laptops and screens sold the more space you have vertically the better and so I have always loved the Global Bar in Unity. Sometimes I feel quite alone in this but I'm certain that many others like it too for just this reason.

So the Appmenu is brilliant. There are some tricky bits with it, like how to edit the looks which isn't very appearent, and that it tends to bug-out when kept as a window decoration button (the scroll down menu's disappear when you scroll past the open window in Firefox for example), but those are just kinks and twists that will probably be adressed by more clever people than me.

My suggestion is adding a bar ON the window decoration.
See the Unity Global Menu, although saving up allot on vertical screen space does have one extremely valid criticism from a UX perspective and that is that its "divorced" from the actuall activity. The window may be down in the bottom right of the screen but you still need to slide all the way up to the top left of the screen to access the menu's.
The button on the window decoration, although clever, is also extremely hidden and results in a mass of scroll down menus in programs with several menu's (like Krita) and I thought "whats the use of knowing what application you're using"? The window title is, nine-times-out-of-ten rather, useless. The information given is redundant as most applications look different from each other and identification is obvious from a quick glance - AND when trying to sort out different windows by title that information is better handled through a window spread, panel thumbnails or a the window dropdown-menu.

So my suggestion is essentially a menu bar hidden within the window top-bar. Like Unity's global menu but ON the actual window. The great upside is that it will save allot of vertical space on the screen, combined with an effect where its hidden when not hovering over it makes for an extremely uncluttered and "calm" look to it and it follows the approach of a "tiered useage" (where the options are all available but hidden in tiers of complexity, from simplistic to complex)



The downsides

How do you move a window? When most people move windows they grab the title bar and simply drag it. With responsive menu's the result would be that instead of moving it they open, say "files", which makes moving the window allot more complex. They either need to learn the shortcut for "Moving Windows" which seems as a horrible sollution to a constructed problem or there has to be a way to assure that there are always open areas on the titlebar to be grabbed. Now in most applications there always will be open areas but in others (again like Krita) the entire titlebar will be full (see second section of "Downsides" below) - so how would that best be solved? I can think of three options:
1) A "move button", simply a button with the move cross-bar-icon which you click and then move the window with.
2) An obvious shortcut like the current "moving windows" but that displays on hovering so that its not missed.
3) A "Protected Area" of the titlebar, a section of the window bar that never gets anything placed over it, ensuring that there will always be something to grab a hold to. This could be selected with "configure buttons" in the "window decorations" section of the system settings.
... or a combination of all three. The big issue here is that a move button is too small and fiddly, a shortcut is too complex and a protected area can result in ugly collapsed menus. So this is my biggest "I dunno" issue.

The second issue is how to handle HUGE sets of menu's in small windows. Again, think Krita. It has several menu,s that might disappear when the window isn't maximized resulting in a more complicated work flow. Now in Krita this isn't a huge issue since you tend to maximize it and unless you use really tiny windows it doesn't pop up as an issue BUT placing the menus in the window decorations top bar means putting them in an already cluttered area. The combined space of the current button set-up and perhaps a move button and perhaps a "protected area" (see above) would mean less space for menus and a large chance for collapsed menus. Now the counter argument here is that users still need to worry about this with window size and that the changes aren't that big, but what if? What IF the border becomes so cluttered the end options (usually "help" ironically enough) aren't visible even when the window is maximized? And shouldn't there be a more elegant sollution to this?
As far as I can see there are three options to this issue
1) Leave it as it is, current set-up work enough and chances that menus will disappear even when the window is maximized is minute
2) Add two buttons. One for left-scroll and one for right-scroll where by pressing them the menus shift right or left exposing eventually hidden menus.
3) Add an "...more" option at the end IF menus disappear. Meaning that in Firefox for example and "Tools" and "Help" where hidden by a small window, the end menu still visible would be replaced by a "...more" menu option that when clicked creates a dropdown menu with "Bookmarks" (the menu option replaced by "...more"), "Tools" and "Help" available as further menu options in the style of the current Appmenu dropdown version.
Now as I see it More buttons as in the case of the right-left ones are right off since as nice as that might look (sliding menus etc) it would make the window decoration EVEN MORE cluttered and filled with things. Number one, although viable, is still not the best sollution and number three seems (to me as a complete layman) complex to create.

So thats my suggestion - what do you guys and girls think?

jensreuterberg wrote:So thats my suggestion - what do you guys and girls think?

Well, I agree with you that vertical screen estate is most valuable. Thats also why I have hidden the menubar everywhere, via:
System settings -> Apllication appearance -> Style - Menubar style: top screen menubar
(see also this post I just wrote).

You only wrote about the Appmenu (which I do not like for the same reasons), but did you also try the above option?

I also agree that the title bar is a lot of wasted space, but if I look at my firefox on windows...
So in the future there might be no title bars at all (I do not know of any plans in KDE tho...)

Another thing with your idea is that it heavy interferes with common usage behavior (as you also wrote it), but on the other side doesn't provide a full menu (as you wrote, too).

Thats why I like the menu button in the toolbar (dolphin/rekonq) and the system setting mentioned above so much, they both hide the menubar completely, but on demand they show the complete menu - no further fuzz needed (and no interference with common usage).

Yes, with KDE 4.10 there is already the option to configure the menu into a small "appmenu" icon and it should offer this as an OPTION too.

One major advantage of this is that when you have a maximised window the top row of pixels can he used to activate the menu with your mouse. Therefore, to access the menu you only need to fling your mouse cursor to the top screen edge and then only have to care about horizontal mouse positioning at this top edge (Fitt's Law). This is kind of like the menu in MacOS, except without the cognitive overhead of having the menu illogically detached from the window it refers to.

For window dragging, simply there should always be enough padded space to have a drag area. If there is not enough space, then simply the menu will appear as normal on the row below.

One thing I don't like, however, is the "hidden when not hovering over" part of your suggestion. Hidden user interfaces are never intuitive.

Another reason (against this) I see, is the tab feature:
You can attach any window to another window as tab, see
http://666kb.com/i/chw41bkmt6rurj4vs.png
With the menu in the title bar this wouldn't be usable.
Although I must say I hardly use this, but others might, so it would be another point where user expectation break.

fakd wrote:Another reason (against this) I see, is the tab feature:
You can attach any window to another window as tab, see
http://666kb.com/i/chw41bkmt6rurj4vs.png
With the menu in the title bar this wouldn't be usable.
Although I must say I hardly use this, but others might, so it would be another point where user expectation break.

This could still be done in such a way where the "attached as tab" feature takes priority. If there were not the space to display the tabbed windows or window title then the menu could automatically appear in its normal position in the row below. Alternatively, the menu could collapse into the appmenu button that was introduced with KDE 4.10.

On your other points, I think the benefit of this feature would also be that (like everything else on KDE) you could configure it on an application or window-specific basis, therefore points about Firefox already having its own proprietary appmenu could be taken into account.

It does disturb me to have all other space used effectively but lot of wasted space in Window Decoration and not to have an option to do something about it. "Hidden when not hovering over" should be optional. Window title could be shortened and showed in pop-up when hovering mouse over it. Paulm's suggestions for tabs sounds good. I'm using the top screen menubar but would prefer to have them in decoration. Top screen menubar is great option to have, but it feels little odd and discrete to have all other parts of the program (almost always) in one window but menubar elsewhere. Especially when the window happens to be somewhere else than top of screen.

Anybody seen this video? I can't find any info on this patch, but this is exactly what I would like to be able to do.

mrbumpy409 wrote:Anybody seen this video? I can't find any info on this patch, but this is exactly what I would like to be able to do.

Hmm, yes this looks nice. Unfortunate he doesn't give any info or replies on his yt channel...

Oooooh that looks spot-on MrBumpy409!

Ok I found the guy on G+ and asked him to come here and show how he did it or explain it there and I'll copy+paste it here

This is a previous version of kded appmenu module but it was refused by KDE SC devs...