I don't have a strong opinion on the question of CSD. I can certainly see the benefits it offers, but also the problems.
> And Chromium
Chromium on Linux has an option "Use System Title Bars and Borders" which turns WM decorations back on. (Click on the empty area next to the tab bar)
> I think Firefox does it now too.
Not on my system at least -- still looks Gnomey.
> X11 offers (and forces you to use) myriad ways to tell the window manager to shut up and get out of the way
That's not a problem really -- most apps will accept WM decorations for their main window because that's the natural thing to do. The ones that you're listing (Chromium and XMMS) are exceptions.
The problem is the *common* case with Qt apps running on a Gnome desktop or GTK apps running on a KDE desktop -- they will look inconsistent and possibly behave inconsistently too.
Or consider toolkits that until now didn't *need* to render their decorations -- I wonder whether Tkinter and FLTK even have any decoration-rendering code because usually the OS will be happy to provide that. Now they need to implement decorations themself or rely on some new external dependency (probably a competing toolkit).
Posted Oct 26, 2012 21:42 UTC (Fri) by daniels (subscriber, #16193)
[Link]
> The problem is the *common* case with Qt apps running on a Gnome desktop or GTK apps running on a KDE desktop -- they will look inconsistent and possibly behave inconsistently too.
They already do. The contents look totally different. They're designed according to HIGs with fundamentally different ideas. They don't have the same VFS, or open/save dialogs. The button order (OK vs. Cancel) is different. The printing UI isn't common. Keyboard shortcuts are different. And so on, and so forth.
CSD means that window decorations are inconsistent in between applications, but it means that the frame and the application themselves are at least consistent. Swings and roundabouts.
> Or consider toolkits that until now didn't *need* to render their decorations -- I wonder whether Tkinter and FLTK even have any decoration-rendering code because usually the OS will be happy to provide that.
The pithy answer to this is 'life's tough'. Writing a toolkit is already really, really hard. (Window managers too.) You'd be surprised how difficult it is; the /topic in #xorg-devel for years was 'seriously, don't write your own toolkit or window manager'. Especially in X11, and especially with all the synchronisation nightmares that external decorations bring you. It's a lot of code, a lot of frustrations, and a hell of a lot of corner cases.
Wayland greatly simplifies that on the whole by removing a lot of the truly difficult parts (e.g. size incoherence) and hair-tearing corner cases, and since toolkits already render all the content, then I expect rendering decorations won't exactly be onerous for them.
The exception to the rule here is SDL, which AIUI doesn't do any drawing of its own. But that's widely-used enough that I expect they'll be able to adapt quite easily.