| |||||||||||||
Wayland and Weston 1.0 releasedWayland and Weston 1.0 releasedPosted Oct 25, 2012 15:58 UTC (Thu) by mpr22 (subscriber, #60784)In reply to: Wayland and Weston 1.0 released by Seegras Parent article: Wayland and Weston 1.0 released This argument would be more convincing if it weren't for the fact that programs acting as if they don't trust the WM to provide them with furniture have been around on X11-based platforms for over a decade.
(Log in to post comments)
Wayland and Weston 1.0 released Posted Oct 25, 2012 23:43 UTC (Thu) by Jandar (subscriber, #85683) [Link]
What programs would that be and how do they corrupt the decorations of the WM? The prospect of windows with different title-bars and arbitrary positioning of respective buttons is scary. IMHO client-side decorations are an abomination. The one reason mentioned in https://www.youtube.com/watch?v=L8zwnqKysfI for this is a smoother border between decoration and a tilted window. I couldn't care less. Enforced consistence of window-managing buttons is far more important. Why don't the wayland compositor compose the original application-window and the decoration into one resulting window and do the following transformations on this new window? In the video it was said such embedding of windows is highly performant even in the case of nested compositors.
Wayland and Weston 1.0 released Posted Oct 26, 2012 4:03 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
They set a hint asking the window manager not to draw any window decorations, and then they draw their own. xmms is a pretty obvious example.
Wayland and Weston 1.0 released 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
> I think Firefox does it now too.
> X11 offers (and forces you to use) myriad ways to tell the window manager to shut up and get out of the way
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).
Wayland and Weston 1.0 released Posted Oct 28, 2012 16:02 UTC (Sun) by nix (subscriber, #2304) [Link]
Yes (hello, XMMS), and they're horrifying and I don't use them. The thought of *every* application doing that... also, currently decorations are highly customizable. If they're under toolkit control, the likelihood is they won't be. I'd find that annoying.
|
|||||||||||||