The image below shows from top (1) Gnome header bars, (2) some non-KDE apps displaying a sort of adaptation of Gnome header bar under Plasma, and (3) a typical KDE app like Kate displaying title bar instead.
I don’t like the idea of having only one window control button, i.e. Close in Gnome, but I think it might be a good idea to get rid of the traditional title bar in KDE Plasma as well. This will not only save more screen real estate, and provide a simpler, cleaner window, but will also help get rid of an important inconsistency in user interface when hardly any one can avoid using some non-KDE apps.
Thank you very much for the detailed info showing all the complexities involved.
Leaving aside technical aspects, and although I think menubar can be replaced with global menu and/or menu button, which I already do, I understand that some apps will suffer from insufficient space left for toolbar, and/or from omission of title (when there’s no tab bar)…
I understand that the built-in hamburger menu of some apps offer only a simplified/concise version of full-fledged one on menu bar, so it’s not satisfactory for some apps.
But couldn’t the “Application Menu” button that KDE Plasma offers suffice in such cases?
No, because the “Application Menu” button uses the same underlying technology that the Global Menu does, which requires that the application export its menubar over DBus. If the app does not, then neither Global Menu nor the Application Menu button will work. And there are some big apps that don’t support this, such as Firefox on non-Ubuntu distros (Ubuntu patches in hacky support for it that was rejected upstream by the Firefox devs).
i don’t mind the loss of the title bar when it’s a choice that i can make, as it is with firefox.
they give you the option of hiding the title bar and incorporating some of the titlebar features into their own “header bar”, if you want to call it that… but they leave the titlebar alone as they should because, as you said, that’s a good separation or roles and responsibilities between the OS and the application.
i choose to hide the tilebar in FF because it gives me back precious vertical screen real estate at the minor cost of grab area… this is a trade i’m willing to make, others may not want to, and i may not want to in other circumstances or with other apps.
the point is the choice should be mine and not locked by the OS.
Right, that’s exactly what we have right now; you can choose your preferred method of accessing the menu. We have no fewer than four of them:
In the window
Global menu (for apps that support it)
Button in the titlebar that shows the full menu structure (for apps that support it)
Hamburger menu in the toolbar that shows a curated menu structure (for apps that support it)
You have total choice and control. I was describing why we can’t use the Global Menu or Application Menu titlebar button by default for everyone, though. To be the global default, it has to work for everything.
i’ve just installed over half a dozen music players and NONE of them offer me a choice of how the titlebar is used (or if it’s used).
most of them have the traditional titlebar with all their menus inside the window area, but lollypop and g4music have the gnome style header bar cluttered with buttons and menus, then there is qmmp which takes a defiant stand against any sort or norm with it’s winamp skins.
I don’t use titlebars at all. There are plenty of options to close/max/unmax/min…on panels, corners, specific shortcuts etc…as far as I am concerned. For me, titlebars are useless and take up too much space.
That being said, would it hurt to add a min/max/unmax to the options of the toolbars? Centuries past I get that a custom toolbar button will never happen in my lifetime ( although it existed once as a git version). And um, maybe add a spacing/padding function to the breeze window decoration cause the default padding still makes up for a quite fat titlebar. This one’s set to a 0 value on the Sierra Breeze window decoration which somewhat compares to default Breeze. Real estate counts on small screens.
I remember your blog post and personally remain dubious about this headerbar.
On the other hand, I’m convinced that the tab bar isn’t the best solution for managing multiple documents within a same application.
Text is oriented from left to right (or vice versa) and tabs are juxtaposed on the same line. So the more documents there are, the more tabs there are, the less space there is for the title of each document. One could do better in terms of clarity and accessibility.
What do you think about replacing the tab bar with a drop-down menu integrated into the title bar to navigate between documents currently being edited ?
This menu could take up around 80% of the width of the title bar, giving more width to display the path and title of each document. Furthermore, this width would be fixed, with documents appearing superimposed rather than juxtaposed.
If the window is split into two or more views, the documents displayed could be grouped together using a brace and colored background, in this drop-down menu.
I think Kate or Kdevellop would be ideal candidates to implement it.
This wouldn’t be a headerbar, but the spirit is the same: that the space at the top of the window be used efficiently.
Thank you, I know this tool and I find it practical.
I believe it is specific to libktexteditor based applications.
I have in mind a similar menu that a developer could use, if his application is able to handle at least two files or folders simultaneously.
I visualize it as a title displayed in the bar at the top of the window like the current title bar. But by clicking on it, it would unfold into a similar menu showing all the other (groups) of open files or folders, in a more readable way.
The user would then, I think, have quicker access to the file/folder he wants to use. This could be done with two clicks and, if there are a lot of items, a quick scroll down.
I’m convinced that this way of presenting the same information is clearer than having 20 tiny tabs juxtaposed among which one looks for the right one.
Your example inspires me to add a search field for filtering.
This weekend, I’m going to try and draw a sketch to explain myself better. Dolphin might be a more appropriate example.
The component that provides this for QtWidgets apps is KXmlGui, and I think some toolbar components can be provided by default to any application using it (it’s been a while since I last looked into it).
Well, like I said, I don’t use titlebars and have plenty of options to control my windows. However, I place a close button on the toolbar on nearly every app that has it available. Dunno why really, I just do. BUT. Imagine for a sec what a configurable button could do. For instance, bind shortcuts emulaters to it, bind scripts to it…etc etc…Simply put, an entire load of stuff which is only possible through a servicemenu right now. The thing is, I know FOR A FACT that at some point someone made exactly that. It was available on github back then. And here’s the thing, you could add several of those customizable buttons to the toolbar. Now, does having close/min/max work as a csd function? No, of course not. For one, there’s no window title of course. But hey, there’s always a taskbar and having a close/min/max straight on the toolbar would already be an option for those who want to avoid titlebars for some reason. Seriously, even Caja has functionality to add custom buttons to the toolbar. Don’t let me start on something like spacefm. I believe nowadays nemo and pcmanfm-qt have this function. Krusader has had it for as long as I can remember with actionman.
WOW! That is such a good feature (it even shows the keybinds)! That is such a killer feature for someone like me who always forgets keybinds and where to find important buttons!
How did I miss that after using KDE for 10+ years?
