Posted Apr 11, 2012 19:40 UTC (Wed) by glandium (subscriber, #46059)
Parent article: LFCS 2012: X and Wayland
If applications handle their own decoration and Wayland does its own window management, how do we get the variety of window management systems we have now (tiling vs. "standard", virtual desktops, etc.)
Posted Apr 11, 2012 20:01 UTC (Wed) by JoeBuck (subscriber, #2330)
[Link]
Presumably this would be handled by writing an alternate Wayland compositor/window manager to do, say, a tiling desktop, or modifying the existing one to produce the desired behavior.
Window manager variety
Posted Apr 11, 2012 20:12 UTC (Wed) by rfunk (subscriber, #4054)
[Link]
It kind of sounds like the entire class of window manager programs will disappear. Just like in Mac and Windows, where there's no such concept.
Window manager variety
Posted Apr 11, 2012 20:21 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
Only if Wayland manages to satisfy everyone, which is basically impossible (just from a performance point of view, getting the performance of the stripped down window managers with the functionality, even optional, of the fancy DE managers is going to be extremely hard, if not impossible)
Window manager variety
Posted Apr 18, 2012 14:02 UTC (Wed) by gmaxwell (subscriber, #30048)
[Link]
"Only if Wayland manages to satisfy everyone, which is basically impossible"
No— the distros will just package this stuff, and eventually all distro users will simply be forced to use it, since the packaged software will stop working with classic X11 and the whole reason you were running a distro in the first place was to outsource the distro maintaining to someone else.
Window manager variety
Posted Apr 11, 2012 21:35 UTC (Wed) by raven667 (subscriber, #5198)
[Link]
I don't think it'd be right to say that Mac and Windows don't have the concept of a window manager/compositor, they certainly do have those components, I believe its dwm.exe on Windows and seems to be WindowServer on my Mac. The difference with Weston is that Weston is a much more easily replaceable component whereas the window managers/compositors in Mac/Win come with and are not designed to be replaced by the end user. It'd be interesting to see if anyone has tried.
Window manager variety
Posted Apr 11, 2012 21:40 UTC (Wed) by alankila (subscriber, #47141)
[Link]
If there is one thing I would like to happen, then that would be that nobody would replace Weston with anything else. We don't need 20 window managers, just 1 good enough one. I desperately wish this point was more widely appreciated.
Window manager variety
Posted Apr 11, 2012 22:00 UTC (Wed) by apoelstra (subscriber, #75205)
[Link]
>We don't need 20 window managers, just 1 good enough one.
Would you like a window manager with 10-pixel-high title bars, which automatically positions windows in a tiled layout, which can be rearranged using the vi keys?
Perhaps you would. I wouldn't have it any other way.
But given the relative popularity of metacity and kwin, I suspect that most people would disagree -- and that is why we have 20 different window managers. Because nobody agrees on what "good" even means, let alone "good enough".
Window manager variety
Posted Apr 11, 2012 22:12 UTC (Wed) by fluxion (subscriber, #62978)
[Link]
indeed. so long as everyone agrees that xmonad is the one window manager to rule them all and should serve as the reference, i fully agree with picking just 1. of course, that's an absurd thing to expect.
Window manager variety
Posted Apr 12, 2012 5:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
It's quite possible that there'll be one basic WM with a lot of configurable hooks for all sorts of customizations. Say, for automatic windows positioning.
Window manager variety
Posted Apr 12, 2012 12:06 UTC (Thu) by sorpigal (subscriber, #36106)
[Link]
If it were possible for there to be a WM like this that was sufficiently configurable such that users of ratpoison, E17 and kwin (just as a sample) could all be switched to it without noticing the difference, don't you think it would have been developed by now? Nothing today or for a long time has prevented this, but it never happened. Why? What do you think has changed that will make this happen now?
Window manager variety
Posted Apr 12, 2012 16:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
Why?
It's simply that nobody cares much. I've seen a tiled window manager for Windows, btw.
Window manager variety
Posted Apr 12, 2012 14:31 UTC (Thu) by alankila (subscriber, #47141)
[Link]
I work mostly in fullscreen apps, with no operating system chrome visible at all. So... I can live with a tiling window manager that can display exactly 1 window.
Window manager variety
Posted Apr 27, 2012 5:58 UTC (Fri) by Duncan (guest, #6647)
[Link]
Of course that, or something very close to it, is already possible with kwin. Reasonably current kwin is tiling capable, titlebar height (and lots more) is configurable, and as with any self-respecting kde app, all major triggerable functionality is mapped to configurable hotkeys.
FWIW, my kde is highly customized as a sort-of hybrid tiling/floating mixture, with floating dominating, but various windows configured to specific sizes and/or locations, including two dominant themes of maxed-Y/half-maxed-X for side-by-side for things like browsers and terminal windows, and maxed-X/almost-maxed-Y, lacking only titlebar height (and sometimes no-border so I get full app height as if it had the titlebar anyway), for things like tri-pane mail, news and feed-reader clients. Combined with (sloppy) focus follows mouse, click-to-raise and with semi-transparent inactive, that lets me work with either the two side-by-side windows or with the almost-maxed and a half-maxed window concurrently, or with all three windows, the back half-maxed one viewable when focused (but not raised) thru the semi-transparent inactive almost-maxed window above it.
It sounds horrible I know, but there's a productive workflow there that I've grown to depend on, and I was VERY unhappy when an earlier version of it broke with my transfer from kde3 to supposedly ready but still in reality VERY early alpha quality kde4. Fortunately I was able to work around or find alternate solutions for the broken bits, and kde4 itself has improved dramatically since then, such that at least with semantic-desktop not only turned off but actually compiled out (gentoo, USE=-semantic-desktop), I can honestly say I'm enjoying kde4 as much if not more than I did late kde3, now.
Window manager variety
Posted Apr 12, 2012 0:16 UTC (Thu) by nybble41 (subscriber, #55106)
[Link]
If you seriously want to be stuck with the single most popular solution, you're welcome to use Windows. Anyone using Linux on their desktop or laptop is already part of a tiny minority. IMHO, it's a bit hypocritical for a Linux user to argue against the possibility of multiple, competing alternatives.
Anyway, there is no such thing as a single "good enough" window manager, or any other program for that matter. Different people have different requirements, which in turn demand different solutions.
Window manager variety
Posted Apr 12, 2012 6:46 UTC (Thu) by niner (subscriber, #26151)
[Link]
Having only one window manager implementation does not mean that it may only have one behavior. For example kwin does already support traditional floating windows and tiling. With a somewhat sane architecture the code may still be readable and maintainable even with several more different ways to manage windows. And I don't see why it would be more difficult to experiment with new ways.
Things we would lose are having extremely lightweight window managers and the choice about the programming language it's implemented in. Personally I don't think that the first one is really a loss. Window management is no performance critical task and I guess that even a completely new behavior would be just a couple of 100 lines of code. A device which is able to handle a graphical UI would already have enough memory that this doesn't matter at all.
Window manager variety
Posted Apr 12, 2012 7:33 UTC (Thu) by daniels (subscriber, #16193)
[Link]
IMHO, it's a bit hypocritical for a Linux user to argue against the possibility of multiple, competing alternatives.
Posted Apr 12, 2012 15:31 UTC (Thu) by nybble41 (subscriber, #55106)
[Link]
I'm afraid I have to disagree. One of the replies to your cited e-mail made a more accurate statement, that Linux *distributions* are about limiting the user. That I can agree with; one of the factors in choosing a particular distribution are the choices which have already been made for you. Few individuals want to design their own distribution from the ground up; even Linux From Scratch has a standard template for the base system.
However, were it not for the freedom to make unpopular choices, including the choice to develop an alternative to an existing "good enough" solution, we wouldn't have Linux in the first place. Anyone who works on Linux is already exercising that freedom, which makes it hypocritical to talk about denying the same freedom to others.
Window manager variety
Posted Apr 12, 2012 15:40 UTC (Thu) by daniels (subscriber, #16193)
[Link]
However, were it not for the freedom to make unpopular choices, including the choice to develop an alternative to an existing "good enough" solution, we wouldn't have Linux in the first place. Anyone who works on Linux is already exercising that freedom, which makes it hypocritical to talk about denying the same freedom to others.
Yes, it would be if anyone had said that, but you're arguing against a strawman. Anyone who wants to work on an alternative desktop environment is more than free to do so; no-one is denying them that right. However, it doesn't mean that everyone around them has to care about it, and/or pander to their needs, requests, and demands of other projects.
Window manager variety
Posted Apr 12, 2012 16:28 UTC (Thu) by nybble41 (subscriber, #55106)
[Link]
>...> If there is one thing I would like to happen, then that would be that nobody would replace Weston with anything else. We don't need 20 window managers, just 1 good enough one. I desperately wish this point was more widely appreciated.
> Yes, it would be if anyone had said that, but you're arguing against a strawman. Anyone who wants to work on an alternative desktop environment is more than free to do so; no-one is denying them that right.
Sure, it's not literally _denying_ the freedom to work on alternatives--that was a bit of justifiable hyperbole on my part--but the original comment was clearly disparaging the idea of developers working on anything but the "1 good enough" solution, which, if consistently applied, would include anyone working on Linux.
> However, it doesn't mean that everyone around them has to care about it, and/or pander to their needs, requests, and demands of other projects.
I agree completely. However, while we're on the subject of strawman arguments... who said anything about providing support? The original comment was simply about developing alternatives to Weston. No mention was made of any expectation of interest or "pandering" by others.
Window manager variety
Posted Apr 12, 2012 8:06 UTC (Thu) by Seegras (subscriber, #20463)
[Link]
> Different people have different requirements, which in turn demand
> different solutions.
And not only that, different people have different hardware. On the desktop I use WindowMaker with sloppy focus and autoraise, because a) I've got the screen real-estate and b) a mouse. On my netbook, I'm running xfce with click-to-focus, because the screen is very small and usually there's no mouse attached. And on my phone, there's an entirely different window manager running -- I'd be very unhappy with xfce or WindowMaker there ;))
Window manager variety
Posted Apr 12, 2012 14:56 UTC (Thu) by alankila (subscriber, #47141)
[Link]
Not all choice is bad, but not all choice is good either. The choice between using windows or linux is to a degree a different kind of choice than the choice of, say, between xfce4 and gnome. (Hint: in the latter choice, you can still run the same application binaries.) Since applications are the thing that truly matter, window manager choice looks trivial to me. And window management? *sigh* Really, are we talking about things like closing, moving, resizing, minimizing and maximizing? This stuff was boring in 1995.
It's also a valid point that a different hardware setup requires a different paradigm. Whether Weston can adapt to, say, mouseless and keyboardless window management is a separate question in itself, but at least different interface devices undeniably pose different requirements.
Window manager variety
Posted Apr 18, 2012 19:13 UTC (Wed) by kleptog (subscriber, #1183)
[Link]
I thought window managers were a done deal as well, until someone introduced me to tiling windows managers. They are definitely different to what came before and IMHO a definite improvement. Namely, your windows are always the perfect size and never need to be moved or resized by hand.
I'll admit that progress is not very fast, but there is progress.
Window manager variety
Posted Apr 18, 2012 22:33 UTC (Wed) by khim (subscriber, #9252)
[Link]
Your definition of progress is kinda strange: tiling window managers were tried and explicitly rejected! And it happened decades ago! They were tried and rejected before X Window System was born!
Tiling window managers were invented before anything else: remember that both Xerox Star (in 1981, no less) and Windows 1.0 (in 1985) employed tiling window managers! They were neat, but people rejected them.
Today they are in position similar to other old rejected technologies (such as Acme or FFM): some old-timers still use them and even few newcomers are choosing them but most users don't know about them and don't want to know about them.
Window manager variety
Posted Apr 19, 2012 0:14 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
> but most users don't know about them and don't want to know about them.
and therefor (according to you) such choices should be eliminated so that NOBODY is able to use them.
By that logic Linux itself should never have been created, the iPhone should never have been created, nothing new should ever be created because everyone is perfectly happy with what they have.
Window manager variety
Posted Apr 19, 2012 17:47 UTC (Thu) by khim (subscriber, #9252)
[Link]
and therefor (according to you) such choices should be eliminated so that NOBODY is able to use them.
Probably. It really depends on the popularity of said things.
By that logic Linux itself should never have been created, the iPhone should never have been created, nothing new should ever be created because everyone is perfectly happy with what they have.
This is strange conclusion: we don't know if something will stick or not unless we'll try. Any new creation starts from one user and grows from there. Or not. If it becomes large enough then it gets enough resources to survive, if not then it's time to finish it.
Linux succeeded: it basically killed Unix and took it's niche, iPhone succeeded, too: it (along with Android) killed RIM and Symbian and took it's niche, webOS failed (and it's now time to write it off).
This is just a natural selection. It was not as troublesome 10, 20, or 100 years ago: markets grew, population grew, pool of knowledgeable workers grew, it was possible to keep both old and new things alive. Today… there are just not enough people to do that: if you want to continue to create something new then you must be ready to weed out something old, too.
Window manager variety
Posted Apr 19, 2012 13:14 UTC (Thu) by renox (subscriber, #23785)
[Link]
> Your definition of progress is kinda strange: tiling window managers were tried and explicitly rejected!
Your own definition of progress is weird too..
At the time most users had small screen, so the situation is different now, plus small difference in implementation can make big difference in end-user acceptance.
And "progress" is not something predictable!
Window manager variety
Posted Apr 19, 2012 10:10 UTC (Thu) by mpr22 (subscriber, #60784)
[Link]
I do not see how the "perfect size" for an arbitrary window can possibly be within the window manager's capability to determine, unless the display device is so pixel-limited that the only sane size for any window is "fullscreen".
Window manager variety
Posted Apr 20, 2012 8:56 UTC (Fri) by jezuch (subscriber, #52988)
[Link]
> I do not see how the "perfect size" for an arbitrary window can possibly be within the window manager's capability to determine, unless the display device is so pixel-limited that the only sane size for any window is "fullscreen".
Hmm, my only clue comes from Java's Swing UI toolkit, where everything is a tree of nested components, each component having a "minimal" and "preferred" sizes. The containers derive their minimal and preferred sizes from the contained components and the layout manager in use. There is even an operation called "pack" that resizes the window according to the preferred sizes of its components. A tiling manager could use this information but it required cooperation from the toolkit.
Window manager variety
Posted Apr 20, 2012 17:40 UTC (Fri) by apoelstra (subscriber, #75205)
[Link]
>> I do not see how the "perfect size" for an arbitrary window can possibly be within the window manager's capability to determine, unless the display device is so pixel-limited that the only sane size for any window is "fullscreen".
>Hmm, my only clue comes from Java's Swing UI toolkit, where everything is a tree of nested components, each component having a "minimal" and "preferred" sizes. The containers derive their minimal and preferred sizes from the contained components and the layout manager in use. There is even an operation called "pack" that resizes the window according to the preferred sizes of its components. A tiling manager could use this information but it required cooperation from the toolkit.
So the "perfect size" is determined by the application developer? No thanks.
Window manager variety
Posted Apr 21, 2012 20:47 UTC (Sat) by kleptog (subscriber, #1183)
[Link]
Looks like I confused a lot of people with the phrase "perfect size". What I was referring to was that I could have 4-8 terminals open and they would automatically all be visible without overlapping without me having to do anything.
That said, I didn't realise the tiling window manager was such an old concept. I hadn't seen it before though, I certainly haven't managed to get my default Ubuntu install to do it.
Window manager variety
Posted Apr 21, 2012 21:14 UTC (Sat) by khim (subscriber, #9252)
[Link]
That said, I didn't realise the tiling window manager was such an old concept.
Well, as I've said not only they are old, they were explicitly rejected. Windows developers apparently liked them (as you do) and though it'll be Windows advantage. Ha! The supposed “inability to create overlapped windows” was one of the more frequent complaints about Windows 1.0. It's obvious for the programmer that it was made explicitly (you had the ability to create and use any number of overlapping dialog windows in Windows 1.0, after all) but Joe Average (including Joe Magazine Observer Average) was quite literally unable to even imagine that someone will create something like this intentionally!
Of course the concept was quickly buried never to be seen on mainstream system again.
Window manager variety
Posted Apr 21, 2012 21:30 UTC (Sat) by dlang (✭ supporter ✭, #313)
[Link]
there are a lot of things that have been 'explicity rejected' by people in the past that are in common use today. It's not unusual for other things to change that make something that used to not be reasonable now become reasonable.
In the case of tiling window managers, one thing to remember is that the screen resolution when they were 'explicitly rejected' for windows 1.0 was 640x400, screens are a bit bigger today, so things that wouldn't work then can work now.
Also, you need to break your mindset that Microsoft is the ultimate authority on the Right Way to do everything
Window manager variety
Posted Apr 21, 2012 23:12 UTC (Sat) by khim (subscriber, #9252)
[Link]
there are a lot of things that have been 'explicity rejected' by people in the past that are in common use today. It's not unusual for other things to change that make something that used to not be reasonable now become reasonable.
Sure. But before you'll try to resurrect some old concept you need to find out why it failed in the past. If it's some technical limitation then it may be overcome, if it's something psychological then situation is much harder.
For example a lot of guys present iPhone (or sometimes iPad) as reincarnation of Newton, and yes, the devices look similar. But the difference is extreme: Newton was built around the handwriting recognition. It was it's cornerstone, everything else was built around this idea. And it just so happen that this idea does not work. iPhone/iPad looks similar, but they don't include stylus and don't use handwriting recognition. At all. You can as well say that contemporary planes are just a reimplementation of the Daedalus creation.
In the case of tiling window managers, one thing to remember is that the screen resolution when they were 'explicitly rejected' for windows 1.0 was 640x400, screens are a bit bigger today, so things that wouldn't work then can work now.
Perhaps, but I seriously doubt it. The biggest problem with tiling managers is perception of the lost control. People want to control their windows, not have them arranged automatically. Perhaps it's possible to create tiling manager which will feel natural, but I'm not holding my breath.
Also, you need to break your mindset that Microsoft is the ultimate authority on the Right Way to do everything.
Of course not! Microsoft is not perfect, but Microsoft is what people use. For better or for worse Windows defines expectations - simply because it's the most popular UI.
Even so… Microsoft tries very hard to destroy itself for the last five years or so. People hated (and still hate) their Ribbon - but apparently not enough to switch to something else. Perhaps Metro will finally push them over the edge?
This gives newcomes a chance. But I doubt something as radically different as tiling WM will be accepted by Joe Average even in the wake of Metro fisco.
Window manager variety
Posted Apr 22, 2012 0:46 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
> Perhaps, but I seriously doubt it. The biggest problem with tiling managers is perception of the lost control. People want to control their windows, not have them arranged automatically. Perhaps it's possible to create tiling manager which will feel natural, but I'm not holding my breath.
you are looking at things backwards.
If the talk about tiling window managers was only from people creating them, saying "this is what people should use" (the type of talk you see coming out of the Gnome or Unity projects for example), then you would have good reasons to point out past attempts and say "No, people don't really want that, here's why"
But when the statements are from people who are using a tiling window manager saying "It's the best thign I've ever used", then you should just shut up because otherwise you are telling people "no, you don't really like what you think you like"
As for Microsoft, If you really like what they do so much, go use it and let those of us who want some variation use what we want. We are used to having features as default (a desktop pager for example) that just aren't available (or only available via a third party hack) on Microsoft desktops.
The great thing is that on Linux, we don't force everyone to use the same thing. Even the distros that have a primary default allow you to switch to one of the other options (and in some cases, like Kubuntu, it's only barely a second class option)
Window manager variety
Posted Apr 22, 2012 11:40 UTC (Sun) by khim (subscriber, #9252)
[Link]
But when the statements are from people who are using a tiling window manager saying "It's the best thign I've ever used", then you should just shut up because otherwise you are telling people "no, you don't really like what you think you like"
Nice strawman. I said, quite literally: the concept was quickly buried never to be seen on mainstream system again and today they are in position similar to other old rejected technologies (such as Acme or FFM): some old-timers still use them and even few newcomers are choosing them but most users don't know about them and don't want to know about them.
How exactly this went from this to "no, you don't really like what you think you like" I'll never understand. It's quite obvious that I'm not talking about individual preferences here.
We are used to having features as default (a desktop pager for example) that just aren't available (or only available via a third party hack) on Microsoft desktops.
Right. But mindshare of people like you is shrinking and it's not clear where is the natural limit of this shrinkage. If some tools are only used by people in some small group then it may find out few years down the road that they just don't have the hardware they need and they can't run the software they want (while staying compatible with the rest of the world). History is littered by examples: Lisp machines (they were all the rage back in the day), RiscOS (ARM is quite popular today and you can even run RiscOS today on PandaBoard… but how many former RiscOS users actually do that?), Amiga ST, Atari, etc.
The great thing is that on Linux, we don't force everyone to use the same thing. Even the distros that have a primary default allow you to switch to one of the other options (and in some cases, like Kubuntu, it's only barely a second class option)
This is greatest strength of Linux and also is greatest weakness. RiscOS fate looks more and more real as time goes on. There was time not so long ago when people used Linux en masses in the university. Today they use MacOS instead. Even if it does not have a tiling window manager.
Window manager variety
Posted Apr 22, 2012 17:02 UTC (Sun) by apoelstra (subscriber, #75205)
[Link]
>But mindshare of people like you is shrinking and it's not clear where is the natural limit of this shrinkage.
Tiling window managers have recently seen a spike in usage, due (I believe) to the sudden destruction of GNOME by folks like you, who argue "users don't want to know about that, so let's stop supporting it" and remove essential features.
There is no question that tiling window managers are more efficient. Nowadays the most common complaint about window management is that wide screens are too wide to read on, and it's a PITA to manually resize windows to look nice on them. So, in Windows 7 you can now drag windows to the sides of the screen, and they'll fill that half. So you can emulate tiling for its most common use case.
As for history, the furthest back I can remember tiling was in Windows 95. You could right-click on the title bar and click "tile". It was crap. Every window got roughly a square inch of screen space, you couldn't control which ones were visible, in what order, how much space to allocate. The default window decorations were still in place, and together they took up around half the screen area. So I wondered what the point of such a stupid feature was, and forgot about it until just now.
But nowadays, I have too much screen space for comfortable full-screen apps, no mouse (since this is a laptop), and I want my windows either 100% visible or 0%. So I've got a tiling window manager, and -now- I think it's the greatest thing since sliced bread. I've showed it off to many people, and they all thought it was very cool (though they were Windows users and didn't have the option to try for themselves). I have never heard of anyone saying they were crap, or restrictive, or useless, until you.
Window manager variety
Posted Apr 22, 2012 17:37 UTC (Sun) by kleptog (subscriber, #1183)
[Link]
I think tiling windows managers are indeed a response to the fact that screen sizes are big enough now that you can comfortably fit 4-8 xterms on a screen and still be able to use them.
Fortunately things are not either/or. I have my xterms set to tile, because working with several machines at the same time it's useful to be able to see all the output next to each other at once, tabs just don't cut it. On the other hand, tiling makes less sense for the web browser or email. Hurray for configurability.
In my case since >80% of my windows are xterms it's more useful to have a tiling window manager that floats a few windows, than a floating window manager. But theoretically if a standard window manager had the option to enable tiling for a few applications you'd make 90% of tiling window manager users happy.
Judging by the comments on this thread though, I figure that's never going to happen.
BTW, there are tiling window managers for Windows, see the wikipedia article.
Window manager variety
Posted Apr 22, 2012 17:48 UTC (Sun) by rahulsundaram (subscriber, #21946)
[Link]
"Tiling window managers have recently seen a spike in usage, due (I believe) to the sudden destruction of GNOME by folks like you"
Attributing to khim the decisions by GNOME developers is fair to neither since khim is not a GNOME developer and doesn't speak for them or even share their mindset in any real way.
"So, in Windows 7 you can now drag windows to the sides of the screen, and they'll fill that half. So you can emulate tiling for its most common use case."
Funny enough, so does GNOME which voids your earlier argument.
Window manager variety
Posted Apr 13, 2012 0:29 UTC (Fri) by robert_s (subscriber, #42402)
[Link]
"If there is one thing I would like to happen, then that would be that nobody would replace Weston with anything else. We don't need 20 window managers, just 1 good enough one. I desperately wish this point was more widely appreciated."
This is utter nonsense. This idea may fly on proprietary desktops where a certain behaviour/layout/theme is provided or mandated from above by "god", but this is a collaboratively developed free desktop where people are able to implement and their preferences more freely.
Window manager variety
Posted Apr 13, 2012 0:45 UTC (Fri) by dlang (✭ supporter ✭, #313)
[Link]
even on Windows you can't get away with making major changes like this. Microsoft is shipping a different look, but they have the option to switch back to the old way of doing things.
Window manager variety
Posted May 10, 2012 15:53 UTC (Thu) by nye (guest, #51576)
[Link]
>Microsoft is shipping a different look, but they have the option to switch back to the old way of doing things.
No they don't. Metro could be disabled in the Developer Preview, but it can't in the Consumer Preview. It remains to be seen how the final release will work.
(I've been using Windows 8 for a couple of weeks now; in many ways it's a great improvement over previous versions, but the moment you have to interact with Metro it feels like you're on a truck that just hit a wall. It's a horrifying blunder; I can't believe they seriously thought they could release a new OS with changes like this after seeing how Vista was received.)
Window manager variety
Posted Apr 12, 2012 10:23 UTC (Thu) by cwng (guest, #74460)
[Link]
the window managers/compositors in Mac/Win come with and are not designed to be replaced by the end user. It'd be interesting to see if anyone has tried.
Actually, there have been quite a few attempts for Windows. Those that came to my mind would be LiteStep and Blackbox.
Window manager variety
Posted Apr 12, 2012 11:23 UTC (Thu) by cortana (subscriber, #24596)
[Link]
Those are replacing what Windows calls the "shell" and what is commonly called Explorer. They don't, AFAIK, replace what we would call the Window Manager and what most people don't have a name for, because it can't be replaced.
Window manager variety
Posted Apr 12, 2012 11:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
I distinctly remember being able to do things like collapsing windows to title bars by triple-clicking or adding extra buttons to window titlebars.
Window manager variety
Posted Apr 16, 2012 18:51 UTC (Mon) by sorpigal (subscriber, #36106)
[Link]
WindowBlinds was not a replacement window manager for Windows. It merely did some hackery to change some of the look and some behaviors and it always ran on top of the existing WM. Think of it more like a very-heavy theme. In the end things like window lists, window position and stacking order were still the same. In addition, it was awfully slow and memory hungry.
LFCS 2012: X and Wayland
Posted Apr 11, 2012 20:43 UTC (Wed) by drag (subscriber, #31333)
[Link]
> If applications handle their own decoration and Wayland does its own window management, how do we get the variety of window management systems we have now (tiling vs. "standard", virtual desktops, etc.)
> The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.
That.
However I am thinking that a superior approach would be to follow the Gnome Shell model of "Window Managing" and use a solid base of functionality and make it's behavior scriptable and extendable. The Shell Window manager is built on Metacity, which is a very mature simplistic window manager. But using that base and it's javascript nature I can have a tiling window manager without actually have to swap out window managers completely. (which I do tile windows on Gnome-shell via gtile)
That way people can just build and modify existing behavior rather then having to write a entire new window management system from scratch. That way they can concentrate on the functionality they desire rather then get caught up in replicating basic/common functionality correctly. Which seems a much faster way to get a large amount of customization possible.
LFCS 2012: X and Wayland
Posted Apr 12, 2012 19:43 UTC (Thu) by Fats (subscriber, #14882)
[Link]
> > The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.
> That.
What is still not clear to me is what happens when a client finds it is too busy or too important to obey the minimize gadget or a window drag ? Would it behave the same as on Windows, e.g. that the window won't budge ? If there is one thing I really dislike about Windows it must be this. I find this important and relying on well behaving clients doesn't cut it for me.
greets,
Staf.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 0:53 UTC (Fri) by hholzgra (subscriber, #11737)
[Link]
+1
AFAIR even the AMIGA did better on that than Windos (although i'd not bet more than 50¢ on it, too many years have gone by since then)
LFCS 2012: X and Wayland
Posted Apr 20, 2012 2:19 UTC (Fri) by tjc (subscriber, #137)
[Link]
Amiga Intuition was a separate process from the client, so even if the client fell over the window could still be managed. In 1985. On a 7 Mhz processor!
LFCS 2012: X and Wayland
Posted Apr 20, 2012 11:44 UTC (Fri) by dgm (subscriber, #49227)
[Link]
The same is true for the Wayland compositor.
With X11 you currently have 3 processes:
1. X server
2. X client
3. compositor/window manager
In Wayland you do away with the X server process. All it's duties unrelated to network communications (screen management, input handling) are incorporated into the compositor/window manager.
So, it will in fact look a lot more like Amiga's Intuition than current X does.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 7:48 UTC (Fri) by drag (subscriber, #31333)
[Link]
Well....
I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing.
Right?
So even though the application is drawing the main body I can still move it around by alt-clicking on the main body and dragging it even if the window is unresponsive.
So this does not seem to be a significant problem at all. All Wayland has to do is be aware of the what is the 'title bar' region of the window and be able to act accordingly when you click on that portion. It doesn't have to draw the title bar or close buttons to be aware of the them and be able to respond to clicks in the area of those items independently of the application itself.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 8:28 UTC (Fri) by khim (subscriber, #9252)
[Link]
Windows solves this problem with timeouts. Program can draw it's own decorations and process events in any way it wants to do that, but if it does not respond in timely fashion then OS imposes standard borders and allows you to do standard things (move/resize, close, etc).
LFCS 2012: X and Wayland
Posted Apr 13, 2012 9:25 UTC (Fri) by dgm (subscriber, #49227)
[Link]
This cannot apply to Wayland, because there's no concept of "draw your decorations" message. All drawing is application's business in Wayland, and done in a single step.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 9:34 UTC (Fri) by khim (subscriber, #9252)
[Link]
So what? Window manager can easily put it's own window with just a decorations and empty transparent body which will give the same affect.
LFCS 2012: X and Wayland
Posted Apr 16, 2012 13:38 UTC (Mon) by dgm (subscriber, #49227)
[Link]
Putting some standard borders is trivial, yes. The problem is detecting that the application is not drawing it's decorations, or more exactly, that it's not doing it so because it's hung or something (because it could be a feature, you know...)
A good alternative is let users point hung up applications themselves (using something like Xkill) and draw the "standard frame" then.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 9:30 UTC (Fri) by renox (subscriber, #23785)
[Link]
> I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing. Right?
Right: that's server-side decoration.
> All Wayland has to do is be aware of the what is the 'title bar' region of the window and be able to act accordingly when you click on that portion.
What you're suggesting is 'server side' window management, so you will have "ugly" window if the client doesn't answer fast enough, but the window will be resized/moved smoothly.
There is a tradeoff to be made:
a- client side decoration: the windows will be always displayed consistently even when resizing, but the animation may become jerky/unresponsive when resizing or moving if applications are slow to answer.
b- server side decoration/management: moving or resizing windows will be animated smoothly but the content of a window when resizing can be "ugly" (incoherent) if the application doesn't answer fast enough.
Wayland developers prefer (a), KDE developers (and I) prefer (b): they'll use their own compositor which will do server-side decoration instead of Weston.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 18:43 UTC (Fri) by Fats (subscriber, #14882)
[Link]
> There is a tradeoff to be made:
> a- client side decoration: the windows will be always displayed consistently even when resizing, but the animation may become jerky/unresponsive when resizing or moving if applications are slow to answer.
> b- server side decoration/management: moving or resizing windows will be animated smoothly but the content of a window when resizing can be "ugly" (incoherent) if the application doesn't answer fast enough.
To me it is clear. It has to be (b), (a) is a reason for me to not go for Wayland. Given that Wayland is using compositing for all windows the amount of uglyness in (b) will be limited: part of the window is cut off or not drawn yet.
Secondly I am waiting to see how network transparency will be implemented, vnc style remote usage won't cut it for me.
greets,
Staf.
LFCS 2012: X and Wayland
Posted Apr 14, 2012 9:24 UTC (Sat) by renox (subscriber, #23785)
[Link]
Well if you have a design like BeOS/Haiku where each application has a thread dedicated to the GUI, (a) may not be so bad as there should be no/vert rare slowdown of the application (it would also work very well with (b) of course).
As for network transparency, AFAIK VNC-like or XSpice-like are the only options for a future toolkit which would only know Wayland, OK for a LAN but for a WAN I'm not convinced that it would work well as I believe that client side decoration increase the number of round trip in some cases such as moving a window.
That said, Qt, GTK, EFL speak X so Wayland isn't a reason to be worried for WAN network transparency, the lack of integration of NX in X is a reason!
LFCS 2012: X and Wayland
Posted Apr 14, 2012 18:09 UTC (Sat) by raven667 (subscriber, #5198)
[Link]
I'm not worried about remoting over WAN links for Wayland because there are 20+ years of research and deployed protocols and I think that this is pretty much a solved problem. The real issue is that it'll take several years to implement something great but implementing something good enough should be easy. As you point out X11 isn't going anywhere so the situation can only get better and not worse.
LFCS 2012: X and Wayland
Posted Apr 15, 2012 9:27 UTC (Sun) by renox (subscriber, #23785)
[Link]
No, the real issue isn't the implementation: the real issue is having the toolkits agree on a common implementation.
DEB vs RPM show that it's quite possible, even for a basic infrastructure to have a division which hurts everybody (wasted time, efforts) which will stay for a long time.
LFCS 2012: X and Wayland
Posted Apr 19, 2012 21:25 UTC (Thu) by wmf (guest, #33791)
[Link]
That's why network transparency should be implemented once by Wayland itself in a toolkit-independent way.
LFCS 2012: X and Wayland
Posted Apr 19, 2012 22:00 UTC (Thu) by nybble41 (subscriber, #55106)
[Link]
Wayland is the wrong place for network transparency. When people speak of "network transparency" what they really mean is "efficient remote rendering", and Wayland does not define a rendering protocol. It is strictly a protocol for accessing the screen and input devices.
What we need is not a remote version of the Wayland protocol, which is inherently _local_ due to the use of shared memory, but general-purpose protocols for remote rendering and input, targeting Wayland for access to the hardware. For now, the X protocol can serve that purpose, as can single-window adaptations of VNC. Future protocols can take similar advantage of Wayland for the low-level hardware interfaces, and concentrate instead on remote rendering.
LFCS 2012: X and Wayland
Posted Apr 22, 2012 16:48 UTC (Sun) by VITTUIX-MAN (guest, #82895)
[Link]
Wayland is exactly the right place to implement network transparency, in XPRA way in a network aware compositor.
This does all the things we love in networked X, that is mainly rootlessness is the default and it would allow plugging into a running session, so connection problems would no longer close all open programs.
LFCS 2012: X and Wayland
Posted Apr 22, 2012 17:16 UTC (Sun) by renox (subscriber, #23785)
[Link]
> Wayland is exactly the right place to implement network transparency, in XPRA way in a network aware compositor.
In my understanding currently:
- the stock server (Weston) doesn't know when a user moves/resizes a window until the client tells it, so there must be a round trip before any action happen: far from ideal in a WAN.
- Wayland has very limited server rendering, so to be able to have XRender-way to display text, you'd have to change it significantly, until then Wayland will use much more bandwith to display text than X (if the toolkit use the XRender extension of course).
LFCS 2012: X and Wayland
Posted Apr 20, 2012 7:30 UTC (Fri) by renox (subscriber, #23785)
[Link]
> That's why network transparency should be implemented once by Wayland itself in a toolkit-independent way.
Except that it isn't possible to have network transparency which works well in a WAN with Wayland, without changing radically how Wayland works.
Two examples:
-Wayland developpers prefer CSD decoration: think about what this imply in term of latency when you want to move a window in a WAN vs server side management of windows.
-Also an X client can send an image of each letter only once on the server, cache it there, and then reuse it: very efficient in terms of bandwith usage, but currently Wayland don't provide this and as nybble41 said, it would be a big change to add a remote rendering protocol.
LFCS 2012: X and Wayland
Posted Apr 20, 2012 9:56 UTC (Fri) by cortana (subscriber, #24596)
[Link]
Do modern (as in, recently written) X clients actually use this font caching mechanism? I thought they all used FreeType (through various wrapping layers) to render on the client side these days.
LFCS 2012: X and Wayland
Posted Apr 20, 2012 11:45 UTC (Fri) by renox (subscriber, #23785)
[Link]
You misunderstood what I wrote: they render the font on the client, send the image of the letters *once* on the server, and can now display text very efficiently from a bandwith POV (all this if the XServer has the XRender extension).
LFCS 2012: X and Wayland
Posted Apr 20, 2012 12:04 UTC (Fri) by chris.wilson (subscriber, #42619)
[Link]
With the Render protocol, glyph images are no longer generated by the server but rather by the client who uploads a set of glyph images for a font. Typically, the client does use FreeType to render the individual glyph images. The server de-duplicates those images across all the clients and maintains the glyph image for later use by the client. When the client then renders some text it converts the string of characters into a set of (font, glyph index, position) tuples and sends that as a rendering request along with the operator to use and source pattern to apply. That request is passed to the driver, which typically prescans the request and uploads unseen glyphs into a texture atlas cache (using random replacement of old glyph entries to maintain fairness across all clients) and then converts it into a command stream for the GPU. By using a texture atlas, the number of state changes required for the command stream is minimised, though still one or two extra are incurred in order to adhere to the Render semantics.
In contrast, the core protocol differs in that the server renders the glyph images itself, and so has a fixed concepts of fonts and glyphs and needs to inform the client of the font/glyph metrics, and in the various semantics of the operators and patterns. That the core fonts were only bitmaps and so were easier for hardware to implement and are still faster than compositing glyphs using Render, is an implementation detail.
LFCS 2012: X and Wayland
Posted Apr 20, 2012 18:26 UTC (Fri) by raven667 (subscriber, #5198)
[Link]
> Except that it isn't possible to have network transparency which works well in a WAN with Wayland, without changing radically how Wayland works.
I really doubt that's true, maybe you are unfamiliar with remote rendering protocols other than X?
> Wayland developpers prefer CSD decoration: think about what this imply in term of latency when you want to move a window in a WAN vs server side management of windows.
I don't think client side decorations have anything to do with window management and I can't envision the problem you seem to be describing. I can't see how window move performance would be affected based on which process is drawing the border, in either case you have a rectangle that needs to be moved around. In fact I would expect the client side decorations to be faster because the current X architecture where window management and borders are in the same process requires extra round trips and coordination between the application, X and the window manger to make sure the borders are adjacent and not overlapping the window contents as it is being moved. This architecture also causes a lot of tearing, as the window contents and window border are drawn at different times by different apps.
> Also an X client can send an image of each letter only once on the server, cache it there, and then reuse it
As the people who are designing wayland (primarily a display protocol for local apps) are also the ones who designed the font caching you describe I think they can figure out how to make an efficient remote protocol if they apply themselves to it 8-)
LFCS 2012: X and Wayland
Posted Apr 16, 2012 14:14 UTC (Mon) by dgm (subscriber, #49227)
[Link]
>> I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing. Right?
>Right: that's server-side decoration.
No, that's window management. Decoration is just drawing borders around the window rectangle. in Wayland you still have a window manager, it's the compositor. The compositor does move windows around, hide or display them. It can do other things like distort them or map them to the sides of a spinning cube.
> a- client side decoration: the windows will be always displayed consistently even when resizing, but the animation may become jerky/unresponsive when resizing or moving if applications are slow to answer.
> b- server side decoration/management: moving or resizing windows will be animated smoothly but the content of a window when resizing can be "ugly" (incoherent) if the application doesn't answer fast enough.
As I said, the compositor can distort windows, so nothing prevents it from doing resizing the smooth and ugly way if needed. This will mean that, usually, applications will simple resize nice and smoothly, but if for some reason an application cannot resize fast enough, a good compositor can interpolate frames and keep the resizing smooth. It's the best of both worlds.
And again, this has nothing to do with decorations, but with window management. Currently the X11 window manager does both, but in Wayland those tasks are split between the application and the compositor.
LFCS 2012: X and Wayland
Posted Apr 16, 2012 15:00 UTC (Mon) by renox (subscriber, #23785)
[Link]
>>> I can alt-click a window to move it in Xfree even if the application is blocking and I happen to click on a portion of the window that the application itself is responsible for drawing. Right?
>>Right: that's server-side decoration.
> No, that's window management.
In current systems server-side decoration imply server side window management, so I'd say you're nitpicking, but yes that's server side window management.
> [cut] a good compositor can interpolate frames and keep the resizing smooth
Not sure this would be so good: the client already took "too long" to answer and then the animation between both frames would add also some delay..
LFCS 2012: X and Wayland
Posted Apr 16, 2012 17:11 UTC (Mon) by Fats (subscriber, #14882)
[Link]
> No, that's window management. Decoration is just drawing borders around the window rectangle. in Wayland you still have a window manager, it's the compositor. The compositor does move windows around, hide or display them. It can do other things like distort them or map them to the sides of a spinning cube.
I don't understand it. How does the compositor know that it has to move or minimize a window if the client is responsible for the window drag bar and the minimization widgets ?
LFCS 2012: X and Wayland
Posted Apr 16, 2012 17:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
[Link]
Easy. Add an 'override mode' to the compositor.
If a window doesn't respond to messages in (say) 2 seconds then the compositor can draw overlay on it with largish "Minimize" and "Force Close" buttons. Additionally, you can add keyboard/mouse shortcuts for that (for example, this overlay can be brought up by triple clicking on a window, etc).
LFCS 2012: X and Wayland
Posted Apr 17, 2012 8:07 UTC (Tue) by renox (subscriber, #23785)
[Link]
>If a window doesn't respond to messages
And to a specific "ping message" I think as it should be possible for a window to ignore some events.
> then the compositor can draw overlay on it with largish "Minimize" and "Force Close" buttons.
"Force Close" OK but I'm not so sure about minimizing/hiding: I thought that this part was handled by the clients.
LFCS 2012: X and Wayland
Posted Apr 17, 2012 8:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
>And to a specific "ping message" I think as it should be possible for a window to ignore some events.
Yup. Patches to add 'ping event' and shading of inactive windows have just been posted today: http://www.phoronix.com/scan.php?page=news_item&px=MT...
>"Force Close" OK but I'm not so sure about minimizing/hiding: I thought that this part was handled by the clients.
Compositor can hide/minimize windows forcibly (and restore them back if unresponsive application recovers). I.e. it might look like:
1) A window grays out.
2) "Force Close" and "Hide" buttons appear
3) You press "Hide" button and window disappears.
4) An icon in the system notification area appears notifying you that there are unresponsive applications. You can right-click on it and bring up a list of forcibly closed apps, with possibility to unhide or kill them.
5) If application recovers, then the user can be notified by flashing icon on the notification area.
Something like this.
LFCS 2012: X and Wayland
Posted Apr 17, 2012 17:21 UTC (Tue) by Fats (subscriber, #14882)
[Link]
> Easy. Add an 'override mode' to the compositor.
So is this in the Wayland architecture ?
LFCS 2012: X and Wayland
Posted Apr 17, 2012 18:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
It's not yet implemented (the very basic 'fading of inactive clients' was pushed yesterday) but it's certainly within the Wayland architecture and perfectly doable.
LFCS 2012: X and Wayland
Posted Apr 17, 2012 19:07 UTC (Tue) by Fats (subscriber, #14882)
[Link]
OK, now still add per-client network transparancy (not per-desktop) optionally with NX-style reconnectability and then I may consider Wayland as an option.
LFCS 2012: X and Wayland
Posted Apr 17, 2012 19:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
It's certainly possible. As I understand, something like xpra for Wayland is in the works.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 12:13 UTC (Fri) by HelloWorld (guest, #56129)
[Link]
With X, you're relying on well-behaving clients all the time. Applications can stop the window manager from drawing decorations, they can move windows around however they like etc. etc.. Yet, things seem to more or less work.
LFCS 2012: X and Wayland
Posted Apr 13, 2012 16:21 UTC (Fri) by alankila (subscriber, #47141)
[Link]
And there is X grab, the ability of a single client to prevent you from further interacting with the desktop.
LFCS 2012: X and Wayland
Posted Apr 17, 2012 17:24 UTC (Tue) by Fats (subscriber, #14882)
[Link]
> And there is X grab, the ability of a single client to prevent you from further interacting with the desktop.
And programs who do that trick to me 2 times gets deinstalled. Thing is that it is more uncommon for an application to grab display than to need to reply to minimize or move requests.