Recent Features
| |||||||||||||
Wayland and Weston 1.0 releasedWayland and Weston 1.0 releasedPosted Oct 25, 2012 15:42 UTC (Thu) by Seegras (subscriber, #20463)Parent article: Wayland and Weston 1.0 released
I'm not entirely convinced of the Wayland model, because of something totally different than what everyone is always bickering about...
Window decorations under client control. I can just see things like this
(Log in to post comments)
Wayland and Weston 1.0 released Posted Oct 25, 2012 15:58 UTC (Thu) by mpr22 (subscriber, #60784) [Link] 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.
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.
Wayland and Weston 1.0 released Posted Oct 26, 2012 0:54 UTC (Fri) by daniels (subscriber, #16193) [Link]
If you don't trust your applications to do things like shut down correctly, or to not be an entrant into a hall of shame, then don't run them.
The non-technical argument for client-side decorations (which isn't the reason for having them), is that you gain consistency between the app contents and the frame; that phone example you linked to wouldn't be enhanced by being in a window with totally random decorations that don't in any way fit the app. Although, on X11, it'd probably do as Chromium, XMMS and a million others do and have done since the dawn of time and draw their own decorations anyway.
But the technical argument of not needing the synchronisation between the frame and content windows is more than enough - you have no idea how painful that is.
Wayland and Weston 1.0 released Posted Oct 26, 2012 8:48 UTC (Fri) by renox (subscriber, #23785) [Link]
There is another argument for server side decoration that you fail to consider: smooth resizing of the window.
With client-side decoration, if the application is slow to answer the resizing will feel 'jerky', with server side decoration the window will resize smoothly but the content of the window will be "ugly". That's a tradeoff but I prefer smooth resizing.
Wayland and Weston 1.0 released Posted Oct 26, 2012 9:04 UTC (Fri) by daniels (subscriber, #16193) [Link]
With client-side decorations, the client sends exactly one buffer to the server - the complete window - every time it resizes.
With server-side decorations, every time the window's resized, the server has to create and fill a new buffer with the frame, then do a stretch blit (or fill the undefined contents with a solid colour, or whatever) of the contents into the frame window. Asynchronously, the contents are updated and the updated contents are blitted back into the frame. Aside from the waste of resources from the additional buffer, I believe it looks measurably worse. The 'spasm' as you get the frame changing size, followed by the content being stretched, followed by resized content (quite possibly from an old resize event, so just beign differently stretched) is pretty horrific.
Additionally, if your problem is resource starvation such that the client can't keep up, adding additional load in the form of the server drawing decorations for sizes the client's never likely to make, and the extra resource load from the additional blits, exacerbates the problem.
I'd much rather just have the pointer lagging a little behind.
Wayland and Weston 1.0 released Posted Oct 26, 2012 9:33 UTC (Fri) by renox (subscriber, #23785) [Link]
>Additionally, if your problem is resource starvation such that the client can't keep up,
This isn't the only reason why clients cannot keep up: applications do many thing, so if you don't dedicate a thread to the GUI, a client can be slow to answer even if the system isn't loaded.
>I'd much rather just have the pointer lagging a little behind.
It's a matter of personal preference, I don't!
Wayland and Weston 1.0 released Posted Oct 26, 2012 10:00 UTC (Fri) by daniels (subscriber, #16193) [Link]
Also, the other other reason is that it significantly complicates event handling, and creates absolutely nightmarish corner cases. Client-side decorations have the nice property of ensuring that windows actually have a single defined size, rather than size being some kind of mystical transient property that's likely to have changed by the time you submit your request.
Wayland and Weston 1.0 released Posted Oct 26, 2012 11:36 UTC (Fri) by renox (subscriber, #23785) [Link]
Oh, there is no question that client-side decorations have benefits.
But there is still this issue of jerkiness when the client is busy and even with a dedicated GUI thread the client may become busy if for example the client use a non-realtime GC (most of the GCs are not real-time), etc.
Loosing smooth resizing of windows is a HIGH price to pay for the benefits of CSD.
Wayland and Weston 1.0 released Posted Oct 26, 2012 11:47 UTC (Fri) by daniels (subscriber, #16193) [Link]
It's not smooth. Your app goes from actual rendered content -> scaled content -> scaled content -> scaled content -> actual rendered content -> scaled content -> scaled content -> actual rendered content. Imagine an app with a status bar, where you're enlarging the size: your status bar goes from its natural size with sharp fonts, to bigger and blurry, to bigger and blurry again, back to its natural size with sharp fonts, and so on, and so forth. It's a disaster for text, where you see the exact same thing, except even more jarring because the text is likely to get reflowed.
The rapid spasming transition is really, really jarring, and objectively speaking, the scaled content looks worse than genuine client-rendered content. All this is in direct conflict with Wayland's core ethos of 'every frame is perfect'.
So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
The only benefit it has is the frame window following the pointer.
(And hey, if it forces app authors to actually think about making their clients more responsive to user interaction, that's no bad thing at all.)
Wayland and Weston 1.0 released Posted Oct 26, 2012 12:33 UTC (Fri) by renox (subscriber, #23785) [Link]
>It's not smooth.[cut]
*Sigh*, at the beginning of the discussion I said 'with server side decoration the window will resize smoothly but the content of the window will be "ugly"' so I know..
>objectively speaking, the scaled content looks worse than genuine client-rendered content
And "objectively speaking" having the frame of the window resize smoothly all the time is better than resizing jerkily when the application is slow to answer to events.
I don't read the text of my windows while I'm resizing them, that why I care more about smooth resizing of the windows frame than having a nice content inside, that is a *trade-off* you prefer one option I prefer the other, that's all.
>And hey, if it forces app authors to actually think about making their clients more responsive to user interaction, that's no bad thing at all.
I actually agree with that, but as I've already said it's not easy at all, especially if you use a GC!
Wayland and Weston 1.0 released Posted Oct 26, 2012 16:05 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
This also seems to cover the use case you are looking for, similar to how some older WMs worked.
Wayland and Weston 1.0 released Posted Oct 26, 2012 16:30 UTC (Fri) by renox (subscriber, #23785) [Link]
>> So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
> This also seems to cover the use case you are looking for, similar to how some older WMs worked.
Not really, you loose information about how your window will look when resized which is annoying, but I think that this configuration is the best when you're using remote applications on high latency communications, so it's still an interesting configuration.
Wayland and Weston 1.0 released Posted Oct 26, 2012 16:32 UTC (Fri) by daniels (subscriber, #16193) [Link]
> Not really, you loose information about how your window will look when resized
Which you also lose whilst scaling.
Wayland and Weston 1.0 released Posted Oct 26, 2012 18:02 UTC (Fri) by renox (subscriber, #23785) [Link]
>> Not really, you loose information about how your window will look when resized
>Which you also lose whilst scaling.
Which are very temporary, short situations.
Wayland and Weston 1.0 released Posted Oct 26, 2012 18:37 UTC (Fri) by daniels (subscriber, #16193) [Link]
> Which are very temporary, short situations.
Equally as temporary and short as for client-side decorations. Although I still maintain CSDs are likely to be even more responsive for the reasons I listed above.
Wayland and Weston 1.0 released Posted Oct 28, 2012 16:04 UTC (Sun) by nix (subscriber, #2304) [Link]
You've never had an application lock up and require an xkill?
Wayland and Weston 1.0 released Posted Oct 26, 2012 3:06 UTC (Fri) by drag (subscriber, #31333) [Link]
> Window decorations under client control.
After the whole 'network transparency' red herring thing this was the next things that I saw people complaining about Wayland's approach.
> I can just see things like this http://hallofshame.gp.co.at/phone.htm spreading.
I don't. It's shit software. Users solve the problem of shit software by not using it. Developers may design and program something like that, but if they do then it won't hurt anything or anybody because nobody will use it.
If it _does_ actually become popular and widely used then users will find that sort of thing very useful and attractive despite the fact it may offend your design sensibilities... although I doubt that will happen to the extreme; because it's almost objectively terrible.
> And un-killable windows occupying the foreground and, and and...
I don't see how not having windows decorations dictated by Wayland is the same as not having control over windows. This problem can be solved by having a equivelent of 'xkill' and/or the use of a particular keyboard sequence that cannot be overridden or intercepted by a application. Also a alt-click-drag feature would be useful in Wayland, just like it is in X.
Wayland and Weston 1.0 released Posted Oct 26, 2012 8:35 UTC (Fri) by dgm (subscriber, #49227) [Link]
All that has been discussed to death in wayland-devel. A few examples:
http://lists.freedesktop.org/archives/wayland-devel/2011-...
You may find this interesting.
Wayland and Weston 1.0 released Posted Oct 29, 2012 10:55 UTC (Mon) by njwhite (subscriber, #51848) [Link]
The issue I have with client-side decorations is that presumably there's no (easy, universal) way to turn them off. My window manager is keyboard based, and I enjoy not having to waste my screen real-estate with large titlebars and buttons that I don't need. Not having a way to turn them off easily would be a pain. But maybe that's something the toolkits will just add as an option in .gtkrc or equivalent, in which case I cease to care.
|
|||||||||||||