Slashdot Mirror
Should Apps Replace Title Bars with Header Bars? (gnome.org)
Gnome contributor Tobias Bernard is on a crusade against title bars -- "the largely empty bars at the top of some application windows [that] contain only the window title and a close button." Instead he wants to see header bars -- "a newer, more flexible pattern that allows putting window controls and other UI elements in the same bar." Tobias Bernard writes:
Header bars are client-side decorations (CSD), which means they are drawn by the app rather than the display server. This allows for better integration between application and window chrome. All GNOME apps (except for Terminal) have moved to header bars over the past few years, and so have many third-party apps. However, there are still a few holdouts.
He's announcing the CSD Initiative, "an effort to get apps (both GNOME and third-party) to drop title bars and adopt GNOME-style client-side decorations... The only way to solve this problem long-term is to patch applications upstream to not use title bars. So this is what we'll have to do."
He's announcing the CSD Initiative, "an effort to get apps (both GNOME and third-party) to drop title bars and adopt GNOME-style client-side decorations... The only way to solve this problem long-term is to patch applications upstream to not use title bars. So this is what we'll have to do."
- Talk to the maintainers and convince them that this is a good idea
- Do the design work of adapting the layout and make mockups
- Figure out what is required at a technical level
- Actually implement the new layout and get it merged
Implementation is already in progress for Firefox, though it has not yet been started for other high-priority apps like LibreOffice, GNOME Terminal, and Skype. "If you want to help with any of the above tasks," writes Tobias, "come talk to us on #gnome-design on IRC/Matrix."
"I must make my mark by fucking up a user interface that's worked fine for thirty damned years!!!! Because I'm soooo much smarter than everyone else!!!"
The sad thing is, the dolts running Gnome might agree with this simpering jackass. Hell, can't pass up a chance to cram in more bloat!
Since there is empty space at the top for a title bar, other applications have been designed around that.
For example, Microsoft Remote Desktop puts a server bar at the top-center of the window.
Then there's Winamp, which can be sized down to be the size of a title bar and be kept always-on-top.
And the chance that I'll have any kind of consistent interface, when thousands of app-writers are rolling their own? ZERO!
"My opinions are my own, and I've got *lots* of them!"
There is a distinction between controls for an app and controls for a window manager.
These are two different concepts and should not be muddled up.
Similarly, should an app be able to bind Alt+Tab for its own use? No, of course not.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
I like my title bars and hate apps that think they're too important to cooperate with my window manager.
The GNOME UI people have apparently become addicted to changing well defined behavior in favor of some crazy shit. GNOME 3 caused a mass exodus of developers because of this, so all they have left is the people who think it's acceptable to completely change the UI whenever they feel like it. This is descending into the death throes of GNOME.
Anons need not reply. Questions end with a question mark.
have you ever tried to reposition a firefox or chrome window that is full of tabs?
what happens when the window manager uses BeOS style titlebars?
what happens to my webex/remote-desktop overlays when there is no empty space for them to live over?
somewhat related: have you ever tried to resize a window that does not have obvious resize control handles? or have you ever tried to *not* resize a window when the non-obvious control 'areas' take your click instead of the drag-to-select-text that you intended?
and don't get me started on scrollbars that appear and disappear depending on where you put your cursor instead of what the content is.
So, Tobias Bernard is trying to convince everyone to join his CSD Initiative
"tl;dr: Let’s get rid of title bars." he says. And what is the "tl" in this case ?
This isn't "too long". It's too short and illogical. "Title" is already the term for what he's trying to say so, he might simply be trying to say that applications don't need a title. So, I wonder he he's using a title ("Introducing the CSD Initiative") at his own article. My take: he's an idiot.
This is exactly why I quit using Gnome 20 years ago. Breaking UI conventions that work perfectly fine and destroying consistency.
Why in god's name would I want apps to cram even more useless controls in my face? A window needs two things: a title so I know WTH it is, and min/max/close buttons. That's it. Now Gnome is taking that away? Just for 20 pixels of real estate ?
Anyone calling themselves a "modern UI developer" should be tarred and feathered. Apple went to flat controls and borderless buttons. Microsoft made Office 2016 flatter than Kansas and decided light gray text controls on bright white background was somehow legible. Gnome has been lost in their own rabbit hole for decades. All of it making interfaces less intuitive and harder to use. A pox on all their houses.
Democracy is two wolves and a sheep voting on lunch.
Modern UI design is often more and more "hide and seek". URLs are hidden, menus disappear, scroll bars appear and disappear. Sometimes, one has the impression, UI designers wanted to play a prank. Adding more stuff in the title bar can be a good thing. But first a rant: I have worked on clunky user interfaces before in my life like VMS workstations, DOS, GEM on Atari or old Mac OS or even gopher browsers pre Mosaic, but the trend of "hide stuff" is driving me nuts. OS X by default does not show the hard drive, nor scroll bars. On browsers, both phone or desktop, things like URLs disappear. It is now cool to hide important things in cryptic places like three dots on the upper right corner in chrome. Or then windows which like to become full screen or adjust their position on their own. I have experienced less frustration writing from scratch a printer driver on an Atari than solving the trivial task to find the print button on a modern browser. Fortunately, it is in most cases still possible to configure things but it often needs first some searching maybe even looking up manuals. I understand that there are two forces in UI design, one which wants to hide things so that it is elegant and beautiful and so that the complexity is hidden and users protected from screwing things up. This is the "passenger" point of view, which mostly applies to consuming stuff. And then there is the need of speed and convenience, which asks for putting many things on the radar so that they can be accessed and found quickly. This is the "pilot" point of view, which mostly applies when producing stuff. The CSD initiative could be a good thing. I for myself like the title bar information. It tells me for each window, where and what it is. Let the user be able to configure it. And in general, be very gentle with changes. Even small modifications can disrupt work flows.
Most of those are designed by people who have never learned how to design UIs. Human-Computer Interface courses are available and I'd gladly run one for the GNOME team if I thought they'd pay attention.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
on the itty bitty bars at the top of my window on my 1080p monitor. I don't want clicking 'new tab' to feel like sniping somebody from across a map. I do, however, want hierarchical menus (File, Edit, View) that follow a consistent pattern making it easy to find things. Whoever came up with the Ribbon should be launched into space and fired out of an airlock.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I think you hit it on the head. I also would add that gnome 3 made the problem worse by having needlessly wide title bars. It feels like the loaded the dice a bit here..
As Mate Desktop has been progressing, they've been slowly replacing Gnome 3 apps (things like certain settings apps, the NetworkManager GUI, etc) with ones more consistent with the Mate Desktop, which is traditional and has regular window title bars.
I for one never use the title bar for moving a window. I exclusively use Alt-click to move a window from anywhere in the window. However I want title bars because they distinguish one window from another using the color theme of window decorations that I want. I can make them small and efficient use of space. Gnome is what is making server-side title bars so big and wasteful. Also with HeaderBar CSDs it's very difficult to distinguish between windows as the headerbar isn't distinct form the body of other windows. This is something I've always had a hard time with on Mac, especially in recent years.
The other thing I use title bars for is to roll up or shade the window, which I use nearly every day, particularly with terminal windows! I think Gnome 3 has the ability to shade apps, even with CSD, but I'm not sure. I saw at least one bug report that said it's no longer possible. But again, where would you click to do that? CSD header bars don't offer consistency in where you can click. Do you click on what looks like a title? blank space between buttons? Hard to know.
With Linux desktops we used to celebrate diversity and choice. Now it appears Gnome 3 would be perfectly happy to be the only choice (getting rid of KDE, Mate, etc), and have all apps be Gnome 3 apps. Why would Blender ever want to integrate into Gnome 3's header bar? Blender doesn't need to look integrated, nor would it benefit it to do so. In fat it might even harm it. Better to look different and remind users that they are operating in a specific environment with a specific methodology that must be learned.
The classic title bar performs several functions of varying utility. Let me count them.
1. As the title suggests, the title bar displays the title of the window. This typically includes the name of the application and the name of document currently opened, and can easily take half the space available or even more.
2. It lights up when the window is active, and dims down when inactive, helping the user maintain focus with a busy desktop.
3. It provides an intuitive, discoverable way of dragging the window. (For experienced users, Alt+dragging is more usable, although less discoverable.)
4. It is a big target for (un)maximization via double click.
5. It is a big target for opening the window control menu via right button click.
6. It houses the window manager controls.
7. Last but not the least, the title bar is provided by the window manager in a manner consistent across the desktop. If every application toolkit starts doing its own header bars, we lose this consistency.
... And frankly, that makes me think this should be the role of the window manager....
I would agree with that. The only reason why I put the onus on the app was that I was dumped upon the last time I brought it up for windows managers. Everyone told me it was the apps' responsibility. Seems like a lot of "not my job" finger pointing, imo. But I still have to ask, why is it still missing in GNU/Linux?
.
It's a basic ease of use requirement. Why make the user resize and relocate a window each time the same app is opened? Aren't computers supposed to help reduce the number of repetitive tasks, not create more of them? KDE comes close on this, allowing me to remember size/location for individual windows, but the ability is sadly absent in the global settings area.