Folks offered a lot of feedback on my article on headerbars last year, some of which was skeptical or critical. I’d like to address some of the arguments people made in this follow-up:
It doesn’t really matter that there’s less visible or actual window drag space
People pointed out that you can drag on the UI controls, or use the hidden Alt-drag shortcut. Other people questioned how useful it is to drag windows around anyway, preferring to maximize everything or use window tiling keyboard shortcuts. I will address these responses:
“Just drag on the controls in the headerbar”
First of all, dragging controls to drag the window isn’t very intuitive. What other controls outside the headerbar allow you to move the window when dragging on them? Sure, you can learn it, but this isn’t the same as a good user interface that re-uses familiarity with existing elements rather than making you learn new modes.
Second, you can’t drag the window by dragging on controls that themselves implement draggable behaviors–such as tab bars, comboboxes, pop-up menus, and sliders. So those controls can’t be put on the headerbar without reducing the drag area and violating the “you can drag the window by dragging on the controls” rule. In the original post, I gave an example of Firefox’s horrendous CSD that puts draggable tabs in the headerbar, reducing the drag area for the window itself to almost nothing. Ensuring draggability by only using controls that are not themselves draggable reduces developer flexibility compared to a traditional titlebar. It’s just not a problem if you have a separate titlebar.
“Just alt-drag the window or move it with keyboard shortcuts”
This somewhat flippant answer describes a workaround, not a general-purpose solution for everyone. Most users drag their windows around all the time and probably don’t know any of those shortcuts. For them, adequate window draggability is important–especially if your desktop happens to be targeting these people as the #1 user group.
“Just maximize the window and then there’s plenty of visible drag space on the headerbar”
it depends on the implementation (e.g. Firefox’s CSD is perfectly capable of having almost no drag space when maximized), but this is broadly true. However, what if you’re not the kind of user who maximizes all of their windows? In any event, window draggability is least important for maximized windows. The whole point of dragging a window around is to move it somewhere else, which requires that it be smaller than the area in which it’s moved.
—
Taken together, these issues demonstrate that reduced draggability reduces developer flexibility and can be a real problem. It can’t just be dismissed as much ado about nothing.
You don’t need menubars anyway
A lot of people expressed many variants of this argument:
“You don’t need menubars anymore because actions and commands can be located inline, available contextually”
This works, but imposes a high bar in UI design, and results in frustrating and awkward software when implemented by a team without at least one person with A+ UI design skills who everyone else actually listens to. This approach is also very labor-intensive and bug-prone as by definition it’s custom-made for each app and requires a lot of code. It may not scale well for content with many actions you can perform on it, since there’s a limited amount of space in the content view to put contextual actions. It furthermore throws away users’ existing familiarity and muscle memory; for example when cut/copy/paste/find are always available in the same place in the Edit menu, users never need to re-learn how to cut, copy, and paste, and find text in each app. Finally, this approach doesn’t help the user learn keyboard shortcuts.
So yes, this approach works, but results in significant drawbacks. It’s definitely not a 100% slam-dunk superior user interface.
“Menubars are overkill for simple apps”
This is a reasonable argument. Most of the items in the average menu bar pertain to text manipulation, file handling, and view adjustment. An app that doesn’t have any text manipulation or file handling can probably get away with putting what’s left in toolbar buttons. In fact KDE’s Discover already does this, for just those reasons. A number of other simple mouse-centric KDE apps like the games could probably do the same.
But the thing is, you don’t need to implement a CSD headerbar to get rid of your menubar! You can do it with a traditional toolbar and a traditional titlebar, and gain all the advantages of those individual user interface elements: guaranteed space to drag the window, a legible window title, a user-customizable toolbar that can include draggable UI elements, and so on. No need to throw the baby out with the bathwater.
“Menubars don’t exist on mobile and mobile is the future therefore we need to get rid of them on the desktop or else people under 25 will perceive us as stogy old farts and won’t want to use our apps”
I see no evidence that the under-25 crowd hates desktop apps with menubars. A lot of KDE’s most active members are young, and all fully understand the productivity benefits of real desktop apps with traditional user interfaces.
The truth is, mobile phones are really only good for communication, travel, controlling portable hardware (cameras, drones, etc) and content consumption that doesn’t benefit from a large screen. Other than these use cases, mobile apps are universally worse to use than traditional desktop apps–especially for productivity. They are slower, more awkward, have fewer features, take longer to accomplish the same tasks, are harder to multi-task with, have user interfaces that are constantly in a state of flux, and are an absolute nightmare for anything that requires precise text manipulation or formatting.
Most of these limitations are imposed by the hardware’s own input and output capabilities. This means that the only way to improve the situation is to plug in a big screen and some faster, more precise input devices–essentially turning the mobile device into an underpowered desktop computer. Not coincidentally, KDE’s Kirigami user interface toolkit explicitly supports this use case anyway. 🙂
I think Star Trek nailed the ideal mobile/desktop split decades ago: people use their mobile devices for communication, information gathering, and relaxing, but when they need to be productive, they use the huge desktop-computer-style consoles built into the walls of their ships. The bigger devices offer speed, power, precision, and good multi-tasking. When you need to get something important done, those are more important features than being able to have the device in your pocket or purse all the time.
The lesson is clear: portable mobile devices are for convenience, not productivity. Mobile isn’t going to kill the desktop any more than air freight killed rail freight. They’re just for different things.
“Menubars are old and clunky and clumsy and obsolete and a relic of the past”
If this is true, why haven’t we come with anything better yet after more than two decades of user interface experimentation?
- MS Office style Ribbons take up much more space than the combination of a menubar and toolbar they replace, make it harder to find what you’re looking for when the context sensitivity feature isn’t implemented perfectly, and don’t teach the user keyboard shortcuts.
- Hamburger menus in the toolbar have to leave out most functionality or else they become too cluttered. Most also don’t make any effort to teach the user keyboard shortcuts.
- Action drawers that slide in from the left or right are basically just hamburger menus, with all the same drawbacks.
- Inline controls were already addressed above.
I have yet to encounter a feature-rich, high-functionality desktop app that completely does away with the concept of the main menubar without feeling awkward, crippled, slow, or like something has been left out. I’m sure someday we will kill the menubar after we’ve invented something genuinely better that doesn’t feel like a regression in any way, but we’re not there yet.
And in the meantime, you don’t declare something to be dead before you’ve actually killed it.
The menubar isn’t dead yet for desktop apps because we haven’t yet come up with anything that’s universally better. The GTK & GNOME approach has a hamburger menu on the toolbar that holds global controls, coupled with a limited number of inline editing controls. most of which are only available via a hidden UI (the right-click context menu or undiscoverable keyboard shortcuts). This is not a solution, it’s a regression: many features must be removed or hidden to make it not visually overwhelming; the inline controls are invisible unless you think to right-click everywhere; and it’s impossible to learn keyboard shortcuts at the moment of use. This is a steep price to pay for visual cleanliness and approachability.
Displaying a title is an application-specific issue
Only when there’s no titlebar. 🙂
When the window manager guarantees your window a titlebar, app developers don’t have to reinvent the wheel by implementing custom labels to solve the same problem over and over again; they just set the title appropriately and move on.
Iff you implement a headerbar but want to put a title in it, it competes for space with the rest of the items in the headerbar. That means it can’t be very long unless your app has almost no UI controls exposed on the headerbar, which is a problem for any application that could benefit from showing a long title–like web browsers, where the titlebar has traditionally showed the website’s title (imagine that).
When you use a traditional discrete titlebar, you don’t have any of these challenges to solve, so you can focus on more important parts of your app.
Headerbars were meant for simple apps; it’s okay for complicated professional apps to not use them
Some people defend headerbars by arguing that the menubar is obsolete, then say that complicated apps can and should still have menubars. This doesn’t work: either menus are obsolete, or they aren’t. If they aren’t, then removing them is a mistake.
The better argument is that headerbars are only intended for very simple apps that don’t really benefit much from a menubar anyway because most of the default entries are inapplicable and would be disabled placeholders. I already acknowledged that it’s probably fine to remove the menubar for very simple apps that don’t have selectable text or do any file handling. But as I mentioned before, there’s no reason why you need to implement a CSD headerbar if your app doesn’t have a menubar.
It’s KDE’s fault for not supporting client-side decorations properly, so nobody should avoid them just to work around KDE brokenness
There is a kernel of truth here: KDE developers have indeed opted not to support GTK client-side decorations as they are currently implemented.
However, this is only because that implementation utilizes optional extensions to the standard that are very challenging for KWin to also implement. Many of KWin’s architectural design decisions reflect the original spec, and not this optional extension to it. Adding support is very technically challenging, and was judged to present an unacceptable risk of breakage.
At this point, GTK developers may be thinking, “Well, that’s not my problem that you wrote KWin in such an inflexible way.” But it’s not quite kosher to extend a spec with an optional single-vendor extension and then blame other people for not adopting it. That’s not really following the spec.
Nonetheless, there are rumblings of being able to support GTK CSDs in Wayland. For now though, the situation on X11 is unfortunate but pretty much unavoidable. You can’t break a spec and then ask everyone else to support your brokenness; it defeats the entire purpose of having a spec in the first place.
Anyone interested in more of the technical details can read through the comments in the following bug reports:
https://bugs.kde.org/show_bug.cgi?id=379637
https://bugzilla.gnome.org/show_bug.cgi?id=csd
https://gitlab.gnome.org/GNOME/gtk/issues/499
https://gitlab.gnome.org/GNOME/gtk/issues/489
https://gitlab.gnome.org/GNOME/gtk/issues/215
https://gitlab.gnome.org/GNOME/gtk/issues/488
The bottom line is that it’s not fair to blame KWin and its developers for not supporting the GTK developers’ decision to implement client-side decorations without extending the X11 window manager spec so that everybody could follow it.
—
I hope this post helps to clarify my position on CSDs. I suspect that these rebuttals won’t put the issue to rest because CSD headerbars have always been more about aesthetics and vertical space savings than functionality, power, and flexibility. That’s fine! all of these arguments I’m making are sort of a roundabout way of saying that I prefer the latter traits to the former ones. I think it’s a good thing that we have choice in the desktop space–real choice, where well-implemented competing visions and design goals appeal to different sorts of people. And that’s what we’re all doing here: empowering people to find what works best for them so their needs and desires can be provided by high-quality open-source software that respects their privacy, freedom, and need for highly usable and productive applications.
Adventures in Linux and KDE 
If I wanted the Gnome look then I’d use Gnome.
LikeLike
I 100% agree with the article and I think that the reason people hate title bars is that they see it as a waste of vertical space. My “Plasma Sets” mockup (https://phabricator.kde.org/M128) makes title bar useful again using a concept KWin already know: tabs.
– you can drag a window from title bar empty space
– if you open many tabs some space on the right could be left to ensure dragging surface
– it would be managed by Kwin so KDE developers can guarantee usability for every window
– it would be optional, if tabs will be enabled by default you aren’t forced to click “+” button and add more. An option to totally disable tabs could be added in settings
– it would unlock a lot of capabilities of Plasma as described in the mockup
LikeLiked by 1 person
Yeah I’d love to get back the tabbed-windows functionality we used to have. Not entirely sure I’m on board with the exact implementation you’ve got there, but it’s certainly an interesting approach!
LikeLike
Thanks Alex! The problem with putting tabs in the titlebar is that they reduce the window drag area, because the tabs themselves have to be draggable. I pointed out this issue with Firefox’s CSD and while I love those mockups, it looks like they’d suffer from the same problem. As you suggest, you could reserve a certain percentage of the titlebar for drag area and not let tabs go there, but then people would complain that this space is “wasted”.
These types of design compromises is why in general I prefer to separate distinct elements rather than trying to merge them into some sort of hybrid.
LikeLike
> but then people would complain that this space is “wasted”
You are right, the only solution I can think is an option that let the user increase/decrease that space (Firefox actually has an option to show/hide a drag area before the tabs).
Anyway the comparison with Firefox is not accurate, because in a web browser the number of tabs is really high compared to other apps. I have an average of 2-3 tabs with apps like Dolphin and Konsole. Even with Plasma Sets the number of tabs per window isn’t meant to increase like the one of web browsers.
LikeLike
I thought I saw in the Mockup that one of the goals was that web browser tabs would be merged with window/app tabs though.
LikeLike
But you’re still interfering with the dragging function of the titlebar by putting draggable widgets (and only draggable widgets) in there. Why not just stuff a toolbar in there? That way you save vertical space regardless of whether the app has tabs and you don’t interfere with dragging. Safari and Gnome web don’t put tabs in the titlebar.
Most apps don’t need tabs at all (so you get inconsistency too, and the payoff is minimal), and those that do usually don’t need it at the very top. I suppose if you could have tabs at the edge of the screen, that might be useful for browsers where you’re clicking tabs constantly, but that’s only if you don’t have a panel on the top. In that case it makes sense to put tabs on the very bottom.
IMO, a dedicated tab swticher tied to an single key accelerator (like a window overview) would probably be the most efficient way to manage lots of tabs anyway.
LikeLike
In your mock-up, the title of the web page is not visible. The title is usually shown in the title bar.
LikeLike
I completely agree with Alex L. While I think that CSD is evil and must be avoided by all means, and that every window should have a standard title bar managed by the server, I also think that tabbed interfaces are nowadays a standard UI paradigm that conceptually replaced MDI interfaces. It’s a shame that there is no “standard”, server-managed way to handle tabbed interfaces. Placing tabs on the title bar (while leaving a customizable dragging area above tabs, e.g. when windows are not maximized), and doing this by relying to a server-sided API that would guarantee consistency between apps, would be the right thing to do IMO.
LikeLike
I agree with you on most of your arguments. You’re right. In many productivity focus apps the need of menubars is a reality. Traditional menus are necessary when you have a lot of functionality in your application. But your vision is “white and black”. CSD and headerbars allow more simple applications to look modern and save screen space, apps like weather, image viewer, clocks, and that kind of stuff.
The problem of KDE Is than you don’t now how be flexible.
I’m not talking of be like GNOME with all CSD. I’m just saying than this can help improve User experience in simpler apps.
LikeLike
But why stop there? Look at the mobile versions of these apps; they generally don’t have toolbars at all. A truly simply app should probably go that route. If your app has enough features to merit a toolbar, I think that making that toolbar pull double duty to also be a titlebar involves too many design and usability compromises.
LikeLike
You can replace traditional menus with a big HUD interface. In the past, stuff like Unity HUD was only good for search, not for poking around with the mouse. So they relied on menubars being visible somwhere. But there is no reason why you can’t roll the point-and-click features of a menubar into the HUD popup. In fact it would be better than a menubar since you’d have more space to click around and browse.
I’ve outlined this here (this was just a rough draft – not a full design.) https://medium.com/@leftcrane/gui-hud-using-global-menu-features-hacks-572760272168
LikeLike
I wrote a response here: (https://www.reddit.com/r/kde/comments/ay5o7k/more_on_headerbars_rebuttals/ehz1zdb)
See the mockups at the end, though they are old and not very coherent from a design standpoint.
The summary: the debate between headerbars and traditional interfaces has a one solution and one solution only. The solution is server-side headerbars (DWD or similar) *plus* large HUD palette (actions palette plus search). KDE made a big mistake IMO in abandoning DWD.
Neither Gnome’s HIG nor traditional UI offers a satisfactory resolution. The longer these two dueling alternatives dominate the debate, the worse the Linux desktop is going to get. Eventually, it the situation will be beyond saving.
LikeLike
I much preferred Unity’s way of preserving vertical screen real estate. Provide a global menu on the top of the screen, ala MacOS style. Then when a window is maximized, integrate the titlebar with the menubar. The beautiful thing is all that is possible by utilizing functionality that already exists in Plasma and Kwin, with maybe a couple Plasmoids to add titlebar functionality to a top panel.
LikeLike
It is really nice to see that somebody in KDE is actively working and thinking about these topics. Like you said in your previous post, for some “je ne sais quoi” GNOME and OSX applications look way better than KDE’s and that should get fixed.
Something that seems interesting to me is that your replies are often full of axioms that as far as I know you (and maybe the KDE team?) are taking as hard truths. For example you seem to put a lot of emphasis on “Drag Space”; perhaps that bothers you a lot, but it seems that the operating system who promote windowing the most (OSX and it’s lack of maximize and enforcement of size hints) do not mind that at all.
Maybe, users prefer the harmony and feel of these kind of desktop apps over the dragging space? At the end of the day you do not move windows that much compared with the amount of time you spend looking into the app.
It was long ago, but I remember reading a UX study from Microsoft, around the Windows 7 days, that explained how most hardcore desktop users (the creators) used mostly 9 apps, 4 of which on a daily bases. Their data was taken from Windows metrics, so I guess that it was either true and accurate or the entire thing was a lie.
Anyway, If that would be true, the dragging space wouldn’t be a problem at all since:
– Regular users will create muscle memory to move the few windows they use (these days perhaps it is just the browser).
– Advance users will either do that or learn the tips and tricks of the operating system.
I am not claiming to hold the truth here, most probably the truth lies somewhere in between the KDE’s priorities, the current userbase, the developer own tastes… But something I would as you guys and girls for is to try to take a step back and revisit everything you think you know, because from reading mailing list and KDE planet it seems that you are working with a knowledge base that might not be as solid as you might think.
Cheers and keep up with the awesome work you all are doing.
LikeLike
> GNOME and OSX applications look way better than KDE’s and that should get fixed
Maybe it’s just a matter of default settings? Here I just changed the color scheme and toolbar buttons and Dolphin looks way better for me: https://i.imgur.com/YxW3QeG.png
LikeLike
That’s more or less the Breeze Light theme, which we do have plans to make default for aesthetic reasons once we can ensure that there’s adequate contrast between focused and un-focused windows.
The next thing is to use single-pixel horizontal lines to separate the view area in the middle from the toolbar above it and the status bar below it, like we do in the Kirigami apps. Basically we move to separating elements with lines rather than showing a visible frames and letting the frames’ own lines separate elements.
I honestly think these two changes would get us 90% of the way there. Just gotta find the time to do it…
LikeLike
I, for one, don’t like that style at all.
Way too bright, way too symbolic, and way too flat.
Different people, different tastes.
LikeLiked by 1 person
> but it seems that the operating system who promote windowing the most (OSX and it’s lack of maximize and enforcement of size hints) do not mind that at all.
And this was one of the biggest reasons what makes windowing on MacOS horrible. Maybe Apple does not mind it, but I mind it enough to go back to using KDE after 4 years of accidentally moving windows around on MacOS.
LikeLiked by 1 person
> MS Office style Ribbons […] don’t teach the user keyboard shortcuts.
That isn’t true: Press Alt in Windows Explorer and it’ll show you the keyboard shortcuts to navigate the menus. Also the tooltip of buttons will display the shortcut for an action (e.g. Ctrl+C for Copy).
LikeLike
Both of those are invisible by default, compared to menus where the keyboard shortcut is visible by default. That means you need to actively go hunting for them, which is the opposite of discoverability.
LikeLiked by 1 person
I agree with everything you’ve said here.
I hate working with maximized windows except for certain applications such as watching a video.
Otherwise I keep a bunch of windows open, browsers and editors are usually portrait aspect ratio almost the height of the display, the size of others depends on their content. They tend to overlap so I can see relevant content in some while working in another.
I have a large high resolution monitor so I can do this.
I also agree about titlebars and menubars. The titlebar helps me positioning and repositioning the windows and allows me to quickly identify what the window is.
As you said, every attempt to remove the menubars has made it harder to discover how to do actions, particularly those you don’t use often.
LikeLike
I have another suggestion to make title bar more useful:
while it’s bad from a semantic point of view the apps could ask KWin to draw some custom buttons. Like Ken’s Dynamic Window Decoration but with just 1-2 buttons, no other complicated widgets. It would also be cool if the user could move to the title bar any button from KDE’s standard toolbar maybe using its settings dialog (Menu > Settings > Configure Toolbars…)
LikeLike
I love titlebars, and you can only pry ’em from my cold, dead hands.
LikeLike
I like both posts and really hate header bars, especially the ones which take more place than a title bar and a menu bar together.
When it comes to themes, I really dislike current KDE themes. Switch the window decoration to plastic and you get a real titlebar again with contrast, real buttons and a nice border and you get the point in having a title bar a lot more than with the modern titlebars which try to look like a part of the window. Of course, its a matter of taste. I just think current plasma 5 has too little contrast.
I really like the idea of providing an API to programs, to place additional buttons in the window title. I think there should probably be a “hands off” option in the KWin options and the whole thing should be specified and not implemented as KWin-only feature.
LikeLike
Might you be using a non-default theme without realizing it? The default Breeze theme has a dark-colored titlebar that doesn’t try to blend into the window.
LikeLike
What would it be like to have KWin give us “title-tabs” like BeOS had? And then stack the tabs such that they don’t overlap each other behind other windows?
I always appreciated this little screen optimization from Be and wondered why it didn’t advance to other OS’s.
https://en.wikipedia.org/wiki/BeOS
LikeLike
Hello Nate, I read your interesting point of view and I have to say that till a few weeks ago I agree with you, but finally I ended up to enable client side decorations on Chromium and I like it.
It’s not too much space I gained for viewport height, but better little than nothing. I don’t need to see window/tab title, I don’t need too much drag space because I have Chromium maximized quite always and I don’t even need kwin window shadows because even if they are beautiful too see, I don’t care to sacrifice them for more usability and much space in the viewport (and since I use it maximized quite always, so I didn’t see them). And menubar? I don’t need it either, there’s quite everything in the dropdown menu.
That does not mean I want all applications with CSD, but I think your point of view is not flexible. It’s just that some applications take advantage from it and some others don’t. So, please, don’t be too drastic on this topic. Assuming that CSD should never be allowed for desktop user interfaces won’t get any benefit to Plasma Desktop.
I know that GNOME made a mistake to push CSD without a standard specification or something similar that could be easily handled by Kwin, but even pushing your point of view as an axiom is also a mistake. I’m afraid that CSD will be more and more used in the future and at some point you devs in KDE will figure out to be left out.
Thus, please, don’t be mainly focused on your concept of user interface. In technology sector maybe they are not devs to establish a standard concept, but the majority of users who use applications. Just focus on usability. Plasma is a good DE. It’s flexible and customizable. And can be improved to be still better than what is now. But, NO, banning CSD all the way is not flexible, neither customizable in certain cases.
LikeLike
> It’s not too much space I gained for viewport height, but better little than nothing. I don’t need to see window/tab title, I don’t need too much drag space because I have Chromium maximized quite always and I don’t even need kwin window shadows because even if they are beautiful too see, I don’t care to sacrifice them for more usability and much space in the viewport (and since I use it maximized quite always, so I didn’t see them). And menubar? I don’t need it either, there’s quite everything in the dropdown menu.
You’ve listed some features that made it much easier to use a software (in this case, Chrome). However, don’t you agree there can be other applications where the same things will be useful? (Lets say another application which you have “maximized quite always” and don’t need menubar). I’m quite sure the answer is yes, and hence you should be able to enable these features in *ALL* applications you want, not just Chrome. Relying on CSDs will never make that happen.
The problem is that what is “usable” for one user might be unusable for another. That is exactly why Plasma/KWin are so flexible. But, CSD means that application designers decide what is “usable” which breaks usability for every person they didn’t account for (and shouldn’t have to).
At the end, the user should have control (via the Window Manager and the Desktop Shell) to adjust how an application behaves.
> In technology sector maybe they are not devs to establish a standard concept, but the majority of users who use applications
Exactly. However, more often than not, I find myself in the minority of users who the app designers don’t care about. Technology like Plasma/KWin come to the rescue here by giving me an escape hatch that I can override the default design.
LikeLike
I already said that not all applications can benefit from CSD. However, you can’t always override the default design with Kwin. That’s a misunderstanding. Kwin is, yes, customizable, but not always flexible and it’s just not enabled when a GTK app uses CSD. You might do it with a hack (there’s a package on GitHub called gtk3-nocsd), but that’s not Kwin, it’s another thing. That means if I don’t want a title bar, but want a shadow around the window, I can’t get it. I can get both… or nothing. Not quite flexible here.
You can say, it’s CSD fault, but that’s not really right when CSD is useful on a specific app. Think an app like Kmix (it’s a Plasma app, not GTK). Titlebar is useless on it. You want it? OK, you already have. But what if I don’t want it?
So we go on another matter: if I don’t want a title bar in a Plasma/Qt app, I have to disable borders completely and I will miss close, maximization and minimization buttons! Not flexible here neither, because I will end up to miss three useful buttons.
This topic is very hard and it’s very difficult to satisfy everyone, but if we can agree that pushing CSD on everything (just like gnome wants) is a mistake, then forcing SSD and close/maxi/mini buttons inside the title bar is not always flexible and having only this UI concept is also a mistake.
LikeLike
> but that’s not really right when CSD is useful on a specific app
I agree with you that there can be CSD elements (like collapsing menubars to a dropdown) that are useful. What I don’t like is that being restricted to only one app. I might find it useful for other apps as well, but I’ll have to just hope other apps also implement that CSD element. (Another example is “Always On Top” on Windows/macOS. Only specific apps implement it on those platforms, but on most Linux DEs you can use that on *any* window, and its damn useful.)
> But what if I don’t want it?
You can set Window rules in KWin to hide it. Problemo solved (well almost, I read your point about the buttons afterwards).
> because I will end up to miss three useful buttons.
Yes, that is a problem. But is CSD really the solution? I remember reading a blog post from one of the KDE devs on a spec that allows apps to display stuff like close/min/max butons inside themselves when the user chooses to.
The other, simpler solution is to just use Alt+F4 or right click > close on the Taskbar entry. Sure, its not intuitive as the buttons, but then, saves you the titlebar without having to make an app responsible for window management.
> This topic is very hard and it’s very difficult to satisfy everyone
+1
> but if we can agree that pushing CSD on everything (just like gnome wants) is a mistake, then forcing SSD and close/maxi/mini buttons inside the title bar is not always flexible and having only this UI concept is also a mistake.
You say “some apps” can use CSD, but then, how do you define the criteria? Or, maybe people will be happy if they can choose to disable them:
Dolphin without menubar (the default)-
But, if you want the menubar back, you can do so-
LikeLike
Headerbars work for all apps, no matter the complexity. On Gnome, the buttons don’t interfere with WM at all. You can even set right-click to maximize, and maximize by right-clicking on a button!
So they aren’t the problem – the problem is Gnome’s approach to CSD and the menubar.
The universal solution would be server headerbars plus a more powerful menu button, which would bring up a large (or small depending on need) command palette with search, clickable items, and possibly even some options for extensions and customization.
This would make the Linux desktop first in class in terms of UI/UX consistency and workflow – well above Mac OS. You could use these server-side solutions to quickly cut through the crap UI/UX that has piled in Linux over the years.
But the way things are going now with Gnome’s CSD and KDE’s awkward app designs, Linux is poised to become worst in last in class on both fronts, worse than the Windows ecosystem.At that point it will be very hard to justify continuing to use Linux desktops, aside from sentimental reasons, since WSL is going to reach parity with Linux very soon.
LikeLike
> The universal solution would be server headerbars plus a more powerful menu button, which would bring up a large (or small depending on need) command palette with search, clickable items, and possibly even some options for extensions and customization.
Yep, that sounds good. I remember seeing a blogpost from a KDE dev about implementing the command search thing you’re talking about (I know, I know, I should really make a habit of bookmarking these things so that I can link to them :P)
> it will be very hard to justify continuing to use Linux desktops, aside from sentimental reasons, since WSL is going to reach parity with Linux very soon.
And that’d be cool if it works for you, really. I’ve used Windows since I was a kid, for 10+ years, and used macOS for 4 years till 2018. I’m back to Linux *because* of how productive KDE is, and I don’t really care having to “justify” it to everyone else.
LikeLike
That’s not really going to work, since it can’t replace the menubar, a concept that Gnome and Elementary have (for better or worse destroyed). You’d still need to put a menubar somewhere.
I propose instead a palette that’s BOTH clickable and searchable – one that can replace the menubar entirely. That’s a UI that’s firmly within reach. DWD is also possible, albeit more involved.
The way I see it, you need to take Gnome’s design to the logical conclusion and extend it to the frameworks and apps like Unity did. Otherwise the Linux desktop has – in my opinion – no advantages. It can’t compete with the commercial OS’ on apps or developer features, so it must provide a better base UI/UX to stay viable. This unfortunately isn’t happening, since no linux DE is offering anything significantly better that what we had 10 years ago. The most serious effort to upgrade the entire ecosystem was Ubuntu Unity and that got canned.
LikeLike
@leftcrane8502 @shantanutushar7
I think that a first solution would be to draw a shadow around the window rather than around the border, so if I don’t want the titlebar and the app can provide close/maxi/mini buttons inside itself, I can disable the border and can still see the shadow. That’s just a first step to get a better integration.
Maybe the solution is not so hard to find. Devs have two ways:
Don’t you want to handle decorations by your side? OK, just let Kwin (or another WM) draw the titlebar, the border and the shadow.
Do you want to handle decorations by your side? OK, you draw what you want and put the close/maxi/mini buttons somewhere, Kwin will only draw a shadow around the window.
Then don’t you like the design? Blame the developer, it’s a “client” side decoration, it’s not Kwin/Plasma/Linux/anyone fault.
LikeLike
I have noticed you don’t monetize pointieststick.com, don’t waste
your traffic, you can earn additional bucks every month with
new monetization method. This is the best adsense alternative for
any type of website (they approve all websites), for more details simply search in gooogle: murgrabia’s tools
LikeLike
I don’t want to monetize this site. I’m not a fan of ads, and I use an ad blocker myself to see as few as possible, so adding them onto my website would be hypocritical. Also using my influence to sell other people’s products would probably damage my credibility. The only thing I want this site to promote is KDE software! 🙂
LikeLike