Martin’s post set off an eruption of ideas and debates over integrating dbusmenu and kwin and proposals for a new tabbed API. To quote José Pedro‘s comment:

The most important things I see lacking in Kwin from KDE 4.5 are an API to allow windows to open in a specific existing group (make a new tab in the decoration), and that the windows from a specific group are not grouped in the taskbar. I also think that if these 2 problems are fixed, most apps in KDE could use the decoration tabs instead of relying on the currently used tabs, inside the application itself. The important thing to notice here is the natural mix between the application tabs and the menu button. These complete each other, and all apps in KDE which rely on tabs to show documents would ideally use this system (dolphin, rekonq, kate, kword… just to name a few).

Here are some screen shots proposed in the comment thread:



Having an easy API to enable this would be very welcome.
setMainMenu(menu);
setWindowTabs(tabWidget);

Elsewhere in KWin settings:

[ X ] Place tabs in window border when supported.
[   ] Place main menu in window border when supported.
April 5, 2011 · [Print]

54 Comments to “KDE Alive with KWin Menu Excitement”

  1. Luis says:

    Beautiful! We keep the menu and the interface is less cluttered!

  2. wind-rider says:

    Of course this might work well in some cases – but I still don’t see what’s wrong with an (auto-hiding) global menu bar?

    Of course it is true that the menu is now closer to the window that is the “parent” of the menu, but it comes at a cost:
    This will only hide the menu in another container, needing an extra click or mouse-hover = an extra annoyance.

    If it is for saving space – the global menu does that (especially when autohiding), it does not require extra click / hovering actions and it provides an unified interface for the menu commands. Actually the global menubar Plasmoid works quite well!

  3. Kyriakos says:

    Looks very good and i guess it will be more functional this way. Hope we can see this on time for KDE SC 4.7.

  4. chrim munzi says:

    i like the idea, but please make it pixel perfect :)

  5. illissius says:

    This would be a very nice capability to have. Even ignoring the question of implementation, though, there are subtle issues. In applications where more or less the entire application UI doesn’t live under a tab bar, but only part of it does — Dolphin is a good example — using top level windows with with window-tabbing presents semantic differences compared to using a tab bar in the application for only part of the UI. In general, any kind of setting or state which is tied to a window rather than the whole application or to a tab will behave differently, and potentially in unexpected ways, between the two cases. In the Dolphin example, if you open the Folders panel and navigate to some folder in it and then switch to a different window-tab, you will see that the panel has reverted to its previous state, which is not so good, whereas with in-application tabs the panel stays consistent. (And there are plenty of examples like this.)

    Perhaps a two-pronged plan of attack would be the best way forward:
    – Design some kind of ‘DBusTabs’ API which allows applications to project their tabs outside of the application, say to the window decoration or a plasma panel, as with menus;
    – In terms of appearance, behaviour, and capabilities, make dbus-tabs and window-tabs as close to identical as possible, so that naive users won’t even notice there’s a different mechanism involved under the hood.

    That way, applications (and advanced users) can choose which method best fits their use case, and users can reap the benefits. Drawbacks: with dbus-tabs outside the application you lose the visual connection between the tabs and which part of the UI they control. If they control a ‘large enough’ part of the UI (Dolphin still qualifies), I think the benefits would still outweigh the drawbacks. There’s also questions like, “what happens when the user drags-and-drops a window-tab onto a dbus-tab-bar?” (presumably, the simplest answer would be not to allow that).

    Also, with regards to menu-in-windec, I think it’s important that the menu you get from the button should not be the normal menubar just mechanically translated into a single menu, with entries being ‘File’, ‘Edit’, etc. This is pretty bad for usability. At the very least there should be an ability to define a different hierarchy for the menubar and single-menu cases.

  6. Bender says:

    I don’t know but i love the second mockup. I’d love to see that implemented in KDE 4.7

  7. masturmix says:

    I’m masturbating looking at these screenshots, DOOOO IT PLEASE

  8. flows says:

    Somewhat cool thing. Thanks for your summary.

  9. Lionel Chauvin says:

    If we start to go in this direction, we also need a “new tab” button integrated in kwin :)

    Martin is against this idea.

    I think it could be standardized with the canonical idea of Window indicators (http://www.markshuttleworth.com/archives/333).

  10. Med says:

    To be honest at the beginning i was not that fond of this kind of layout. But thinking about it, i do not use the menu that often that an extra click becomes a problem. In the end it saves precious vertical space as screen makers make them wider and wider for commercial reasons (larger diagonal for the same area). Next step, windecs on the side of the windows? :)

  11. Framp says:

    Wow, chrome DID really changed the world
    All the major browsers, unity, now this..

    I don’t like using windows decoration *that* much (the decoration looks cluttered imho), but having choice is good and vertical space is precious in this days.

    Implementing this system wide and not per application would be a plus for the user experience.

  12. David Mills says:

    You got me all excited there, I was waiting for the part where you said that you’d gone and implemented it for 4.7 and needed testers ;)

  13. LukasHetzi says:

    I love this idea! The screenshots are absolutely awesome!
    Please make this happen ;)

  14. Satoshi says:

    Oh god yes.

  15. Michael says:

    Thank you! When I read that thread like you, I was nearly praying that someone would implement this very exact way of tucking the menu into the title bar, such as Firefox 4.

    This seems to clean up the interface nicely, and if it could be integrated into KWin like you mentioned, all the better!

    I wish I had the time to implement this idea myself, so I ask those with the skills to do so. Thank you!

  16. Bugsbane says:

    Dang, those screenies look nice. I find it especially interesting how the image of Firefox has FireFoxes standard tabs appearing in the same place that the window tabs would normally appear. Would there be any way of differentiating application tabs from window tabs? From an end user perspective, does there need to be? What would happen if you had two firefox windows grouped and each of those windows had tabs? Would you get two rows of tabs?

    There’s still questions, but dang I hope they can get solved and get this happening!

  17. madigens says:

    These screenshots look FANTASTIC and in combination with the idea to integrate application tabs into the window decorator just seem so natural. Here’s hoping this goes well!

  18. TheBlackCat says:

    Menu buttons, titlebar tabs, titlebar notifications, maybe it is time to have a comprehensive look at how the titlebar can be made more useful.

  19. damipereira says:

    Very good! I’ve always wanted rekonq to have this, it looks good and it is integrated with kde.
    maybe this should be the new hig for simple apps?
    also, can additional buttons be added on the right of the button menu?,.
    This way a bit more complex apps could use this type of gui, adding in the border the frequently used stuff that doesn’t fit in the toolbar.
    So maybe putting most used features as toolbar buttons, medium used features as window border buttons, and little used features inside the menu button.

  20. Foo Bar says:

    This is sweet. Especially the second picture looks aweseom!

  21. JeanLuc says:

    looks absolutely sexy^^
    great mockups ;) i hope some day this will make it into kde sc

  22. Lukas says:

    Hi,

    Getting rid of menu row as we know it know is great, but I don’t know if window decoration is the best place for it. I’d prefer it on the main toolbar like http://img141.imageshack.us/i/ktorrent.png/

    //Notice – the background is the same color as the icon of the app. It gives some personality touches :)

    On the other hand, it all depends on actual design and it would be great if someone could collect all mockups/screen shots in a single place to get as wide picture as possible ;)

  23. Stephan says:

    good idea! Only very rarely do I use the menu.

  24. CSousa says:

    Thumbs UP! +1

    I’m watting this (kwin client side managed tabs) since I saw it in Chrome/Chromium.

    It is an idea that works with great flow in chrome and will also work with Dolphin and others.

    But it shall not be abused, only few apps can take advantage of it.
    I’m thinking in Dolphin, Konsole, Konqueror, Rekonq and maybe Kate.
    On the other hand Kdevelop is an example of an app that does not need it (maybe for projects).

    Perhaps it is technologically hard to implement. But the benefits must be weighted.

  25. ruben says:

    this is actually really good.

    the apple’s approach to main menu (on the upper part of the screen) gets less efficient while screens get bigger and bigger (according to fitts’ law)

    cleaning the visual interface helps a lot for programs where one don’t use that much the main bar.

    waiting for this !

  26. Ole Christian Tvedt says:

    If anyone starts implementing this, I hope they will keep window hints and standards in the back of their minds. Decoration tabs is a good idea, but I would like to see it in other window managers too (without forcing the application developers to use several APIs).

  27. mutlu says:

    Thanks to Martin (Kwin), Hugo (Oxygen) and Thomas (Bespin) KDE is on the forefront of innovation. It’s really exciting. I hope someone will work on this idea.

  28. This is a great idea!

  29. Max says:

    This would be great. I wanted this since I first used Chrome. And I think this would be even better if it was implemented through client-side-window-decorations. Because then KDE-applications would have this not only in KDE but also in e.g. E17 or Gnome. And people might also want to put other things in the decoration like a search bar.

    Of course there is the disadvantage of UI-inconsistency when using different window managers, but in my opinion it’s already bad when the decorations and the applications themes don’t match and I’d like it better if the windows where consistent with themselves. (meaning kde-apps should always have kde-decorations, gnome-apps always gnome-decorations and so on)
    Also with themes like QGtk you could reduce these inconsistencies.

  30. Fri13 says:

    I find this idea not so good as there are many people who want to keep their window decoration clean as possible. Many my friends has only a close button in the window decoration and I personally dont have even that, but the window decoration is totally empty as there are no reasons to have any buttons in it. If I want to close the window, I simply double click decoration (instead just aiming a small X) or I middle click task in taskbar.

    The tabbing feature in KWin is already a very clean and simple, so why we should have anything like Firefox uses on windows?
    If wanted to have menubar hided, then simply add the Ctrl+M feature the kdelibs and set global configuration for it to system settings and disabled by default and thats it.

    But I must say as well that the KWin tabbing feature is not used so much.

  31. Alejandro Nova says:

    The supreme irony of all this: KDE is implementing Mark Shuttleworth’s ideas much, much better than Ubuntu’s own Unity.

    In the meantime, I have my own idea about what Dolphin can do with a menu button:

    http://www.megaupload.com/?d=04OAJCOJ

    (if someone has a better place to put that file, I’ll upload there, is an inoffensive 16k OpenDocument Presentation file)

  32. Michael Wright says:

    Absolutely brilliance. Should work perfectly on tablet and multi-touch screen device. Go for it!

  33. Markus says:

    You have read my mind and implemented it!

  34. blueget says:

    Hmm… I don’t like this, but I also hate MS Office’s Ribbon Interface that is highly praised by some. As long as it can be disabled easily, I don’t mind it.

    One question: does the menu button really need to be that big? Today we generally have the application’s icon in the window decoration, if that could be changed so that not the context menu, but the application menu is displayed on clicking it, that would be a very screen-estate-efficient solution – at least as an option it would be worth considering this, IMHO.

  35. fast_rizwaan says:

    I want it in my KDE… :-)

  36. alex j says:

    great idea, the hiding of the menubar would allow for making the window translucent as the menubar used to disrupt the applicability of this effect a great deal.

    Just a thought, wouldn’t it be more consistent (from a user’s POV) that the menu button be multifunction? I mean, both the app-specific menu items (file, edit etc), the kwin window mgmt items (always on top etc) and application ‘servers’ menu items (window volume -> pulseaudio/oss4/kmix) be cleverly merged into this button! The user wont have to hunt for the kwin window adjacent this btn (would be redundant) as well as putting other functions which conceptually belong associatedvwith a window/app but are not WM related to be integrated (it is the app window, according to the user, that plays my music, not some system tray icon so I should be able to set its volume on the app!!). With dbusmenu, this should be possible as when kwin (the decoration) is composing/building the menu items for the menu, it has knowledge of the kwin items, the app items (through dbusmenu) as well as the application \server’s\ menu items (also dbusmenu). Wouldn’t it be nice if the user could stop the printouts of that window (ie if cups advertised its menus through dbusmenu). I see this as a revolutionary feature for KDE

  37. SONA says:

    Phew, that’s great. Please, please realize this feature :-)

  38. andreas says:

    beautiful. really nice.

    one question:
    is it possible, that when you open a new tab (firefox or konqueror) that the tab will shown in the window decoration. This would be nice also dolphin, when you open a new tab.

    this would be a benefit for the tab functionality at the window decoration and for the usability.

  39. Fri13 says:

    If I remember correctly, tabs at the window decoration were noticed to be bad for usability. This in Apple’s own usability studies.

  40. kap4lin says:

    This is indeed a very useful feature to have. As many have noted above, there are two kinds of tabs – tabs across applications and tabs within an application. Things need to be sorted out. If this needs time and due deliberation to get it right, so be it. Don’t rush and ruin it (like most of KDE 4.x has).

    Further, keep in mind that drawing and redrawing the toolbar when switching tabs can become resource hungry. KDE 4.x has already inculcated the bloated sluggish feel of a linux desktop, please do not enhance this taste. So, again, if attempted, this should be done right, otherwise don’t do it.

  41. maninalift says:

    This could work well with menu search:

    http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/

    I’m imagining placing a search box in the top level of the menu, ideally accessible by a key short-cut and usable as far as possible as a krunner-for-application-actions (i.e. shortcut-type-return done, no need to click or navigate though options with arrow keys)

  42. jamms says:

    How would this work with a window group featuring different applications: the middle click, drag, tabbed thing? I can’t seem to picture how more than one application menu tab can work effectively and simply.

  43. josephk says:

    these ideas in couple DO make a lot of excitement. great! :)
    hope to see “something” in 4.7

  44. maninalift says:

    @jamms the menu is built by the application, it can be modified by the application while it is running (a common example is that features are “greyed out” when they are not available), therefore it is per-process.

    In principal therefore having multiple instances of the same application is no different from having multiple different applications in both cases there is one menu per process (ie per tab).

    I think that simply switching the menu so that the menu displayed relates to the active tab could work well (I’d like to have menu-in-widow-decoration and window tabs working together like this) but I feel that UI desigbners might complain that this would be confusing (if the menu is associated with the process and the process is represented by the tab then the menu should be attached to the tab)

    I think that simple visual hinting could overcome this.

    _________________________________________
    OO\___________/active tab\_______________|

    I have a feeling the above is not going to be at all clear when other people try to view it. My point is simply make the top-right button area look like it is attacked to the window-area below in exactly the way an active tab is designed to look like it is attached to the window below: visual confusion gone :-)

    In contrast Firefox 4 is a single application and Chrome/Chromium has menus-inside-tabs. Also Chrome is different because there is one process per tab plus one process which controls the rest.

  45. frank says:

    What I would have liked in the past is to put the normal menubar and the window title into one row. So the main menu is left-aligned, then some space, then the window title and lastly the window buttons.

    The reason for that is that both decorator and menubar waste space alike (the decorator a bit more b/c the title is usually shorter than a menu, if one doesn’t use the tabbed windows feature).

    For most programs like text editors, media tools such as players and all sorts of special utilities, this would be an ideal compromise. Though this here mockup is nice to look at, it takes another klick and some additional orientation by the user (he needs to wait for the menu to come up and then find out where the wanted menu item is).

  46. maninalift says:

    I’d like to hear your perspective on a platform for KDE mobile. ATM as far as I am aware Meego is the only mobile phone OS which is near-enough “full-blown” linux to run KDE and as everyone is aware the current state of meego devices is nonexistant and the future is uncertain at best.

    I’m sure there are a lot of KDE hackers and advanced users who would choose a phone on the basis that they could get KDE to run on it if there were a decent phone out there that they could try KDE out on and still use for day-to-day use.

  47. Eugene says:

    As a user, not a developer, I think that’s what is predictable next step. I use Google Chrome mostly because of it’s vertical space economy (tabs in the title bar).

    • Fri13 says:

      If you check closely, Chrome does not have tabs in the tittlebar, it has has tabs covering just littlebit the titlebar so there is about 60% space left where to resize/move window.

      What is now suggested, is that user can not anymore easily resize/move window or have anykind space for that for others than young users who has very accurate mouse hand.

  48. Charles Opondo says:

    Extremely exciting! I want to try it out, where cana I get it?

Leave a Reply