Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Wayland and Weston 1.0 released
Posted Oct 26, 2012 11:39 UTC (Fri) by daniels (subscriber, #16193)
But yeah, funny how you never saw anyone decrying XMMS as the death of UNIX, and it never seemed to be a particular problem then.
X11 offers (and forces you to use) myriad ways to tell the window manager to shut up and get out of the way. Setting the override-redirect flag on your window - which is required for all menus, combo boxes, tooltips, screensavers, and other things I can't remember off the top of my head - makes it impossible for the window manager to in any way influence what goes on.
Posted Oct 26, 2012 20:07 UTC (Fri) by intgr (subscriber, #39733)
> 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).
Or am I missing something?
Posted Oct 26, 2012 21:42 UTC (Fri) by daniels (subscriber, #16193)
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.
Posted Oct 31, 2012 15:53 UTC (Wed) by daglwn (subscriber, #65432)
Heh. I took one look at XMMS and decided it was unusable precisely because of the application-managed decorations making it really non-intuitive. Consistency is important.
I'm not necessarily saying Wayland is wrong here but it is definitely something to keep on top of. Frozen unkillable windows is my biggest concern with this.
Posted Nov 2, 2012 10:09 UTC (Fri) by intgr (subscriber, #39733)
This has already been solved in Wayland (or Weston, whatever). Whenever the toolkit pops up a new window, it can register a certain clickable area which acts as the "kill button" if the window isn't responding to events. Normally this area overlaps with the close button on the title bar.
Posted Nov 2, 2012 15:23 UTC (Fri) by nix (subscriber, #2304)
Posted Nov 2, 2012 16:09 UTC (Fri) by intgr (subscriber, #39733)
As far as I understand, dragging (moving) windows will still work -- the draggable title bar is registered with a similar hint like the kill button. Window placement and moving is now exclusively the job of the compositor -- windows don't even receive move events and they may not have a well-defined position with respect to the screen any more, because the compositor is free to do anything with them.
But you're right, resizing windows will probably not work as it does in X11.
Posted Nov 2, 2012 20:30 UTC (Fri) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds