Going Indepth With Wayland Sub-Surfaces

[TheBlackCat]

Is Wayland utterly trying to gnome-ize the linux desktop then? Neither the protocol nor the compositor should make assumptions about what minimization means ,is or should be for applications in general . The job of compositor is to 'paint' the application and nothing else .

You just completely ignored everything I said.

That is none of your business nor Wayland's business nor the compositor's business . "Separation of concerns " See?. That's a choice made by the developer, it does not matters if you like to or not. And what do you meant by "standard API"?

Window management is done by the window manager, not by individual applications. Applications trying to fight the window manager only leads to problems.

[makomk]

The point is, since currently all wayland apps have client side decorations, there is the need of a protocol to let the client ask the compositor to minimize it when the user click on the minimize button. That is not in the wl_shell_surface protocol, so you can't minimize any wayland app currently, on any compositor (again, when clicking on the minimize button in the decoration. A compositor can still minimize a window if the operation is started by the compositor itself, like clicking on a "minimize" entry in the context menu of the task bar.). The xdg_shell protocol that is being worked on will have that feature.

So if I'm following this correctly, it's basically like the situation we have right now with input on X - the original protocol has been essentially obsoleted by a new one, but all compositors that want to be able to run older applications and all applications that need to be able to run on older compositor versions will need to have duplicate codepaths supporting two different, incompatible APIs for window handling. Wasn't this what we were meant to be getting away from with X?

[TheBlackCat]

An IM client might show you as "away" when minimized, a RSS reader might optimize by not checking as often when minimized, and so on. It doesn't have to be rendering-related.

What about a tablet DE that only has full-screen apps? Apps are pushed to the back the queue when not visible. They aren't minimized, but in terms of how they behave should be similar. What about when someone hovers over a minimized version of their RSS reader and gets a thumbnail, should the RSS reader still not update? What about when an app is docked to the edge of the screen as a small thumbnail. Is that minimized or not?

Given all the sorts of DEs we have today, desktops, tablets, phones, TVs, "minimize" isn't really a useful indication of how active the application should be. I would say in such a situation, the RSS reader would be better of not updating as often when it isn't being rendered. This should tell the RSS reader that it isn't very important right now, even if it might not be minimized.

[Alex Sarmiento]

What about a tablet DE that only has full-screen apps? Apps are pushed to the back the queue when not visible. They aren't minimized, but in terms of how they behave should be similar. What about when someone hovers over a minimized version of their RSS reader and gets a thumbnail, should the RSS reader still not update? What about when an app is docked to the edge of the screen as a small thumbnail. Is that minimized or not?

A Desktop Environment (DE) in a tablet, how is that to begin with? If the environment neither accepts nor implements minimization and only implements fullscreen apps then obviously asking for minimization makes no sense, so that's just circular reasoning. And how do you read text from a thumbnail? Why do you assume that the application is going to assume that the compositor is going to render a thumbnail?

Given all the sorts of DEs we have today, desktops, tablets, phones, TVs, "minimize" isn't really a useful indication of how active the application should be. I would say in such a situation, the RSS reader would be better of not updating as often when it isn't being rendered. This should tell the RSS reader that it isn't very important right now, even if it might not be minimized.

That's none of wayland's business to decide if minimization is useful or not! don't you get it? Is none of Wayland business to decide what the application should do. Certain application X wants to perform this or that operation when the user clicks the minimize button. Or wants to be minimized when the user performs certain operation. End of story! It does not matters if you think it is a good idea or not . Wayland is supposed to be a general purpose protocol

Or is wayland being designed just around the gnome shell ? Because that kind of rationalizations can only be found in the gnometopia land.

[curaga]

What about a tablet DE that only has full-screen apps? Apps are pushed to the back the queue when not visible. They aren't minimized, but in terms of how they behave should be similar. What about when someone hovers over a minimized version of their RSS reader and gets a thumbnail, should the RSS reader still not update? What about when an app is docked to the edge of the screen as a small thumbnail. Is that minimized or not?

That's up to that DE to decide. The DE is in the position of knowing if it makes sense to send the "minimized" hint/message.

RSS fetching while its thumbnail is displayed? I would make that a configurable option in the RSS reader, assuming the developers of it cared enough for such thumbnailing DEs.

[TheBlackCat]

If the environment neither accepts nor implements minimization and only implements fullscreen apps then obviously asking for minimization makes no sense, so that's just circular reasoning.

No, it isn't. The point is that minimization is not a good cue for apps, both in systems with minimization and systems without. The app shouldn't be guessing what the window manager is trying to do. It is only useful in a very, very, narrow range of situations that implement minimization in a very specific manner.

And how do you read text from a thumbnail? Why do you assume that the application is going to assume that the compositor is going to render a thumbnail?

Depends on how big the thumbnail is. And the applications shouldn't assume anything. That is my point. Your approach will only work if the application assumes a bunch of things about how minimization will be implemented, things that are not necessarily the case, and further it assumes a lot of things about how now-minimized states are.

That's none of wayland's business to decide if minimization is useful or not! don't you get it? Is none of Wayland business to decide what the application should do.

No, and I never said it was. Window management tasks are the job of the window manager. That is the whole reason we have window managers in the first place.

[QUOTE=Alex Sarmiento;374101]Certain application X wants to perform this or that operation when the user clicks the minimize button. Or wants to be minimized when the user performs certain operation. End of story! It does not matters if you think it is a good idea or not.[/quote/
Again, what business does the application have handling window management? That is what we have window managers for. Why do you insist that applications have the right to override the window manager? That completely defeats the purpose of having window managers at all. If what you are saying is right, why don't we just throw out window managers entirely and leave everything up to applications? This has nothing to do with wayland, it has to do with window managers vs. applications.

Or is wayland being designed just around the gnome shell ? Because that kind of rationalizations can only be found in the gnometopia land.

I don't use Gnome and I never plan to. I use KDE, and I like kwin deciding how my window managers behave. One thing I am absolutely sick of on windows is apps like skype deciding they want to completely ignore standard behavior and just do whatever the heck they want when users push a button. Close doesn't close. Minimize leaves a window open. The last thing I want is applications deciding that they want to completely break standard window interaction.

[Alex Sarmiento]

No, it isn't. The point is that minimization is not a good cue for apps, both in systems with minimization and systems without. The app shouldn't be guessing what the window manager is trying to do.

Why not. I mean, the application should not care what the Window Manager is doing, the application only cares about what the user wants. If the user wants minimization, the application should know that. Who cares about how the WM paints the minimization?

It is only useful in a very, very, narrow range of situations that implement minimization in a very specific manner.

I am not talking about how to render the minimization , but what the application does when is already minimized .

Depends on how big the thumbnail is

.

What do you think a thumbnail is?

And the applications shouldn't assume anything. That is my point. Your approach will only work if the application assumes a bunch of things about how minimization will be implemented, things that are not necessarily the case, and further it assumes a lot of things about how now-minimized states are.

No, the application does not cares about how the minimization looks. Neither the WM cares what the application does when is minimized.

No, and I never said it was. Window management tasks are the job of the window manager. That is the whole reason we have window managers in the first place.

I agree , Window managers don't tell what the application should do neither.

Again, what business does the application have handling window management? That is what we have window managers for. Why do you insist that applications have the right to override the window manager? That completely defeats the purpose of having window managers at all. If what you are saying is right, why don't we just throw out window managers entirely and leave everything up to applications? This has nothing to do with wayland, it has to do with window managers vs. applications.

You seems to be stuck in a mental loop. You do not seem to understand what a Window Manager is, neither. Applications are not there so the window managers can exist. Window Managers exist only to arrange the graphical applications according to the input of the user , nothing else. The input could even be via application, so the window manager should obey.

I don't use Gnome and I never plan to. I use KDE, and I like kwin deciding how my window managers behave. One thing I am absolutely sick of on windows is apps like skype deciding they want to completely ignore standard behavior and just do whatever the heck they want when users push a button. Close doesn't close. Minimize leaves a window open. The last thing I want is applications deciding that they want to completely break standard window interaction.

You don't like it, who cares . Some people like it or just don't care. That is not Wayland's business anyways .

[TheBlackCat]

Why not. I mean, the application should not care what the Window Manager is doing, the application only cares about what the user wants. If the user wants minimization, the application should know that. Who cares about how the WM paints the minimization?

I am not talking about how to render the minimization , but what the application does when is already minimized .

Are you just completely ignoring me? I am not talking about the minimization animation, I gave a number of situations regarding how the minimized window is represented.

What do you think a thumbnail is?

A smaller image of something, but they can be big enough to be legible.

No, the application does not cares about how the minimization looks. Neither the WM cares what the application does when is minimized.

Now I am sure you are ignoring me. As I explained, with many modern window managers the window manager has to care, because it does stuff with the window besides just "make it invisible".

You seems to be stuck in a mental loop. You do not seem to understand what a Window Manager is, neither. Applications are not there so the window managers can exist. Window Managers exist only to arrange the graphical applications according to the input of the user , nothing else. The input could even be via application, so the window manager should obey.

You seem to be stuck in the 1990's. Many modern window manager do a lot more than that. Unfortunately some application developers seem to be stuck in the same time period, not realizing that the assumptions they made from that time no longer apply in modern desktop environments.