Recent Features
| |||||||||||||
LFCS 2012: X and WaylandLFCS 2012: X and WaylandPosted Apr 11, 2012 19:26 UTC (Wed) by dlang (✭ supporter ✭, #313)Parent article: LFCS 2012: X and Wayland
I am dreading the applications taking control of their window decorations.
you will end up with different windows on the desktop with vastly different decorations, and with the Mac/Unity fad, some will have the min/max/close buttons on the left, and some on the right, all with different symbols....
This is the sort of change that the Desktop Environment folks who think that everyone runs only their Desktop Apps are going to love, but will make life worse for real users who don't limit their apps to one particular DE's "blessed" set of apps.
(Log in to post comments)
LFCS 2012: X and Wayland Posted Apr 11, 2012 19:49 UTC (Wed) by quintesse (subscriber, #14569) [Link]
I don't think there's much to be afraid off. Either you have well-behaved apps that fit in their environment seamlessly or you got apps that do whatever they feel like. I don't think it's so much worse to have the window decorations being "off" when the whole application looks wrong in your DE anyway.
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:01 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
>I don't think it's so much worse to have the window decorations being "off" when the whole application looks wrong in your DE anyway.
I do. When an application merely "looks wrong", that's fine, although if the decorations were all in the wrong place and inconsistent with everything else, that'd be very irritating, and from the user's perspective, an awful regression.
But when applications provide no "quit" functionality or shortcut (I've seen many that are like this, assuming the WM will take care of them), or they lock up, then my window manager will save me. I've got a tiling manager where I can right-click on the title bar, click "Kill", and it will send SIGKILL to the application. (There is also a keybinding for SIGTERM, but I can never remember what it is.)
The bigger issue, IMHO, is still the lack of tiling window managers. I have no interest in manually resizing and moving windows, especially when it's up to the application to provide me a sane way to do it.
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:06 UTC (Wed) by quintesse (subscriber, #14569) [Link]
I'm pretty sure I read that Wayland could provide for a way to kill misbehaving apps, that here was nothing preventing them from doing that.
LFCS 2012: X and Wayland Posted Apr 12, 2012 19:37 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
Yes, in a talk about Wayland at FOSDEM this year this was mentioned, but it seemed to be still work in progress.
Alex
LFCS 2012: X and Wayland Posted Apr 13, 2012 0:21 UTC (Fri) by robert_s (subscriber, #42402) [Link]
So is this working on the premise that you can get someone to do anything as long as you have a gun pointed at their head?
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:08 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
not matching the look is cosmetic, some people care passionatly about this, but others will accept that this is a different app and so it looks different.
functional changes like where the maximize/minimize/close buttons are and what they look like are much more significant.
I'm also worried about these being under the control (and therefor subject to problems with) the applications. How long will it be before there are apps where the 'close' button on the window actually does something else?
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:23 UTC (Wed) by quintesse (subscriber, #14569) [Link]
How long before an app will actually delete your file when you say "Open..."? Sure that could happen, but why would anyone do that? And especially in a open source world where anyone could just fix/improve it?
On the other hand you say that the position of the window decorations is important, while I'm much more affected by GTK apps not *behaving* like they should within KDE for example. Still, it's something we all learned to live with. I think it's the same with Wayland, things will either get fixed or we will learn to accept them.
LFCS 2012: X and Wayland Posted Apr 13, 2012 0:19 UTC (Fri) by robert_s (subscriber, #42402) [Link]
"How long before an app will actually delete your file when you say "Open..."? Sure that could happen, but why would anyone do that? And especially in a open source world where anyone could just fix/improve it?"
That's a ridiculous example - nobody would ever do that because it is functionally illogical. However, the details of window management are very subjective, to do with taste, opinion and preference. Different people have different ideas (and strong opinions) over how things "should" be.
We are talking about the same software community that ended up with a whole GNOME fork based around the order of the OK/Cancel buttons, remember?
"Window managers" answer the question correctly here by saying "the correct behaviour is what the specific _user_ wants".
LFCS 2012: X and Wayland Posted Apr 13, 2012 1:06 UTC (Fri) by quintesse (subscriber, #14569) [Link]
And making the close button "do something else" isn't a ridiculous example? Then we have different ideas of ridicule my friend.
LFCS 2012: X and Wayland Posted Apr 13, 2012 20:13 UTC (Fri) by k8to (subscriber, #15413) [Link]
You're being ridiculous.
The statement was clearly that windows would get the positioning confused. Perhaps you're laboring under the misconception that everyone puts the close box in the same place? (This is false, by the way).
From where I sit, nearly every prefab environments gets the window decorations quite wrong, by putting destructive, unrecoverable decoration buttons directly adjacent to nondestructive, recoverable buttons.
For example, nearly everyone puts close adjacent to things like minimize, so an attempted minimize can lose your work.
I'm certainly not going to accept an environment that allows the app developer to inflict this kind of stupidity on me.
LFCS 2012: X and Wayland Posted Apr 14, 2012 2:55 UTC (Sat) by quintesse (subscriber, #14569) [Link]
Clearly obvious? I beg to differ. The sentence "How long will it be before there are apps where the 'close' button on the window actually does something else?" seems very explicit, a close button that does something else than close the window. (which would of course be very confusing, and which in my opinion would therefore never happen, no need to start worrying about that kind of thing)
LFCS 2012: X and Wayland Posted Apr 14, 2012 13:01 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]
let us not forget that there is a number of themes without any icon on the buttons. What if they differ in order? I have not seen any argument pro csd and many cons... I usually tend to think it is a bad idea in such cases ;-)
LFCS 2012: X and Wayland Posted Apr 14, 2012 13:22 UTC (Sat) by quintesse (subscriber, #14569) [Link]
You haven't seen any argument pro? You just have to read the technical arguments for Wayland, so either you don't like Wayland at all which would mean for you in fact there are no pros, or that should count as a pro in itself because that just how Wayland works. And on the other hand are these "many cons" which I think are highly exaggerated or even fictitious.
People come up with red herrings of things that will surely happen if we allow CSD while ignoring the facts that show that on other OSes they seem to be doing fine, no complete chaos of every app for himself and just drawing the decorations however they feel like (and examples that if an app really wants they can break the rules even on X, ie Chrome).
Apps built on top of the software made by their respective DEs won't even know anything changed, the core software in Gnome and KDE will take over the rendering of the decorations. So in one fell swoop a large quantity of apps will behave exactly as before.
Most other apps will not go through the trouble of rendering their own decoration either and will use some kind of system service/library for that (probably the same Gnome and KDE will be using).
So that only leaves us with those apps that decide to do their own rendering for some reason and that's when we have to remember that Linux/BSD are highly managed environments where apps that misbehave will probably get fixed or ignored.
And that's why I think CSD is not the end of the world.
LFCS 2012: X and Wayland Posted Apr 14, 2012 15:49 UTC (Sat) by apoelstra (subscriber, #75205) [Link]
How will apps using GNOME's decoration drawing know about my KDE settings, or vice-versa? If I want the close button moved away from other buttons, will I only be able to affect half my applications? Will I need multiple configuration tools?
How will any of these know if I don't want -any- decorations, just a 10px title bar with a title on it?
These "other OSes" you claim are working fine, are so inflexible, and have such insane defaults (which for the most part cannot be changed) that they are nearly unusable to me. This is hardly what I call "working fine". Not to mention the insanity individual apps can, and do, foist on the system..
LFCS 2012: X and Wayland Posted Apr 14, 2012 16:11 UTC (Sat) by quintesse (subscriber, #14569) [Link]
How? The way Gnome and KDE do right now, by having special themes (or theme engines) that know about the other DE's theme settings. But this is problem that exists right now as well, if you don't have those compatibility packages installed a Gnome app will look completely out of place on a KDE desktop and vice versa.
Yes those other OSes or less flexible, what does that have to do with anything? We were talking about being able to provide a consistent desktop experience, even when using CSD. And talk about insanity, you *really* want to use the Linux desktop as an example of saneness???
LFCS 2012: X and Wayland Posted Apr 16, 2012 18:43 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
> Yes those other OSes or less flexible, what does that have to do with anything? We were talking about being able to provide a consistent desktop experience, even when using CSD. And talk about insanity, you *really* want to use the Linux desktop as an example of saneness???
Putting window controls outside of the application is one of the things that the Linux desktop does which is undeniably better than the alternatives. Why do you want to throw away an advantage? You seem to be assuming that the way things work is "just" an accidental side effect of the implementation and not, as it is, a feature.
The correct thing to do is to find a way to retain the experience we have now--which is well liked--and add technically superior underpinnings. So far I have heard that Wayland will throw away valuable and desirable features with the only justification given as "We want to improve the implementation and it's too hard to make it keep working the right way afterwards, so we decided to assume that no one cares."
If the new system really is superior then re-implement the old system on top; if you can't, it isn't.
LFCS 2012: X and Wayland Posted Apr 16, 2012 21:48 UTC (Mon) by quintesse (subscriber, #14569) [Link]
So what's so superior about it?
We already know that X is better at handling unresponsive apps, but that's not something that's impossible to do with CSD.
So what else is so superior that people will not even wait until Wayland has actually something usable to show to before running it into the ground? (which is by the way the ONLY thing I've been trying to clear up all this time. Of course if Wayland can maintain current X functionality I'll be happy, but I'm just not convinced I'll be unhappy if they can't)
LFCS 2012: X and Wayland Posted Apr 17, 2012 11:55 UTC (Tue) by sorpigal (subscriber, #36106) [Link]
> So what else is so superior that people will not even wait until Wayland has actually something usable to show to before running it into the ground?
There's this tendency to say "You should have raised this objection a year ago" when the software is already released and the problems become clear.
LFCS 2012: X and Wayland Posted Apr 17, 2012 12:04 UTC (Tue) by quintesse (subscriber, #14569) [Link]
Well constructive criticism is great of course, helping out and coming up with solutions would be better, but what I see mostly in these threads is people just assuming the very worst and do nothing but complain. That can be very demotivating and is normally the number one reason for the developers to ignore people. (I can't imagine what it must be like to be Lennart Poettering for example ;) )
LFCS 2012: X and Wayland Posted Apr 17, 2012 19:09 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Hear, hear! I find it very tiresome for so many people to complain so bitterly about the few projects that really seem to be improving and revitalizing the Linux ecosystem. Pottering and Packard seem to be some of the few people who are willing to take on the challenge of improving what has come before instead of casting it in bronze as a museum piece. In this specific case it is particularly ironic because the Wayland developers also seem to be the X developers and if anything Wayland is X12.
Wayland is heavily informed by what does and doesn't work in X by the people who know it most intimately. As you say some people are just assuming the very worst and doing nothing but complain but the developers they are complaining are wrong and the developers they are holding up as right are _the_same_people_!
LFCS 2012: X and Wayland Posted Apr 18, 2012 8:12 UTC (Wed) by renox (subscriber, #23785) [Link]
> the developers they are complaining are wrong and the developers they are holding up as right are _the_same_people_
Except of course that the same people at different times may do totally different things due to changing priorities, which means you have _no_point_.
LFCS 2012: X and Wayland Posted Apr 19, 2012 18:46 UTC (Thu) by tuna (guest, #44480) [Link]
Linux does not do anything regarding window decorations. X and the window manager does things regarding window decorations.
LFCS 2012: X and Wayland Posted Apr 14, 2012 16:45 UTC (Sat) by mpr22 (subscriber, #60784) [Link] Individual apps already can "foist insanity" on X desktops. My current choice of audio playback application (they're all crap one way or another, this one happens to annoy me less than most) comes up with its own close/minimize buttons and no WM-applied decorations.
LFCS 2012: X and Wayland Posted Apr 15, 2012 16:46 UTC (Sun) by Tet (subscriber, #5433) [Link] People come up with red herrings of things that will surely happen if we allow CSD while ignoring the facts that show that on other OSes they seem to be doing fineI'm somewhat staggered by this comment. I don't know which world you live in, but it doesn't seem to be the same one as me. I can't speak about OS X, but client side window decoration causes massive problems on Windows in the real world. Further, the very concept seems fundamentally flawed because it assumes that all applications will be written using an appropriate toolkit, which just plain isn't true. It isn't true now, it hasn't been true for the last 30 years, and it won't be true in the future. Unlike many X fans, I'm not opposed to Wayland. But I'm very strongly opposed to the way it's going about some things. Notably removing my control over my environment.
LFCS 2012: X and Wayland Posted Apr 15, 2012 17:11 UTC (Sun) by quintesse (subscriber, #14569) [Link]
I'll stagger you some more. Windows and OS X are doing fine. You might not like it but millions of people all over the world use their desktops, and the world does not go up in flames.
But of course, according to you that can't really be true because they have "massive problems". Really now?
LFCS 2012: X and Wayland Posted Apr 15, 2012 20:42 UTC (Sun) by Tet (subscriber, #5433) [Link]
Yes, really. To quote Esther Schindler, "Microsoft's biggest and most dangerous contribution to the software industry may be the degree to which it has lowered user expectations." You claim that people are using Windows (and OS X, which as I've said I haven't used, so can't comment on) without problems. But realistically, if you look around an average office, you see people having problems all the time, and just accepting it as normal behaviour. And a perfect example of that is applications that hang and you can't even iconify them because the application is responsible for window management. You can claim that's not a problem until the cows come home. But it happens, and it happens sufficiently frequently that I'm happy calling it a problem.
LFCS 2012: X and Wayland Posted Apr 15, 2012 21:18 UTC (Sun) by quintesse (subscriber, #14569) [Link]
So these are the "massive problems"? Not being able to iconify an application that hangs? Yes, and you can't move the window around either. Sucks I know, but hardly earth-shattering.
Oh and wait, in Windows 7 I actually *can* do it, seems that MS after many many years finally fixed that one.
But the people working on Wayland have said they've already thought about possible solutions to these problems. So why not wait and see what happens?
And if we have to talk about the lowering of expectations, I've been a Linux user for many years and if it has taught me anything it is not to have too many expectations and lots of patience.
LFCS 2012: X and Wayland Posted Apr 16, 2012 23:15 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]
They fixed minimise and close in Windows 2000; I'm not sure whether moving is a more recent issue.
Windows had the compatibility problem that the window manager used to be just a library that would run in the client processes. While most clients would just pass mouse clicks on the decorations into the default message handler, some of them relied on being notified in advance of any change to their window and being able to override it. Changing that ran the risk of breaking applications.
X applications don't assume they can have this control, and Wayland application won't be able to do so either. Being responsible for rendering decorations doesn't mean becoming the window manager, though certainly lack of visible feedback to window decorations is a pain.
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:26 UTC (Wed) by NAR (subscriber, #1313) [Link] How long will it be before there are apps where the 'close' button on the window actually does something else?If I remember correctly, I can setup a handler in Java for the "window close button clicked" event, i.e. the application can do whatever it wants to do for over 15 years.
LFCS 2012: X and Wayland Posted Apr 12, 2012 5:41 UTC (Thu) by Tuna-Fish (subscriber, #61751) [Link]
> How long will it be before there are apps where the 'close' button on the window actually does something else?
About -25 years or so. Doing this is entirely possible at present, and part of normal functionality for a lot of applications. For example, when I "close" xchat, it actually minimizes into tray, because that's typically what I want it to do.
LFCS 2012: X and Wayland Posted Apr 21, 2012 18:07 UTC (Sat) by JanC_ (guest, #34940) [Link]
The close button is there to close the window, not to close the application (although that could be logical result for many apps, of course).
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:04 UTC (Wed) by marduk (subscriber, #3831) [Link]
In a way I agree with you, but at the same time... we already have this problem now. My web browser — and I'm not going to name names here— wants to provide its own decorations. And put close/minimize buttons not where all my other window manager buttons are.
OTOH I don't use *that* many apps not built around my desktop environment/X11 toolkit. The ones I do use already look/feel different, so adding window decoration into the mix isn't going to peeve me much more than it already does.
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:10 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
however Chrome does have the option of leaving the window decorations to the window manager (the first config option I changed)
LFCS 2012: X and Wayland Posted Apr 11, 2012 20:05 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] My guess is that by the time this is deployed, you'd have KDE and Gnome applications that speak Wayland, and use common theming to get consistent decorations, together with legacy apps that speak X, run on the Wayland/X server, and have their decorations drawn by the Wayland/X window manager, again according to the common theme.Perhaps a Wayland expert can elaborate or tell us how it really should be done.
LFCS 2012: X and Wayland Posted Apr 12, 2012 0:19 UTC (Thu) by dgm (subscriber, #49227) [Link]
If I'm not mistaken the plan is to provide a shared library with code to draw the window decorations for applications (and toolkits) that want to use the "system theme". Fast, simple and consistent look if that is what you need. Probably the version of Xlib that talks to Wayland is going to pull a few tricks to run this decorator code in the application instead of the window manager.
LFCS 2012: X and Wayland Posted Apr 12, 2012 14:03 UTC (Thu) by glandium (subscriber, #46059) [Link]
What if you don't want title bars at all?
LFCS 2012: X and Wayland Posted Apr 12, 2012 14:29 UTC (Thu) by dgm (subscriber, #49227) [Link]
Don't use the library. It's only a convenience.
LFCS 2012: X and Wayland Posted Apr 12, 2012 21:41 UTC (Thu) by glandium (subscriber, #46059) [Link]
I meant as a user, not as an application developer. I don't have titlebars in my tiling window manager.
LFCS 2012: X and Wayland Posted Apr 13, 2012 9:29 UTC (Fri) by dgm (subscriber, #49227) [Link]
Each Wayland's compositor should provide it's own library. In a tiling Window manager most functions would be stubs, because windows do not really need decorations.
LFCS 2012: X and Wayland Posted Apr 15, 2012 18:06 UTC (Sun) by glandium (subscriber, #46059) [Link]
It doesn't really look like it's designed this way... How would these libraries be linked anyways? Toolkits would link with a generic implementation, and different implementations would be LD_PRELOADed at runtime? (or something similar)
LFCS 2012: X and Wayland Posted Apr 16, 2012 11:28 UTC (Mon) by nix (subscriber, #2304) [Link]
It's more likely that the Wayland library would read a configuration file (or other configuration state) which would then give it the name of a plugin .so to load to implement the pluggable stuff.
But, noooo, it's better to force people to reimplement or fork the whole thing! Bah.
LFCS 2012: X and Wayland Posted Apr 13, 2012 0:24 UTC (Fri) by robert_s (subscriber, #42402) [Link]
"If I'm not mistaken the plan is to provide a shared library with code to draw the window decorations for applications (and toolkits) that want to use the "system theme"."
But is there no way of _forcing_ an application to use a users preferred decoration/manager?
LFCS 2012: X and Wayland Posted Apr 13, 2012 5:21 UTC (Fri) by renox (subscriber, #23785) [Link]
> But is there no way of _forcing_ an application to use a users preferred decoration/manager?
Look, most applications will use a toolkit, the toolkit will use a common way to draw the decorations (otherwise there will be a coherency issue), ideally a shared library.
But no, there is no way to force an application (short of modifying it) to use all this, and *this is not an issue* because there are *now* lots of way for an application to misbehave but in practice this doesn't happen.
LFCS 2012: X and Wayland Posted Apr 13, 2012 11:24 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>Look, most applications will use a toolkit
It's not about those that do, but about those which don't. Even if Qt and GTK start drawing the deco, there is still SDL and glut, for example.
LFCS 2012: X and Wayland Posted Apr 13, 2012 11:39 UTC (Fri) by renox (subscriber, #23785) [Link]
So? As I said above I don't expect that this will be a big issue because the 'social forces' which makes current applications look&behave 'identically' will still be here with Wayland.
LFCS 2012: X and Wayland Posted Apr 13, 2012 5:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Strictly speaking, no.
However, you can set the default decorations to empty rectangles and have your compositor to draw whatever decorations it wants to do. Some applications might ignore the setting and do whatever they want, but that's how they behave right now anyway.
Additionally, you can do tricks like overlaying a gray rectangle over an unresponsive application and drawing large "KILL" button on it to immediately kill the hung application.
LFCS 2012: X and Wayland Posted Apr 13, 2012 9:47 UTC (Fri) by dgm (subscriber, #49227) [Link]
No, no way of forcing, the same way you cannot force the application to speak your language, or have icons that integrate with your preferred theme.
But you can always try embarrassing the developer in public for not doing things the right way :-)
LFCS 2012: X and Wayland Posted Apr 12, 2012 14:58 UTC (Thu) by randomguy3 (subscriber, #71063) [Link]
Given that the maintainer of KWin has explicitly come out against client-side decorations (and KWin will be the Wayland compositor for KDE), I'm interested to see how this will work out.
There is the potential for clients with no decorations at all on Weston, or clients with two lots of decorations on KWin.
LFCS 2012: X and Wayland Posted Apr 13, 2012 6:30 UTC (Fri) by alison (✭ supporter ✭, #63752) [Link]
We already suffer the constant annoyance of programs that variously are closed with Ctrl-Q, Ctrl-Shift-Q and Alt-F-x. Why not move all the chrome around as well? We'll just reboot when we want to close windows.
-- Alison, who's looking forward to test-driving Wayland
LFCS 2012: X and Wayland Posted Apr 13, 2012 11:10 UTC (Fri) by mgraesslin (subscriber, #78959) [Link]
There will never be Client Side Window Decorations in KDE Plasma. In fact the current state of Wayland support in KWin requires server side Window Decoration for Wayland Clients.
We will most likely go for an approach were all Wayland Clients will be forced into server side decorations no matter whether they use Client Side Decorations or not. We have to do that as the differentiation between our Workspaces (Desktop, Netbook, Tablet) is from Window Manager perspective mostly in the decorations (Desktop always decoration, Netbook decorated except maximized windows, Tablet undecorated). I don't expect that application developers will care about such differentiation and we need to have the possibility to experiment in that area. We would limit ourselves if we would allow Client Side Decorations.
I have even considered to enforce server side decorations on X11 but that's difficult due to backwards compatibility.
LFCS 2012: X and Wayland Posted Apr 13, 2012 12:07 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> I don't expect that application developers will care about such differentiation and we need to have the possibility to experiment in that area.
Well, if applications were to draw the decorations themselves, they're going to use a library to do it anyway. This kind of issues should be handled transparently to application developers in that library.
LFCS 2012: X and Wayland Posted Apr 13, 2012 13:03 UTC (Fri) by mgraesslin (subscriber, #78959) [Link]
and how should such a library function? We need one to do rendering with GTK, one for rendering with Qt, one for rendering OpenOffice/LibreOffice. The same then for each of the different shells oh and people might want to change the window decorations. Yes some flexibility known from KDE Plasma which our users don't want to go away.
Sorry a library just does not fit it. Especially not if we want to be able to experiment from one release to the other.
We just should not try to fix what is not broken and keep server side decorations. Please read http://blog.martin-graesslin.com/blog/2010/05/open-letter... why client side decorations are a very bad idea. And no, most of the issues mentioned in that blog post will not go away with Wayland. Some issues might be fixable by adding some glue there and some hacks there, but then we are again fixing what is not broken :-)
LFCS 2012: X and Wayland Posted Apr 15, 2012 19:00 UTC (Sun) by The_Barbarian (subscriber, #48152) [Link]
Thank you!
How about running untrusted applications? Posted Apr 24, 2012 11:44 UTC (Tue) by gmatht (guest, #58961) [Link] There has been research into secure GUIs which minimize an applications ability to interfere with other applications running on the same screen, with some attempts to retrofit this to UNIX. For example the Plash Powerbox uses preload tricks to transparently replace the GTK file open dialog box with a powerbox that hands back the right to open the file the user has chosen (but none of the users other files which are otherwise inaccessible due to chroot trickery). Unfortunately X isn't especially well prepared to deal with hostile clients. Potentially a simpler and more modern system could be more secure. It seems to me that if the clients are responsible for drawing their own decorations that would instead make a secure GUI harder. The secure GUIs rely on, for example, windows titles being correct even in the case of a hostile client. This would seem hard to ensure if the API encouraged applications to draw their own decorations.
How about running untrusted applications? Posted Apr 24, 2012 13:51 UTC (Tue) by dgm (subscriber, #49227) [Link]
> The secure GUIs rely on, for example, windows titles being correct even in the case of a hostile client.
A very poor assumption, if you ask me.
How about running untrusted applications? Posted Apr 24, 2012 14:15 UTC (Tue) by renox (subscriber, #23785) [Link]
>> The secure GUIs rely on, for example, windows titles being correct even in the case of a hostile client.
> A very poor assumption, if you ask me.
Uh? If the window manager is in the server, that's not such a bad assumption!
How about running untrusted applications? Posted Apr 24, 2012 16:11 UTC (Tue) by dgm (subscriber, #49227) [Link]
Correct me if I'm wrong but:
1. Aren't X11 applications able to specify their window title? 2. Aren't X11 applications able to override the WM redirection if they ask to? And finally... 3. Aren't server side decorations something exclusive of X? meaning that applications relying on this would not be portable to Windows or OSX?
How about running untrusted applications? Posted Apr 24, 2012 16:32 UTC (Tue) by renox (subscriber, #23785) [Link]
> Correct me if I'm wrong but:
> 1. Aren't X11 applications able to specify their window title?
Of course they are, but this doesn't mean that a window manager cannot get its own way to check whether the application is trusted or not (not so simple in practive but doable I think) and display a trust indicator next to the window tittle.
Not sure what you mean about your point 2, but clearly untrusted applications must be restricted in what they're allowed to do (no real fullscreen, no input redirection, etc).
> 3. Aren't server side decorations something exclusive of X? meaning that applications relying on this would not be portable to Windows or OSX?
Portable applications exist already today with X and Windows/OS X, so I'm not sure what is your point.
|
|||||||||||||