If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Anyone have insight to why special functionality is needed? What is stopping the compositor from managing individual window size, since it already controls the chrome, such that if you size a window to 0x0 it is minimized, and the compositor can implement maximize and fullscreen to just give the application the desktop-chromed max window size and a borderless full screen window?

It just seems like it is a sound abstraction to consider a window that percieves its draw area as 0x0 pixels as being hidden or otherwise minimized, and I don't see many applications that need to care how big its window is relative to the desktop (it just needs to be alerted to size changes to reorient contents).

Comment

Anyone have insight to why special functionality is needed? What is stopping the compositor from managing individual window size, since it already controls the chrome, such that if you size a window to 0x0 it is minimized, and the compositor can implement maximize and fullscreen to just give the application the desktop-chromed max window size and a borderless full screen window?

It just seems like it is a sound abstraction to consider a window that percieves its draw area as 0x0 pixels as being hidden or otherwise minimized, and I don't see many applications that need to care how big its window is relative to the desktop (it just needs to be alerted to size changes to reorient contents).

I don't know details, but caching and resource control comes to mind. If you minimize already existing window, you are giving composer a hnt that you might maximize it sometime later.

If you just resize it, your are practically throwing away everything that might be already drawn within. Also, you are straining infrastructure with dealocation of resources only to be allocated probably short time later.

Comment

I don't know details, but caching and resource control comes to mind. If you minimize already existing window, you are giving composer a hnt that you might maximize it sometime later.

If you just resize it, your are practically throwing away everything that might be already drawn within. Also, you are straining infrastructure with dealocation of resources only to be allocated probably short time later.

Well I don't know but the description to me sounds like this design might finally fix the issue of not having the ability to have a live preview of a minimized window that shows up in other display servers.

Comment

Weston supports maximizing and returning to its pre-maximized state, they're just working out how to do it in the cleanest fashion. Please stop jumping to absurd conclusions Michael, or you could just ask me when you're unsure about some details.

Comment

The patches are supporting minimize and what ever it's called when the window comes out of the task manager (minimize?).

Applications can already maximize and restore, and they already could for a long time.

The reason why this functionality has to be added for minimize, is because in order to know how to create the entry in the 'task bar' of which it can minimize to, the application needs a way to tell the shell what the title and icon is, and everything.

Comment

I thought this article was about a Wayland feature, and not about a moral lesson for Canonical. Rly needed to mention Mir here? Why not say...'X has been supporting this for years, despite the primitive implementation..."?

Anyway I don't know why I still hope for quality articles in this blog, it isn't what it used to be, too much personal feelings and too little objectivity.