Posted on by Martin Flöser

4.10 Feature Presentation: Application Menu in Window Decoration

My favorite new feature in the KDE Plasma workspaces 4.10 (to be released on February, 6th) is the ability to hide an application menu inside the window decoration. I’m someone who is hardly using the menu, I get too lost in it. I’m preferring to use tool bars with the nice icons which help me to recognize what I’m looking for (a scissor is easier to recognize than “Cut” or “Ausschneiden” – depending on the language the app thinks to have to use).

By removing the window menu the complete window frame gets less cluttered. A huge area containing lots of text is just gone. Just look at this screen shot of Calligra Words, which I use to write this blog post:

Aus KWin

While KDE Plasma workspaces does not only allow to have the menu in the window decoration it also provides the possibility to put it into a global menu bar. Personally I do not like this (have used Mac OS, know what I’m talking about) as it disconnects the menu from the window. With the window decoration this problem does not exist and also removes the problem of long mouse distance travels in case of non-maximized windows.

In 4.10 we provide this new feature only in the Oxygen (default) window decoration. But our 4.11 development branch has seen some activity in this area: all Aurorae themes support it and also the Laptop window decoration.

This pretty awesome new feature can be enabled in System Settings. Just go to “Application Appearance”, then to “Style”, select the second tab called “Fine Tuning”. If your system provides the required support libraries (if not complain to your distribution) you will find there a section “Menubar” with a dropdown to select the way you want to have it. If you select “Title bar button” the button will be added automatically. As screen shots say more than words:

Aus KWin

And last but not least a screenshot with the menu:

Aus KWin

62 Replies to “4.10 Feature Presentation: Application Menu in Window Decoration”

  1. I really like it, though in my humble opinion it should be wider. It barely looks different than other default buttons on left side. I like the global menubar as well BUT it is too small. Other than that it’s great, glad to see that in 4.10. Thank You Martin

    1. I would like to have something like what Firefox did, but it is non trivial as we don’t have the application name. Yeah we only have the caption, which is useless for using as the button.

      With this constraint given our designers seem to have gone for consistency with the other buttons.

      Concerning corner: this is my personal setup, I want to have the normal icon completely on the left. I actually do not know where it is put by default. Reordering buttons is also just a mouse click away.

        1. interesting. Will look into this. Had annoyed me for years that I only get the caption the window sets.

    1. I think that solution, even if elegant, shouldn’t be generalized because of apps with several menu items e.g. with unity (menu in global bar with calendard, try icon etc) I can’t see last kile’s menu entry on a netbook display (1024x) and I believe it’s the same with similar apps (IDEs etc.).

      1. @Erica
        The menu can’t be always displayed in the titlebar because it prevents the window to be moved by the user (if menu’s width >= window’s width).

        In my opinion, it could be displayed in the titlebar only after a click on the dedicated button.

        @Radio
        On small screen or when window’s size is too small, the menu could be cut and a drop down could be displayed.
        If fact, it already happens with menus inside applications.

        Unfortunaly, if I remember the current state of developpement, kwin don’t know menu’s items. It only asks to kded appmenu to display the menu at a particular position.
        So, it is not currently possible to develop this feature with current codebase.

        1. You could move the window by holding the mousebutton down, which shouldn’t open the menu.

          Click > Menu opens
          Click and hold down > Move the window without opening the monu
          Double click > Maximize, minimize, roll up etc.

          Problem solved.

  4. Indeed, trying it now, nice feature! A wider button would be easier to use, I agree with previous comments.

      1. See the window in foreground: the menubar is on the same line of the titlebar. You also posted about this a week ago:

        312900: wish: kwin option to save vertical space: merge window buttons into menu-bar
        This change will be available in version 4.10

        Note. I’m using 4.10 RC3

        1. no, that is not possible. And I did not “post” about it a week ago. This is an auto-generated report of bug reports that got set to resolved fixed over the last week with the title being taken from what the users enter. This does not have to reflect the reality.

                  1. Unity devs try to get this result in Ubuntu but fails… It’s quite hard to have this feature without many unfixables issues.

  7. And even the keyboard shortcuts are still functional, great! Thanks a ton, people! Small suggestion, maybe make the ctrl+m shortcut, which usually hides/shows the menubar, open/close the menu when the menu is reduced to the button.

  8. In addition to the very small button, another problem is that you have an extra first level for the main menu items, which is not great for usability.

    Firefox (which has a simplified single menu with a few submenus) and itunes on windows are better solutions. Something like itunes shouldn’t be too hard to implement, just add an overflow button; for the firefox-like solution, the app would need to know that it’s supposed to give the window manager a simplified menu (e.g. chrome gives you a traditional menu if you enable the global menu bar, but the window manager could ask for a simplified menu in this case, and chrome would give it something like the menu inside the window)

    1. This will be possible when switching to GMenuModel (KDE 4.12 i hope).

      But, i would personnaly prefer:
      – Normal menu like in KDE 4.10
      – Use alternative menu to show context actions in taskbar/icontasks

      1. Is there any further information about using GMenuModel in KDE SC available? It’d be interesting to see how it compares to the (your ?) current solution and which possibilities are opening up by the switch.

        1. no not yet, I have not known about that prior to the blog post – there’s a small discussion about it on Google+.

    2. In terms of usability, the Firefox style is the way to go. It condenses a large menu in a small box and a few sub-menus, so you can reach any item with a short movement of your pointing device, and there’s still a few context actions in toolbars. And I think looks way nicer and cooler than having a huge menu in the window border.

          1. maybe it improved in later versions, but the compacted menu I have here on Debian cannot be navigated with cursor keys.

            1. When I hit Alt + F, E, V, etc. it temporarily brings up the standard menu bar, even when set to the compact version. I’m using Firefox 18.0.1-1 on Arch Linux [extra].

  9. really nice… and it also works in gimp.
    thx a lot !

    hopefully this feature will get some other options in the future.. like “button size” “menu icon” “button color” oder just display the word “menu” inside the button or the “application name” ..

      1. That is not reported by me. I was led there by a google search. This does not seem to be reported in the KDE bug. Should I report it?

        1. to be honest: I did not even read the bug report as in general I ignore all bugs reported to me through my blog post (especially if it’s in an area I don’t work on). I just wanted to point out that a bug report on Launchpad for KDE software won’t be fixed.

            1. guess what: I had a tough day. Maybe my answer was not the best and some of them here had been rather short, but I have also other things to do than providing custom answers. At least I take the time to answer. And yes I cannot do everything users want from me. A day only has 24 hours and I did decisions that I don’t look into bugs pointed out to me on various channels like here in my blog post (users think they can just ask random stuff to it) or on IRC. Why don’t I do it: because it’s lost here. I read it, I cannot work on it and then it’s gone. We have a bugtracker for bugs, not blog posts or IRC.

              And please do yourself a favor: don’t judge people by the way they write. You might notice that I am not a native English speaker (for example I just had to look up “prick” in a dictonary as I didn’t know that word) and I write like I speak German. The language, the culture is different. What’s considered as normal and acceptable writing in German may be considered as arrogant in English. For me it’s more important to give someone an honest answer than being totally friendly. Yes English especially American is different in that regard.

                1. Launchpad is the bugtracker of the distribution Ubuntu. Each distribution has it’s own bug tracker. So has KDE and bugs in KDE software need to be reported in KDE’s bugtracker, because that’s the place where KDE devs look for bugs. We cannot check all the distribution bug trackers.

  11. As long as you allow us to use our desktop HOW WE WANT to, its really not a problem.
    Too often do we hear devs say “i dont use this feature, therefore we can change it” as if they are the world.

    Look, I hate all the defaults, Oxygen especially but I like KDE because it still allows me to do thigns the way I want to.
    Just like Firefox did with its menu change, all you have to do is give the peolpe ‘choice’ instead of going for the ‘we know better than you waht you like’ mentality that is too common.
    Its like telling people that you dont offer vanilla ice cream because more people like chocolate…. its a subjective thing.

    There is a lot of things in KDE that I dont use… it doesnt mean they are not good, simply that I dont like them. Its this flexibility that allows my KDE desktop to be totally different looking that my wifes laptop or my parents or in-laws computers.

    So go ahead and innovate just dont start with the ‘its this way from now on’ mentality and all will be fine.

    That said, any chance of EVER seeing the system tray icons be allowed to be made bigger? You can modify every single component of the desktop except the most viewed portion of the screen, the system tray icons.
    The number one thing I hear from older people is ‘this is too small, can you make it bigger?’. This same group doesnt believe that monochrome icons help but rather make it harder to see.
    Allow the icons to be made bigger in the system tray whether its on the panel or as a stand alone widget.

    Have been using Linux since KDE4.2 and its the only reason I stuck around with Linux (the other desktops didnt allow me to do things the way I did and I came close to going ‘back’).
    So Id like to take this opportunity to thank you along with your colleagues for all the hard work you do. Too often people tend to overlook that.
    Thanks.

  13. Just wonder is this feature enabled in RC3? I have emerged rc3 from kde portage overlay, but I cannot activate this feature as I want.

    Thanks for the great work.

    1. of course it’s in RC3, we are in feature freeze for quite some time. Check your install log, you are not the first Gentoo user complaining about it, I guess the ebuild is not yet adjusted.

      1. Speaking of distro-specific gripes, this feature is completely missing in Arch’s [kde-unstable], and I know we’ve already got RC3. I’m not entirely sure who’s in charge of that repo; is this something to ask Arch or KDE about?

          1. The feature is not missing just the appmenu-qt (or qt-appmenu? not opn arch just now) has to be installed in order to use this feature. So it is in fedora, too.

            1. Thank you. It was appmenu-qt. I love how every time I run into a problem with Arch it’s actually me forgetting an optional dependency.

  14. A good start, but I think the button needs to be larger and better indicate what it does. One option is to have it say “Menu” inside the button, which would help to lengthen it, making it an easier target.

  15. One minor problem with the menu in the title bar. Seems that it can only be globally enabled or disabled. However, when using a theme that doesn’t support it (why can’t the theme just draw a blank button there if it cannot recognize the type of button instead of ignoring it ?…) it doesn’t automatically fallback to normal menu. And themes like oxygen can turn off title bar for a certain window (not as flexible as window rules though) and there is no fallback for such case either (or is this one a limitation of the protocol?).

  16. Hello, I have a few suggestions for that appmenu thing:
    – an option to have different behaviors for maximized and not-maximized windows. As a user of the global menu plasmoid (by the way, it would be nice to integrate it in KDE SC too!), I would really like having the plasmoid (or the glowbar) used for maximized windows and standard menu bar (or titlebar dropdown) for non-maximized ones. This makes a lot of sense in a setting when you hide the titlebar of maximized windows (like in netbook mode).

    – could the glowbar be modified such that it appears *over* the plasma panel, just under the screen edge, instead of below the panel? (when the plasma panel is on top edge) If the glowbar could do that I would use it instead of the global menu plasmoid.

    Otherwise, nice work, and congratulations for having this appmenu stuff officially make it into KDE SC 4.10.

  17. Hi, I think this is a great idea, it makes you think why have we been restricted to the fixed menubar for so long? 🙂 That said, I think it needs some improvement. One issue is discoverability, something that FF addresses by making it very noticeable. Another is that there is no provision for “branding”. Again FF does this well: why not show a kde logo or something beautiful the artistic team can come up with. Don’t know about the technical implications, but I really look forward to any improvements (I really liked the proposal by fasd!).
    Thanks for the great work!

    PS: the tickboxes under the submit form are in German 🙂

Comments are closed.