Posted Oct 26, 2012 11:39 UTC (Fri) by daniels (subscriber, #16193)
[Link]
And Chromium. I think Firefox does it now too.
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.
Wayland and Weston 1.0 released
Posted Oct 26, 2012 20:07 UTC (Fri) by intgr (subscriber, #39733)
[Link]
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).
Or am I missing something?
Wayland and Weston 1.0 released
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.
Wayland and Weston 1.0 released
Posted Oct 31, 2012 15:53 UTC (Wed) by daglwn (subscriber, #65432)
[Link]
> 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.
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.
Wayland and Weston 1.0 released
Posted Nov 2, 2012 10:09 UTC (Fri) by intgr (subscriber, #39733)
[Link]
> Frozen unkillable windows is my biggest concern with this.
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.
Wayland and Weston 1.0 released
Posted Nov 2, 2012 15:23 UTC (Fri) by nix (subscriber, #2304)
[Link]
They're still immobile, though (although admittedly even in X, frozen windows can be dragged but can't be repainted, so they end up looking ugly -- but at least you can get them to get out of the way.)
Wayland and Weston 1.0 released
Posted Nov 2, 2012 16:09 UTC (Fri) by intgr (subscriber, #39733)
[Link]
> They're still immobile, though
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.
Wayland and Weston 1.0 released
Posted Nov 2, 2012 20:30 UTC (Fri) by nix (subscriber, #2304)
[Link]
Ah, right. I'd say the useful properties are retained -- you can move a stuck window mostly off the screen if need be. Resizing a stuck window is much less important (at least in my workflow).