minimized and stick windows
Hello, I've been looking the Weston code relative to maximized windows, and it seems that the respective code for minimized windows wouldn't be hard to implement. The questions are: are there any plans to add it? Is there someone already working on it? If not, would it be OK if I start submitting patches to try to add support for this? Of course the minimize feature would be more useful if we had a taskbar, or something like that, but I guess that having the code necessary for just minimizing the window would already be great. I also would like to implement, if possible the "sticky" window feature (when a window is pinned, visible on every workspace). Is this a desired feature too? Regards, -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Hi Rafael, On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli wrote: > Hello, > > I've been looking the Weston code relative to maximized windows, and > it seems that the respective code for minimized windows wouldn't be > hard to implement. > > The questions are: are there any plans to add it? Is there someone > already working on it? If not, would it be OK if I start submitting > patches to try to add support for this? > A month or two ago, Scott Morreau was working on it. However, his work never made into weston for a variety of reasons. Personally, I'm glad to see someone interested in working on it again because it's something that wayland will need eventually. The place to start on it is probably with the following e-mail and the long string of replies: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html There was quite a bit of discussion about how to handle it from a protocol level, but Scott never made an actual version 2. I'd suggest you start by reading the chain of e-mails (it goes into April, not just March). There were quite a few suggestions in there that could be incorporated. Hopefully, you can pick through the e-mail discussion and figure out what the consensus was. It'd be good to have a pair of fresh eyes look at it. Of course the minimize feature would be more useful if we had a > taskbar, or something like that, but I guess that having the code > necessary for just minimizing the window would already be great. > Scott also had a taskbar implemented and a right-click menu. That said, I haven't looked through all of his code and I have no idea what it's like. > I also would like to implement, if possible the "sticky" window > feature (when a window is pinned, visible on every workspace). Is this > a desired feature too? > I'm not the person to answer that question. Thanks for looking into this, --Jason Ekstrand ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Hi Jason, On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand wrote: > Hi Rafael, > > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli > wrote: >> >> Hello, >> >> I've been looking the Weston code relative to maximized windows, and >> it seems that the respective code for minimized windows wouldn't be >> hard to implement. >> >> The questions are: are there any plans to add it? Is there someone >> already working on it? If not, would it be OK if I start submitting >> patches to try to add support for this? > > > A month or two ago, Scott Morreau was working on it. However, his work > never made into weston for a variety of reasons. Personally, I'm glad to > see someone interested in working on it again because it's something that > wayland will need eventually. > > The place to start on it is probably with the following e-mail and the long > string of replies: > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > > There was quite a bit of discussion about how to handle it from a protocol > level, but Scott never made an actual version 2. I'd suggest you start by > reading the chain of e-mails (it goes into April, not just March). There > were quite a few suggestions in there that could be incorporated. > Hopefully, you can pick through the e-mail discussion and figure out what > the consensus was. It'd be good to have a pair of fresh eyes look at it. Thanks for pointing that out. I just went through the chain of e-mails, but I don't think there was a consensus there. It also seems that the minimize implementation is a little more complex than just hiding surfaces and marking some flags. Which makes me not so comfortable doing an implementation without a consensus about what should be implemented, and with some orientation. That said, I'm not sure I'm really going to take this task. Thank you for your support anyway. -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli wrote: > Hi Jason, > > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand > wrote: > > Hi Rafael, > > > > > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli > > wrote: > >> > >> Hello, > >> > >> I've been looking the Weston code relative to maximized windows, and > >> it seems that the respective code for minimized windows wouldn't be > >> hard to implement. > >> > >> The questions are: are there any plans to add it? Is there someone > >> already working on it? If not, would it be OK if I start submitting > >> patches to try to add support for this? > > > > > > A month or two ago, Scott Morreau was working on it. However, his work > > never made into weston for a variety of reasons. Personally, I'm glad to > > see someone interested in working on it again because it's something that > > wayland will need eventually. > > > > The place to start on it is probably with the following e-mail and the > long > > string of replies: > > > > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > > > > There was quite a bit of discussion about how to handle it from a > protocol > > level, but Scott never made an actual version 2. I'd suggest you start > by > > reading the chain of e-mails (it goes into April, not just March). There > > were quite a few suggestions in there that could be incorporated. > > Hopefully, you can pick through the e-mail discussion and figure out what > > the consensus was. It'd be good to have a pair of fresh eyes look at it. > > Thanks for pointing that out. I just went through the chain of > e-mails, but I don't think there was a consensus there. > > It also seems that the minimize implementation is a little more > complex than just hiding surfaces and marking some flags. Which makes > me not so comfortable doing an implementation without a consensus > about what should be implemented, and with some orientation. > > That said, I'm not sure I'm really going to take this task. > I didn't intend to scare you off. Honestly, I don't know for 100% certain how much weston machinery is needed to implement it. It would require some sort of set of flags to keep the compositor and shell plugin in sync. That said, I don't know if its quite as difficult as Scott made it sound. As far as direction goes, the first thing is to think through use-cases and settle on a protocol. Unfortunately, the discussion I linked you to seemed to go nowhere. However, a lot of that was Scott saying, "This is the way I want to do it and I'm not going to change." If you look at the other comments, I think there was some consensus in there (at least in a general direction). Feel free to throw some XML together and we can re-start the discussion. For that matter, if you can come up with a way to do it as a weston extension for now (with the hopes of putting it in wayland core later), things can be a lot more flexible and we can play around with protocol concepts as we go. Once a basic protocol is in place, then the client-side needs to be implemented in tinytk (window.c) and the server-side needs to be implemented in weston. I'm sorry "I want to add X feature" isn't simpler. Basically every new major protocol piece goes through a long mailing list discussion and a lot of revision. --Jason Ekstrand ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Mon, 13 May 2013 17:26:28 -0500 Jason Ekstrand wrote: > On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli > wrote: > > > Hi Jason, > > > > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand > > wrote: > > > Hi Rafael, > > > > > > > > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli > > > wrote: > > >> > > >> Hello, > > >> > > >> I've been looking the Weston code relative to maximized windows, and > > >> it seems that the respective code for minimized windows wouldn't be > > >> hard to implement. > > >> > > >> The questions are: are there any plans to add it? Is there someone > > >> already working on it? If not, would it be OK if I start submitting > > >> patches to try to add support for this? > > > > > > > > > A month or two ago, Scott Morreau was working on it. However, his work > > > never made into weston for a variety of reasons. Personally, I'm glad to > > > see someone interested in working on it again because it's something that > > > wayland will need eventually. > > > > > > The place to start on it is probably with the following e-mail and the > > long > > > string of replies: > > > > > > > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > > > > > > There was quite a bit of discussion about how to handle it from a > > protocol > > > level, but Scott never made an actual version 2. I'd suggest you start > > by > > > reading the chain of e-mails (it goes into April, not just March). There > > > were quite a few suggestions in there that could be incorporated. > > > Hopefully, you can pick through the e-mail discussion and figure out what > > > the consensus was. It'd be good to have a pair of fresh eyes look at it. > > > > Thanks for pointing that out. I just went through the chain of > > e-mails, but I don't think there was a consensus there. > > > > It also seems that the minimize implementation is a little more > > complex than just hiding surfaces and marking some flags. Which makes > > me not so comfortable doing an implementation without a consensus > > about what should be implemented, and with some orientation. > > > > That said, I'm not sure I'm really going to take this task. > > > > I didn't intend to scare you off. Honestly, I don't know for 100% certain > how much weston machinery is needed to implement it. It would require some > sort of set of flags to keep the compositor and shell plugin in sync. That > said, I don't know if its quite as difficult as Scott made it sound. > > As far as direction goes, the first thing is to think through use-cases and > settle on a protocol. Unfortunately, the discussion I linked you to seemed > to go nowhere. However, a lot of that was Scott saying, "This is the way I > want to do it and I'm not going to change." If you look at the other > comments, I think there was some consensus in there (at least in a general > direction). Feel free to throw some XML together and we can re-start the > discussion. For that matter, if you can come up with a way to do it as a > weston extension for now (with the hopes of putting it in wayland core > later), things can be a lot more flexible and we can play around with > protocol concepts as we go. > > Once a basic protocol is in place, then the client-side needs to be > implemented in tinytk (window.c) and the server-side needs to be > implemented in weston. > > I'm sorry "I want to add X feature" isn't simpler. Basically every new > major protocol piece goes through a long mailing list discussion and a lot > of revision. Also worth noting, that there are actually two different pieces of protocol involved with minimized windows: - the public protocol, likely part of wl_shell_surface, which all applications use to communicate with the server. This is the important part that will go under strict review, but it is probably also the simpler of the two. You could also check what DE projects have done on this (Gnome/gtk, KDE/Qt, EFL, ...). - the private protocol between Weston and weston-desktop-shell specifically. As we have chosen to let weston-desktop-shell client do all the GUI drawing, and minimized windows will need some GUI (a task bar button, a menu list of windows) to be able to get them back, we need protocol to inform weston-desktop-shell about the windows so it can draw the GUI. But these should not be complicated, once you understand how the basics of a Wayland protocol work. And you don't need to have any complex foreign surface passing protocol to get window thumbnails by hovering the pointer over a taskbar button. Thumbnails can be added later, as it does not concern the public protocol at all. Cheers, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen wrote: > On Mon, 13 May 2013 17:26:28 -0500 > Jason Ekstrand wrote: > >> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli >> wrote: >> >> > Hi Jason, >> > >> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand >> > wrote: >> > > Hi Rafael, >> > > >> > > >> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli >> > > wrote: >> > >> >> > >> Hello, >> > >> >> > >> I've been looking the Weston code relative to maximized windows, and >> > >> it seems that the respective code for minimized windows wouldn't be >> > >> hard to implement. >> > >> >> > >> The questions are: are there any plans to add it? Is there someone >> > >> already working on it? If not, would it be OK if I start submitting >> > >> patches to try to add support for this? >> > > >> > > >> > > A month or two ago, Scott Morreau was working on it. However, his work >> > > never made into weston for a variety of reasons. Personally, I'm glad to >> > > see someone interested in working on it again because it's something that >> > > wayland will need eventually. >> > > >> > > The place to start on it is probably with the following e-mail and the >> > long >> > > string of replies: >> > > >> > > >> > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html >> > > >> > > There was quite a bit of discussion about how to handle it from a >> > protocol >> > > level, but Scott never made an actual version 2. I'd suggest you start >> > by >> > > reading the chain of e-mails (it goes into April, not just March). There >> > > were quite a few suggestions in there that could be incorporated. >> > > Hopefully, you can pick through the e-mail discussion and figure out what >> > > the consensus was. It'd be good to have a pair of fresh eyes look at it. >> > >> > Thanks for pointing that out. I just went through the chain of >> > e-mails, but I don't think there was a consensus there. >> > >> > It also seems that the minimize implementation is a little more >> > complex than just hiding surfaces and marking some flags. Which makes >> > me not so comfortable doing an implementation without a consensus >> > about what should be implemented, and with some orientation. >> > >> > That said, I'm not sure I'm really going to take this task. >> > >> >> I didn't intend to scare you off. Honestly, I don't know for 100% certain >> how much weston machinery is needed to implement it. It would require some >> sort of set of flags to keep the compositor and shell plugin in sync. That >> said, I don't know if its quite as difficult as Scott made it sound. >> >> As far as direction goes, the first thing is to think through use-cases and >> settle on a protocol. Unfortunately, the discussion I linked you to seemed >> to go nowhere. However, a lot of that was Scott saying, "This is the way I >> want to do it and I'm not going to change." If you look at the other >> comments, I think there was some consensus in there (at least in a general >> direction). Feel free to throw some XML together and we can re-start the >> discussion. For that matter, if you can come up with a way to do it as a >> weston extension for now (with the hopes of putting it in wayland core >> later), things can be a lot more flexible and we can play around with >> protocol concepts as we go. >> >> Once a basic protocol is in place, then the client-side needs to be >> implemented in tinytk (window.c) and the server-side needs to be >> implemented in weston. >> >> I'm sorry "I want to add X feature" isn't simpler. Basically every new >> major protocol piece goes through a long mailing list discussion and a lot >> of revision. > > Also worth noting, that there are actually two different pieces of > protocol involved with minimized windows: > > - the public protocol, likely part of wl_shell_surface, which all > applications use to communicate with the server. This is the > important part that will go under strict review, but it is probably > also the simpler of the two. You could also check what DE > projects have done on this (Gnome/gtk, KDE/Qt, EFL, ...). > > - the private protocol between Weston and weston-desktop-shell > specifically. As we have chosen to let weston-desktop-shell client do > all the GUI drawing, and minimized windows will need some GUI (a task > bar button, a menu list of windows) to be able to get them back, we > need protocol to inform weston-desktop-shell about the windows so it > can draw the GUI. > > But these should not be complicated, once you understand how the basics > of a Wayland protocol work. And you don't need to have any complex > foreign surface passing protocol to get window thumbnails by hovering > the pointer over a taskbar button. Thumbnails can be added later, as it > does not concern the public protocol at all. We don't need even need to pull that complexity in in the first step. We can simply allow mod-tab to select minimized windows and unminiized if they're selected. K
Re: minimized and stick windows
Hello, I thought a bit about it and like to present my ideas. I mainly thought about it from the shell/compositor site when I like to minimize, maximize surfaces from keybindings, like in some window managers. For example the client can still request minimize, maximize, fullsrceen and toplevel actions, but now the compositor responds with an state_update event. The compositor can also send this state_update when the compositor likes change the window on it's own (like some task bar or compositor key bindings). The client can then save the state and act accordingly (like hiding same menus if maximized or fullscreen). diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 3bce022..e0f2c4a 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -811,6 +811,14 @@ + + +Minimize the surface. + +The compositor responds with state_update event. + + + Set a short title for the surface. @@ -867,6 +875,30 @@ + + + + + + + + + + + +Tells the surface which state is has on the output. + +This event is sent in respons to set_maximized, set_minimized or +set_fullscreen request to acknowledge the request. The client can update it +own state if it wants to keep track of it. + +The also compositor sends this event if itt wants the surface minimized or +maximized. For example by clicking on a task list item or compositor key +bindings for fullscreen. + + + + The popup_done event is sent out when a popup grab is broken, I don't know about multiple window applications and maybe missed some other use cases, but I hope this isn't too wrong of an idea. At least this should hopefully not break the protocol too much. Best Regards, Alexander Preisinger 2013/5/14 Kristian Høgsberg > On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen > wrote: > > On Mon, 13 May 2013 17:26:28 -0500 > > Jason Ekstrand wrote: > > > >> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli < > antogno...@gmail.com>wrote: > >> > >> > Hi Jason, > >> > > >> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand > >> > wrote: > >> > > Hi Rafael, > >> > > > >> > > > >> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli < > antogno...@gmail.com> > >> > > wrote: > >> > >> > >> > >> Hello, > >> > >> > >> > >> I've been looking the Weston code relative to maximized windows, > and > >> > >> it seems that the respective code for minimized windows wouldn't be > >> > >> hard to implement. > >> > >> > >> > >> The questions are: are there any plans to add it? Is there someone > >> > >> already working on it? If not, would it be OK if I start submitting > >> > >> patches to try to add support for this? > >> > > > >> > > > >> > > A month or two ago, Scott Morreau was working on it. However, his > work > >> > > never made into weston for a variety of reasons. Personally, I'm > glad to > >> > > see someone interested in working on it again because it's > something that > >> > > wayland will need eventually. > >> > > > >> > > The place to start on it is probably with the following e-mail and > the > >> > long > >> > > string of replies: > >> > > > >> > > > >> > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > >> > > > >> > > There was quite a bit of discussion about how to handle it from a > >> > protocol > >> > > level, but Scott never made an actual version 2. I'd suggest you > start > >> > by > >> > > reading the chain of e-mails (it goes into April, not just March). > There > >> > > were quite a few suggestions in there that could be incorporated. > >> > > Hopefully, you can pick through the e-mail discussion and figure > out what > >> > > the consensus was. It'd be good to have a pair of fresh eyes look > at it. > >> > > >> > Thanks for pointing that out. I just went through the chain of > >> > e-mails, but I don't think there was a consensus there. > >> > > >> > It also seems that the minimize implementation is a little more > >> > complex than just hiding surfaces and marking some flags. Which makes > >> > me not so comfortable doing an implementation without a consensus > >> > about what should be implemented, and with some orientation. > >> > > >> > That said, I'm not sure I'm really going to take this task. > >> > > >> > >> I didn't intend to scare you off. Honestly, I don't know for 100% > certain > >> how much weston machinery is needed to implement it. It would require > some > >> sort of set of flags to keep the compositor and shell plugin in sync. > That > >> said, I don't know if its quite as difficult as Scott made it sound. > >> > >> As far as direction goes, the first thing is to think through use-cases > and > >> settle on a protocol. Unfortunately, the discussion I linked you to > seemed > >> to go nowhere. However, a lot of that was Scott saying, "This is the > way I > >> want to do it and I'm n
Re: minimized and stick windows
On Wed, 15 May 2013 14:20:21 +0200 Alexander Preisinger wrote: > Hello, > > I thought a bit about it and like to present my ideas. > I mainly thought about it from the shell/compositor site when I like to > minimize, maximize surfaces from keybindings, like in some window managers. > > For example the client can still request minimize, maximize, fullsrceen and > toplevel actions, but now the compositor responds with an state_update > event. > The compositor can also send this state_update when the compositor likes > change the window on it's own (like some task bar or compositor key > bindings). > The client can then save the state and act accordingly (like hiding same > menus if maximized or fullscreen). > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 3bce022..e0f2c4a 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -811,6 +811,14 @@ > allow-null="true"/> > > > + > + > +Minimize the surface. > + > +The compositor responds with state_update event. > + > + > + > > > Set a short title for the surface. > @@ -867,6 +875,30 @@ > > > > + > + > + > + > + > + > + > + > + > + > + > +Tells the surface which state is has on the output. > + > +This event is sent in respons to set_maximized, set_minimized or > +set_fullscreen request to acknowledge the request. The client can > update it > +own state if it wants to keep track of it. > + > +The also compositor sends this event if itt wants the surface > minimized or > +maximized. For example by clicking on a task list item or compositor > key > +bindings for fullscreen. > + > + > + > + > > > The popup_done event is sent out when a popup grab is broken, > > > I don't know about multiple window applications and maybe missed some other > use cases, but I hope this isn't too wrong of an idea. At least this should > hopefully not break the protocol too much. If I understood right, here you have the client asking the compositor for permission, and then the compositor orders the client to be in a certain state and will compose it as such, regardless of what the client actually draws. This won't work, fixing the races it causes will complicate the protocol and cause roundtrips. The client draws its window, hence the client is in charge of how it looks, and the compositor cannot force that. Hence, it must be compositor proposing to the client that it should e.g. maximize. It the client does that at some point, perhaps first sending a few new frames since it was animating, the client will tell the compositor it will now go maximized, and then the very next frame it draws will be maximized. This avoids flicker. Minimize is a little special, since the client does not need to react specially for it to look right. For everything else it will need to. Actually, if you think about a multi-window application, minimize needs to work the same way, so that application can hide all relevant windows (but maybe not *all* windows). Deja vu, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
2013/5/15 Pekka Paalanen > On Wed, 15 May 2013 14:20:21 +0200 > Alexander Preisinger wrote: > > > Hello, > > > > I thought a bit about it and like to present my ideas. > > I mainly thought about it from the shell/compositor site when I like to > > minimize, maximize surfaces from keybindings, like in some window > managers. > > > > For example the client can still request minimize, maximize, fullsrceen > and > > toplevel actions, but now the compositor responds with an state_update > > event. > > The compositor can also send this state_update when the compositor likes > > change the window on it's own (like some task bar or compositor key > > bindings). > > The client can then save the state and act accordingly (like hiding same > > menus if maximized or fullscreen). > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 3bce022..e0f2c4a 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -811,6 +811,14 @@ > > > allow-null="true"/> > > > > > > + > > + > > +Minimize the surface. > > + > > +The compositor responds with state_update event. > > + > > + > > + > > > > > > Set a short title for the surface. > > @@ -867,6 +875,30 @@ > > > > > > > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > +Tells the surface which state is has on the output. > > + > > +This event is sent in respons to set_maximized, set_minimized or > > +set_fullscreen request to acknowledge the request. The client can > > update it > > +own state if it wants to keep track of it. > > + > > +The also compositor sends this event if itt wants the surface > > minimized or > > +maximized. For example by clicking on a task list item or compositor > > key > > +bindings for fullscreen. > > + > > + > > + > > + > > > > > > The popup_done event is sent out when a popup grab is broken, > > > > > > I don't know about multiple window applications and maybe missed some > other > > use cases, but I hope this isn't too wrong of an idea. At least this > should > > hopefully not break the protocol too much. > > If I understood right, here you have the client asking the compositor > for permission, and then the compositor orders the client to be in a > certain state and will compose it as such, regardless of what the client > actually draws. > > This won't work, fixing the races it causes will complicate the > protocol and cause roundtrips. > > The client draws its window, hence the client is in charge of how it > looks, and the compositor cannot force that. > > Hence, it must be compositor proposing to the client that it should > e.g. maximize. It the client does that at some point, perhaps first > sending a few new frames since it was animating, the client will tell > the compositor it will now go maximized, and then the very next frame > it draws will be maximized. This avoids flicker. > > Yes that seems logical. So the update_state should then be a request/suggest_state event? It seems I am tainted by using tiling window managers, where they sometimes forces the size. > Minimize is a little special, since the client does not need to react > specially for it to look right. For everything else it will need to. > Actually, if you think about a multi-window application, minimize needs > to work the same way, so that application can hide all relevant > windows (but maybe not *all* windows). > > My Idea is that the client gets notified per shell surface and the client can hide all windows (for example we want to minimize the main window) or just the requested/proposed window. I will try get some basic implementation done, maybe I can reuse soreaus code for this. > > Deja vu, > pq > Thank you for your time Best Regards. Alexander Preisinger ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Mon, May 13, 2013 at 06:14:46PM -0300, Rafael Antognolli wrote: > Hi Jason, > > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand wrote: > > Hi Rafael, > > > > > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli > > wrote: > >> > >> Hello, > >> > >> I've been looking the Weston code relative to maximized windows, and > >> it seems that the respective code for minimized windows wouldn't be > >> hard to implement. > >> > >> The questions are: are there any plans to add it? Is there someone > >> already working on it? If not, would it be OK if I start submitting > >> patches to try to add support for this? > > > > > > A month or two ago, Scott Morreau was working on it. However, his work > > never made into weston for a variety of reasons. Personally, I'm glad to > > see someone interested in working on it again because it's something that > > wayland will need eventually. > > > > The place to start on it is probably with the following e-mail and the long > > string of replies: > > > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > > > > There was quite a bit of discussion about how to handle it from a protocol > > level, but Scott never made an actual version 2. I'd suggest you start by > > reading the chain of e-mails (it goes into April, not just March). There > > were quite a few suggestions in there that could be incorporated. > > Hopefully, you can pick through the e-mail discussion and figure out what > > the consensus was. It'd be good to have a pair of fresh eyes look at it. > > Thanks for pointing that out. I just went through the chain of > e-mails, but I don't think there was a consensus there. > > It also seems that the minimize implementation is a little more > complex than just hiding surfaces and marking some flags. Which makes > me not so comfortable doing an implementation without a consensus > about what should be implemented, and with some orientation. > > That said, I'm not sure I'm really going to take this task. I agree that the thread is a little daunting and gets political/personal towards the end. But between Pekka, Jason and Bill I see concensus and I'll try to summarize here: - The server needs to be able to initiate state changes, but the client is in control. The server requests a state change but the client ultimately has to set the new state and provide a new buffer. In case of maximize and unmaximize, the client has to provide a new buffer before the state can change and in case of minimize, the client may want to hide other windows as well as it minimizes. - Discussion about whether states are orthogonal flags that the client sets or if the client just sets the current state. The distinction is whether the compositor knows the full set of states or only the effective state. For example, if you maximize a window and then minimize it, does the compositor know that it's maximized and minimized or only that it's currently minimized? I think the compositor needs to know all the state, so that it's possible to implement something like unmaximize while minimized. There's a catch: the current model (set_toplevel, set_fullscreen and set_maximized) doesn't work this way, these requests always set the current state, not a flag. I think we can fit those into the new mechanism: set_toplevel clears all states, set_maximized sets maximized and clears fullscreen, and set_fullscreen sets fullscreen. - Enum vs set_minimized. Do we add an enum with states and a set(state) request or do we add set_minimized etc? We only lack set_minimized currently, but we also need events to let the compositor initiate state changes, so we would have to add request_maximized/minimized events as well as request_unmaximized/unminimized. If we add an enum of states instead, we can add set and clear requests and request_set and request_clear events. Using an enum also lets us add sticky and always-on-top as enum values. - Visibility and frame events during minimized is orthogonal and up to the compositor. The compositor can keep sending frame events at the full frame rate or throttle the application down to a few frames per second for example. But the compositor can do that at any time, for example if the window is fully obscured by an opaque surface, there's really no interaction with being minimized. - Stacking is an orthogonal issue. Currently clients can't assume anything about their stacking order relative to other clients, so a compositor is free to unminimize surfaces to anywhere in the stack. - We've also talked about a request_close event that the compositor can use to ask a client to close its window. This useful for closing from a window list or from something like the GNOME Shell overview. I think this is straight forward, though not directly related to the state stuff here. If we turn this into protocol, I think it wi
Re: minimized and stick windows
Alexander Preisinger wrote: + Maybe "normal"? "toplevel" sounds like it is in the same layer as popup notifiers. +This event is sent in respons to set_maximized, set_minimized or +set_fullscreen request to acknowledge the request. The client can update it +own state if it wants to keep track of it. No. The client *has* to assume the requests work. Echoing these will just confuse clients and they will have to do tricks to distinguish these from real requests from the shell. Similar to the ugly things X clients have to do to distinguish real configure notifies from echoes. And set_fullscreen and set_maximize already have a response, which is a configure request for the size needed. +The also compositor sends this event if itt wants the surface minimized or +maximized. For example by clicking on a task list item or compositor key +bindings for fullscreen. Yes, this is what this event is for and should be it's only use. I think you are imagining that the shell can do something before it sends these events. It cannot, because only the client knows exactly what effect these have. Only it knows if other surfaces should be hidden, shown, raised, or resized. Only it knows the size of a toplevel surface (imagine it was shown maximized first, so the shell has never seen it un-maximized). If a client ignores these events then nothing happens. The client is mis-behaving but this is the way it has to be. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Pekka Paalanen wrote: Minimize is a little special, since the client does not need to react specially for it to look right. The client does have to react if there is a floating panel that also has to disappear. For example the floating shared toolbox with 2 main windows. It should only disappear when *both* main windows are minimized. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
> I agree that the thread is a little daunting and gets > political/personal towards the end. But between Pekka, Jason and Bill > I see concensus and I'll try to summarize here: > > - The server needs to be able to initiate state changes, but the >client is in control. The server requests a state change but the >client ultimately has to set the new state and provide a new >buffer. In case of maximize and unmaximize, the client has to >provide a new buffer before the state can change and in case of >minimize, the client may want to hide other windows as well as it >minimizes. > > - Discussion about whether states are orthogonal flags that the >client sets or if the client just sets the current state. The >distinction is whether the compositor knows the full set of states >or only the effective state. For example, if you maximize a window >and then minimize it, does the compositor know that it's maximized >and minimized or only that it's currently minimized? I think the >compositor needs to know all the state, so that it's possible to >implement something like unmaximize while minimized. > >There's a catch: the current model (set_toplevel, set_fullscreen >and set_maximized) doesn't work this way, these requests always set >the current state, not a flag. I think we can fit those into the >new mechanism: set_toplevel clears all states, set_maximized sets >maximized and clears fullscreen, and set_fullscreen sets fullscreen. > > - Enum vs set_minimized. Do we add an enum with states and a >set(state) request or do we add set_minimized etc? We only lack >set_minimized currently, but we also need events to let the >compositor initiate state changes, so we would have to add >request_maximized/minimized events as well as >request_unmaximized/unminimized. If we add an enum of states >instead, we can add set and clear requests and request_set and >request_clear events. > >Using an enum also lets us add sticky and always-on-top as enum >values. > > - Visibility and frame events during minimized is orthogonal and up >to the compositor. The compositor can keep sending frame events at >the full frame rate or throttle the application down to a few >frames per second for example. But the compositor can do that at >any time, for example if the window is fully obscured by an opaque >surface, there's really no interaction with being minimized. > > - Stacking is an orthogonal issue. Currently clients can't assume >anything about their stacking order relative to other clients, so a >compositor is free to unminimize surfaces to anywhere in the stack. > > - We've also talked about a request_close event that the compositor >can use to ask a client to close its window. This useful for >closing from a window list or from something like the GNOME Shell >overview. I think this is straight forward, though not directly >related to the state stuff here. > > If we turn this into protocol, I think it will look something like this: > > > ... > > > > This is a bitmask of capabilities this seat has; if a member is > set, then it is present on the seat. > > > > > > Arent we missing the fullscreen from the above enum? Also the rationale for me adding the default state (in the other thread) was that it would indicate to the compositor that it is the "normal" state of the the app i.e. when going from maximized/fullscreen to the default state the compositor could remember the last size and propose that to the client. > > > > To me the word 'set' implies that this will happen and in some cases the compositor might not honor this, so in a way it is a request. Perhaps 'request_state'? > > > > > This is a bit unclear to me. Does the compositor take some action after this request or is the state just cleared on the compositors side? It seems a bit open ended... if the client has set the state to say fullscreen and then clears it will the surface still stay fullscreen. > ... > > > > > > > > > > > > > > > > How does that look? Excellent ;) > > Kristian > > > -- > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > End of wayland-devel Digest, Vol 32, Issue 73 > * ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On May 15, 2013 9:37 PM, "Mikko Levonmaa" wrote: > > > I agree that the thread is a little daunting and gets > > political/personal towards the end. But between Pekka, Jason and Bill > > I see concensus and I'll try to summarize here: > > > > - The server needs to be able to initiate state changes, but the > >client is in control. The server requests a state change but the > >client ultimately has to set the new state and provide a new > >buffer. In case of maximize and unmaximize, the client has to > >provide a new buffer before the state can change and in case of > >minimize, the client may want to hide other windows as well as it > >minimizes. > > > > - Discussion about whether states are orthogonal flags that the > >client sets or if the client just sets the current state. The > >distinction is whether the compositor knows the full set of states > >or only the effective state. For example, if you maximize a window > >and then minimize it, does the compositor know that it's maximized > >and minimized or only that it's currently minimized? I think the > >compositor needs to know all the state, so that it's possible to > >implement something like unmaximize while minimized. > > > >There's a catch: the current model (set_toplevel, set_fullscreen > >and set_maximized) doesn't work this way, these requests always set > >the current state, not a flag. I think we can fit those into the > >new mechanism: set_toplevel clears all states, set_maximized sets > >maximized and clears fullscreen, and set_fullscreen sets fullscreen. > > > > - Enum vs set_minimized. Do we add an enum with states and a > >set(state) request or do we add set_minimized etc? We only lack > >set_minimized currently, but we also need events to let the > >compositor initiate state changes, so we would have to add > >request_maximized/minimized events as well as > >request_unmaximized/unminimized. If we add an enum of states > >instead, we can add set and clear requests and request_set and > >request_clear events. > > > >Using an enum also lets us add sticky and always-on-top as enum > >values. > > > > - Visibility and frame events during minimized is orthogonal and up > >to the compositor. The compositor can keep sending frame events at > >the full frame rate or throttle the application down to a few > >frames per second for example. But the compositor can do that at > >any time, for example if the window is fully obscured by an opaque > >surface, there's really no interaction with being minimized. > > > > - Stacking is an orthogonal issue. Currently clients can't assume > >anything about their stacking order relative to other clients, so a > >compositor is free to unminimize surfaces to anywhere in the stack. > > > > - We've also talked about a request_close event that the compositor > >can use to ask a client to close its window. This useful for > >closing from a window list or from something like the GNOME Shell > >overview. I think this is straight forward, though not directly > >related to the state stuff here. > > > > If we turn this into protocol, I think it will look something like this: > > > > > > > > ... > > > > > > > > This is a bitmask of capabilities this seat has; if a member is > > set, then it is present on the seat. > > > > > > > > > > > > > > Arent we missing the fullscreen from the above enum? Also the rationale > for me adding the default state (in the other thread) was that it would > indicate to the compositor that it is the "normal" state of the the app > i.e. when going from maximized/fullscreen to the default state the > compositor could remember the last size and propose that to the client. Fullscreen is a bit special as it requires other arguments (mode and output). You cant merely set it as a flag. It should probably be considered as a different mode all together. More specifically, the flags only apply to toplevel surfaces. (Maximized will require a little work to keep backwards compatibility.) > > > > > > > > > > > To me the word 'set' implies that this will happen and in some cases the > compositor might not honor this, so in a way it is a request. Perhaps > 'request_state'? The client is setting surface flags (perhaps "unset" would be better than "clear" below). Exactly what the compositor does will depend on a precedence order. Kristian didn't define it above but it shouldn't be too hard to do. That said, the order should be well documented. Why wouldn't the server respect the flags? Also, when this request is handled, the flag is set. The only strange thing the compositor can do is to do something unexpected with the flags. > > > > > > > > > > > > > This is a bit unclear to me. Does the compositor take some acti
Re: minimized and stick windows
Mikko Levonmaa wrote: i.e. when going from maximized/fullscreen to the default state the compositor could remember the last size and propose that to the client. The client has to know the default size: 1. It may have initially shown maximized. The compositor therefore has not seen it in normal state and does not know the size. 2. The state of the client may have changed while it was maximized such that it's normal size has changed. An actual example of a bug we have run into repeatedly on Windows and in Qt (though underlying X you can fix it) is that we want to save our window state in a file, and we want to save both the fact that it is maximized and what the un-maximized size is. This is not possible if only the compositor knows it. On Windows we are forced to blink a maximized window when created so that Windows sees the normal size and remembers it. On X a big kludge is done to get around Qt emulating the Windows bug. It would be nice if Wayland avoided this problem. So as I see it, if the user hits the "un-maximize" hot key: 1. The compositor sends a state_change event that turns off maximize 2. Client figures out it's un-maximized size, and configures the surface, drawing the new resized image. 3. Client sends the state_change request to tell the compositor that this new image is not maximized. 4. Client does a commit so the new size, image, and non-maximized state are all updated atomically. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, 15 May 2013 15:26:02 +0200 Alexander Preisinger wrote: > 2013/5/15 Pekka Paalanen > > > On Wed, 15 May 2013 14:20:21 +0200 > > Alexander Preisinger wrote: > > > > > Hello, > > > > > > I thought a bit about it and like to present my ideas. > > > I mainly thought about it from the shell/compositor site when I like to > > > minimize, maximize surfaces from keybindings, like in some window > > managers. > > > > > > For example the client can still request minimize, maximize, fullsrceen > > and > > > toplevel actions, but now the compositor responds with an state_update > > > event. > > > The compositor can also send this state_update when the compositor likes > > > change the window on it's own (like some task bar or compositor key > > > bindings). > > > The client can then save the state and act accordingly (like hiding same > > > menus if maximized or fullscreen). > > > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > > index 3bce022..e0f2c4a 100644 > > > --- a/protocol/wayland.xml > > > +++ b/protocol/wayland.xml > > > @@ -811,6 +811,14 @@ > > > > > allow-null="true"/> > > > > > > > > > + > > > + > > > +Minimize the surface. > > > + > > > +The compositor responds with state_update event. > > > + > > > + > > > + > > > > > > > > > Set a short title for the surface. > > > @@ -867,6 +875,30 @@ > > > > > > > > > > > > + > > > + > > > + > > > + > > > + > > > + > > > + > > > + > > > + > > > + > > > + > > > +Tells the surface which state is has on the output. > > > + > > > +This event is sent in respons to set_maximized, set_minimized or > > > +set_fullscreen request to acknowledge the request. The client can > > > update it > > > +own state if it wants to keep track of it. > > > + > > > +The also compositor sends this event if itt wants the surface > > > minimized or > > > +maximized. For example by clicking on a task list item or compositor > > > key > > > +bindings for fullscreen. > > > + > > > + > > > + > > > + > > > > > > > > > The popup_done event is sent out when a popup grab is broken, > > > > > > > > > I don't know about multiple window applications and maybe missed some > > other > > > use cases, but I hope this isn't too wrong of an idea. At least this > > should > > > hopefully not break the protocol too much. > > > > If I understood right, here you have the client asking the compositor > > for permission, and then the compositor orders the client to be in a > > certain state and will compose it as such, regardless of what the client > > actually draws. > > > > This won't work, fixing the races it causes will complicate the > > protocol and cause roundtrips. > > > > The client draws its window, hence the client is in charge of how it > > looks, and the compositor cannot force that. > > > > > Hence, it must be compositor proposing to the client that it should > > e.g. maximize. It the client does that at some point, perhaps first > > sending a few new frames since it was animating, the client will tell > > the compositor it will now go maximized, and then the very next frame > > it draws will be maximized. This avoids flicker. > > > > > Yes that seems logical. So the update_state should then be a > request/suggest_state event? Yup, something like that. > It seems I am tainted by using tiling window managers, where they sometimes > forces the size. You can never really force a size. You can tell a client with wl_shell_surface.geometry event, that this window should be made at most this size. The client can choose a smaller size, but should choose the largest size possible fitting into the suggested size. Well-behaving clients will do just that. If a client is not well-behaving, it will look like crap, and there's nothing to fix that. But note, that well-behaving does allow a smaller window than suggested, so you need to prepare for that in a tiling WM. The "never expose global coordinates" property does allow a tiling WM to deal gracefully with misbehaving clients, though. You can simply scale the surface down to the size you really wanted, and the client will continue working as if nothing strange happened. Only that one client will look bad, but it still completely shows, and will not obscure other windows. > > Minimize is a little special, since the client does not need to react > > specially for it to look right. For everything else it will need to. > > Actually, if you think about a multi-window application, minimize needs > > to work the same way, so that application can hide all relevant > > windows (but maybe not *all* windows). > > > > > My Idea is that the client gets notified per shell surface and the client > can hide all windows > (for example we want to minimize the main window) or just the > requested/proposed window. Yeah. Thanks, pq ___
Re: minimized and stick windows
On Wed, 15 May 2013 12:27:17 -0700 Bill Spitzak wrote: > Pekka Paalanen wrote: > > > Minimize is a little special, since the client does not need to react > > specially for it to look right. > > The client does have to react if there is a floating panel that also has > to disappear. > > For example the floating shared toolbox with 2 main windows. It should > only disappear when *both* main windows are minimized. You very conventiently removed my next sentence, where I already took this into account. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Pekka Paalanen wrote: For example the floating shared toolbox with 2 main windows. It should only disappear when *both* main windows are minimized. You very conventiently removed my next sentence, where I already took this into account. - pq Sorry, obviously I did not read very carefully: > Actually, if you think about a multi-window application, minimize needs to work the same way, so that application can hide all relevant windows (but maybe not *all* windows). I think also it is important to note that the compositor cannot even hide the window the minimize is for. This is because that hide should be in sync with the hiding of other windows, so the client should do all of them. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak wrote: > > > Pekka Paalanen wrote: > >>> For example the floating shared toolbox with 2 main windows. It should >>> only disappear when *both* main windows are minimized. >> >> >> You very conventiently removed my next sentence, where I already took >> this into account. >> - pq > > > Sorry, obviously I did not read very carefully: > > >> Actually, if you think about a multi-window application, minimize needs to >> work the same way, so that application can hide all relevant windows (but >> maybe not *all* windows). > > I think also it is important to note that the compositor cannot even hide > the window the minimize is for. This is because that hide should be in sync > with the hiding of other windows, so the client should do all of them. OK, so since what Khristian proposed was this: https://github.com/antognolli/wayland/commit/a94eb97fdf49c6e06b0b4e94f4b8c840602442db Can I start from it? It seems to me that it allows to cover the most important part mentioned here, which is the fact that weston will only send the minimize events and clients should have control over this. Regards, -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Tue, May 28, 2013 at 3:10 PM, Rafael Antognolli wrote: > On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak wrote: > > > > > > Pekka Paalanen wrote: > > > >>> For example the floating shared toolbox with 2 main windows. It should > >>> only disappear when *both* main windows are minimized. > >> > >> > >> You very conventiently removed my next sentence, where I already took > >> this into account. > >> - pq > > > > > > Sorry, obviously I did not read very carefully: > > > > > >> Actually, if you think about a multi-window application, minimize needs > to > >> work the same way, so that application can hide all relevant windows > (but > >> maybe not *all* windows). > > > > I think also it is important to note that the compositor cannot even hide > > the window the minimize is for. This is because that hide should be in > sync > > with the hiding of other windows, so the client should do all of them. > > OK, so since what Khristian proposed was this: > > > https://github.com/antognolli/wayland/commit/a94eb97fdf49c6e06b0b4e94f4b8c840602442db > > Can I start from it? It seems to me that it allows to cover the most > important part mentioned here, which is the fact that weston will only > send the minimize events and clients should have control over this. > Rafael, That looks like a good starting point to me. I'm not a huge fan of the names of things but those can be debated/changed any time before we release. I'd say the basics look good and you might as well go ahead and start implementing. --Jason Ekstrand ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Tue, May 28, 2013 at 1:10 PM, Rafael Antognolli wrote: > On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak wrote: >> >> >> Pekka Paalanen wrote: >> For example the floating shared toolbox with 2 main windows. It should only disappear when *both* main windows are minimized. >>> >>> >>> You very conventiently removed my next sentence, where I already took >>> this into account. >>> - pq >> >> >> Sorry, obviously I did not read very carefully: >> >> >>> Actually, if you think about a multi-window application, minimize needs to >>> work the same way, so that application can hide all relevant windows (but >>> maybe not *all* windows). >> >> I think also it is important to note that the compositor cannot even hide >> the window the minimize is for. This is because that hide should be in sync >> with the hiding of other windows, so the client should do all of them. > > OK, so since what Khristian proposed was this: > > https://github.com/antognolli/wayland/commit/a94eb97fdf49c6e06b0b4e94f4b8c840602442db > > Can I start from it? It seems to me that it allows to cover the most > important part mentioned here, which is the fact that weston will only > send the minimize events and clients should have control over this. Looks fine, putting some code behind all this talk would be very welcome. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Thu, Jun 6, 2013 at 3:50 PM, Kristian Høgsberg wrote: > On Tue, May 28, 2013 at 1:10 PM, Rafael Antognolli > wrote: >> On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak wrote: >>> >>> >>> Pekka Paalanen wrote: >>> > For example the floating shared toolbox with 2 main windows. It should > only disappear when *both* main windows are minimized. You very conventiently removed my next sentence, where I already took this into account. - pq >>> >>> >>> Sorry, obviously I did not read very carefully: >>> >>> Actually, if you think about a multi-window application, minimize needs to work the same way, so that application can hide all relevant windows (but maybe not *all* windows). >>> >>> I think also it is important to note that the compositor cannot even hide >>> the window the minimize is for. This is because that hide should be in sync >>> with the hiding of other windows, so the client should do all of them. >> >> OK, so since what Khristian proposed was this: >> >> https://github.com/antognolli/wayland/commit/a94eb97fdf49c6e06b0b4e94f4b8c840602442db >> >> Can I start from it? It seems to me that it allows to cover the most >> important part mentioned here, which is the fact that weston will only >> send the minimize events and clients should have control over this. > > Looks fine, putting some code behind all this talk would be very welcome. Starting code here. Following are some comments. https://github.com/antognolli/wayland/commits/minimize https://github.com/antognolli/weston/commits/minimize I didn't add code for the events that ask state changes from the compositor, neither any code related to minimize yet. I tried to first change the current maximized surface type to be just another state, as suggested at some point in this thread. So, it ended up very hackish IMHO. In order to do that, when the surface type is set to maximized, I change it to set the maximized state instead, which is currently working correctly (from my tests). But when the surface type is set to anything else than maximized, I have to unset the maximized state, to keep the same behavior as before these changes. I need to know if I should follow this path, in which case I'll improve the above code (some refactory can take place), or if we should use another approach. Maybe the minimized state should be in fact another surface type, and we would only have states for things like always_on_top and sticky (and any other that may come next). Or maybe we can keep the same surface types that we had already, and just add minimized as a state. What are your opinions about this? PS: I'm sending the code as links to github since it's not a request to integrate it yet, but I can send it to the list as attached patches if it's preferable. PS2: I added the surface states as a bitmask, but since I didn't see something like that in the rest of the code, I can also change it to a simple enum. Regards, -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Tue, 11 Jun 2013 16:31:59 -0300 Rafael Antognolli wrote: > Starting code here. Following are some comments. > > https://github.com/antognolli/wayland/commits/minimize > https://github.com/antognolli/weston/commits/minimize > > I didn't add code for the events that ask state changes from the > compositor, neither any code related to minimize yet. I tried to first > change the current maximized surface type to be just another state, as > suggested at some point in this thread. > > So, it ended up very hackish IMHO. In order to do that, when the > surface type is set to maximized, I change it to set the maximized > state instead, which is currently working correctly (from my tests). > But when the surface type is set to anything else than maximized, I > have to unset the maximized state, to keep the same behavior as before > these changes. > > I need to know if I should follow this path, in which case I'll > improve the above code (some refactory can take place), or if we > should use another approach. Maybe the minimized state should be in > fact another surface type, and we would only have states for things > like always_on_top and sticky (and any other that may come next). Or > maybe we can keep the same surface types that we had already, and just > add minimized as a state. > > What are your opinions about this? To get the big picture, let me reiterate the surface classification as a whole, the way I see it. Surface roles, exclusive: - cursor - drag icon - shell surface Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Top-level shell surface states, each more or less toggleable on its own: - maximized - fullscreen - minimized - sticky - always-on-top or some equivalent layer thing ... Does this make sense? That is, only a top-level surface, which we should probably be calling as an application window, can be maximized etc., and I think the discussion was that it can be many things at once, like maximized and minimized. I don't think the states make sense as types, I would prefer the above hierarchy. A shell surface can only have one type at a time, but the states are not that restricted. It gives a nice tree-like hierarchy, instead of a directed graph where several surface types can have the same states. The tiling-WM developers would be concerned only about the top-level shell surface states, and could hopefully support all the shell surface types, which should make the difference between floating and tiling WMs more manageable. Protocol-wise, this means that requests set_maximized and set_fullscreen would be deprecated as is, and replaced with the state setting request. Request set_toplevel would deprecate the part of its behaviour where it changes a surface into normal state. We cannot remove the deprecated functionality, I believe, so it must be kept working, and just plumbed into the new kind of internal state change machinery inside weston. However, it's not that simple. Some states need parameters. Maximized needs an output, and fullscreen a few things more. Always-on-top equivalent might want a layer number or something. Therefore I'm not sure a single set_state request will work. Anyway, that's just what came to my mind now. I don't recall any of the earlier discussions anymore, maybe there were solutions to some of these issues, maybe not. Did we ever discuss the possiblity of fullscreen being a special kind of maximized, btw? If you look at the state list above, everything is orthogonal (toggleable independently) except maximized vs. fullscreen. This is just as a concept, how it maps into protocol is a different matter. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On 12/06/2013 09:57, Pekka Paalanen wrote:
To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.
Surface roles, exclusive:
- cursor
- drag icon
- shell surface
Each role is an interface then? Simple and efficient, I love it.
Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)
Transcient is for dialog (modal?) boxes, isn’t it?
Each type is a one-shot request on a new created surface. Again, simple
and efficient, love it too.
It may be a bit more clear, see below.
Top-level shell surface states, each more or less toggleable on its own:
- maximized
- fullscreen
- minimized
- sticky
- always-on-top or some equivalent layer thing
...
Does this make sense?
Yes.
That is, only a top-level surface, which we should probably be calling
as an application window, can be maximized etc., and I think the
discussion was that it can be many things at once, like maximized and
minimized.
Right, it is useful and not that hard to implement.
I don't think the states make sense as types, I would prefer the above
hierarchy. A shell surface can only have one type at a time, but the
states are not that restricted. It gives a nice tree-like hierarchy,
instead of a directed graph where several surface types can have the
same states. The tiling-WM developers would be concerned only about the
top-level shell surface states, and could hopefully support all the
shell surface types, which should make the difference between floating
and tiling WMs more manageable.
I agree.
Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.
We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.
However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.
At protocol level, we may be better using new interfaces.
wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a
transcient one
— get_popup(wl_shell_toplevel_surface): returns a popup surface
That would duplicate some requests between the three interfaces (or
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping
wl_shell_surface around, as we have to maintain a compatibility struct
in the compositor, but that would be a simple struct { type; union {
toplevel; transcient; popup; }; }.
That would allow to extend the configure event in a nice fashion, that
tiling WM will love (e.g. for decorations).
Anyway, that's just what came to my mind now. I don't recall any of the
earlier discussions anymore, maybe there were solutions to some of
these issues, maybe not.
Did we ever discuss the possiblity of fullscreen being a special kind
of maximized, btw? If you look at the state list above, everything is
orthogonal (toggleable independently) except maximized vs. fullscreen.
This is just as a concept, how it maps into protocol is a different
matter.
Fullscreen, especially for games, is a completely different thing (e.g.
modesetting). We can have two cases here: “basic” fullscreen, which is
just maximize with panel removed (and the app will use the normal
decoration mechanism here, no fullscreen state), and plain fullscreen,
which would be another surface type.
I *think* most apps (games) already have heavy switching, so destroying
and creating a new surface should not be a problem here, imo.
Cheers,
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, 12 Jun 2013 10:23:33 +0200
sardemff7+wayl...@sardemff7.net wrote:
> On 12/06/2013 09:57, Pekka Paalanen wrote:
> > To get the big picture, let me reiterate the surface classification as
> > a whole, the way I see it.
> >
> > Surface roles, exclusive:
> > - cursor
> > - drag icon
> > - shell surface
>
> Each role is an interface then? Simple and efficient, I love it.
No, a role is just a concept. In protocol it is currently assigned by
passing the wl_surface as an argument for a specific request, that
assigns the role.
Only shell surface has a new interface associated, IIRC.
> > Shell surface types, exclusive:
> > - top-level
> > - transient (umm, what was this for, again?)
> > - popup (menu?)
>
> Transcient is for dialog (modal?) boxes, isn’t it?
Tooltips and alike, rather.
> Each type is a one-shot request on a new created surface. Again, simple
> and efficient, love it too.
> It may be a bit more clear, see below.
>
> > Top-level shell surface states, each more or less toggleable on its own:
> > - maximized
> > - fullscreen
> > - minimized
> > - sticky
> > - always-on-top or some equivalent layer thing
> > ...
>
> > Does this make sense?
>
> Yes.
>
>
> > That is, only a top-level surface, which we should probably be calling
> > as an application window, can be maximized etc., and I think the
> > discussion was that it can be many things at once, like maximized and
> > minimized.
>
> Right, it is useful and not that hard to implement.
>
>
> > I don't think the states make sense as types, I would prefer the above
> > hierarchy. A shell surface can only have one type at a time, but the
> > states are not that restricted. It gives a nice tree-like hierarchy,
> > instead of a directed graph where several surface types can have the
> > same states. The tiling-WM developers would be concerned only about the
> > top-level shell surface states, and could hopefully support all the
> > shell surface types, which should make the difference between floating
> > and tiling WMs more manageable.
>
> I agree.
>
>
> > Protocol-wise, this means that requests set_maximized and
> > set_fullscreen would be deprecated as is, and replaced with the state
> > setting request. Request set_toplevel would deprecate the part of its
> > behaviour where it changes a surface into normal state.
> >
> > We cannot remove the deprecated functionality, I believe, so it must be
> > kept working, and just plumbed into the new kind of internal state
> > change machinery inside weston.
> >
> > However, it's not that simple. Some states need parameters. Maximized
> > needs an output, and fullscreen a few things more. Always-on-top
> > equivalent might want a layer number or something. Therefore I'm not
> > sure a single set_state request will work.
>
> At protocol level, we may be better using new interfaces.
>
> wl_shell will gain three requests:
> — get_toplevel_surface(class, title): returns a new
> wl_shell_toplevel_surface
> — get_transcient_surface(wl_shell_toplevel_surface): returns a
> transcient one
> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>
> That would duplicate some requests between the three interfaces (or
> maybe two, if transcient and popup can share one).
> Backward-compatibility would be both easier and harder than keeping
> wl_shell_surface around, as we have to maintain a compatibility struct
> in the compositor, but that would be a simple struct { type; union {
> toplevel; transcient; popup; }; }.
>
> That would allow to extend the configure event in a nice fashion, that
> tiling WM will love (e.g. for decorations).
That is certainly a novel suggestion. I wonder what toolkit authors
would think.
Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.
Cheers,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On 12/06/2013 11:18, Pekka Paalanen wrote:
On Wed, 12 Jun 2013 10:23:33 +0200
sardemff7+wayl...@sardemff7.net wrote:
On 12/06/2013 09:57, Pekka Paalanen wrote:
To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.
Surface roles, exclusive:
- cursor
- drag icon
- shell surface
Each role is an interface then? Simple and efficient, I love it.
No, a role is just a concept. In protocol it is currently assigned by
passing the wl_surface as an argument for a specific request, that
assigns the role.
Only shell surface has a new interface associated, IIRC.
That’s fine: if the role is complex enough, put it in an interface.
Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)
Transcient is for dialog (modal?) boxes, isn’t it?
Tooltips and alike, rather.
Ok, so we should add something here for modal dialogs.
[snip]
Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.
We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.
However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.
At protocol level, we may be better using new interfaces.
wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a
transcient one
— get_popup(wl_shell_toplevel_surface): returns a popup surface
That would duplicate some requests between the three interfaces (or
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping
wl_shell_surface around, as we have to maintain a compatibility struct
in the compositor, but that would be a simple struct { type; union {
toplevel; transcient; popup; }; }.
That would allow to extend the configure event in a nice fashion, that
tiling WM will love (e.g. for decorations).
That is certainly a novel suggestion. I wonder what toolkit authors
would think.
I would probably provide patches for GTK+ at least, to test the stuff,
and the old interface (less powerful) would still be there for a while.
Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.
Sorry. ^^'
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 5:23 AM, wrote:
> On 12/06/2013 09:57, Pekka Paalanen wrote:
>>
>> To get the big picture, let me reiterate the surface classification as
>> a whole, the way I see it.
>>
>> Surface roles, exclusive:
>> - cursor
>> - drag icon
>> - shell surface
>
>
> Each role is an interface then? Simple and efficient, I love it.
>
>
>
>> Shell surface types, exclusive:
>> - top-level
>> - transient (umm, what was this for, again?)
>> - popup (menu?)
>
>
> Transcient is for dialog (modal?) boxes, isn’t it?
> Each type is a one-shot request on a new created surface. Again, simple and
> efficient, love it too.
> It may be a bit more clear, see below.
>
>
>> Top-level shell surface states, each more or less toggleable on its own:
>> - maximized
>> - fullscreen
>> - minimized
>> - sticky
>> - always-on-top or some equivalent layer thing
>> ...
>
>
>> Does this make sense?
>
>
> Yes.
>
>
>
>> That is, only a top-level surface, which we should probably be calling
>> as an application window, can be maximized etc., and I think the
>> discussion was that it can be many things at once, like maximized and
>> minimized.
>
>
> Right, it is useful and not that hard to implement.
>
>
>
>> I don't think the states make sense as types, I would prefer the above
>> hierarchy. A shell surface can only have one type at a time, but the
>> states are not that restricted. It gives a nice tree-like hierarchy,
>> instead of a directed graph where several surface types can have the
>> same states. The tiling-WM developers would be concerned only about the
>> top-level shell surface states, and could hopefully support all the
>> shell surface types, which should make the difference between floating
>> and tiling WMs more manageable.
>
>
> I agree.
>
>
>
>> Protocol-wise, this means that requests set_maximized and
>> set_fullscreen would be deprecated as is, and replaced with the state
>> setting request. Request set_toplevel would deprecate the part of its
>> behaviour where it changes a surface into normal state.
>>
>> We cannot remove the deprecated functionality, I believe, so it must be
>> kept working, and just plumbed into the new kind of internal state
>> change machinery inside weston.
>>
>> However, it's not that simple. Some states need parameters. Maximized
>> needs an output, and fullscreen a few things more. Always-on-top
>> equivalent might want a layer number or something. Therefore I'm not
>> sure a single set_state request will work.
>
>
> At protocol level, we may be better using new interfaces.
>
> wl_shell will gain three requests:
> — get_toplevel_surface(class, title): returns a new
> wl_shell_toplevel_surface
> — get_transcient_surface(wl_shell_toplevel_surface): returns a transcient
> one
> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>
> That would duplicate some requests between the three interfaces (or maybe
> two, if transcient and popup can share one).
> Backward-compatibility would be both easier and harder than keeping
> wl_shell_surface around, as we have to maintain a compatibility struct in
> the compositor, but that would be a simple struct { type; union { toplevel;
> transcient; popup; }; }.
>
> That would allow to extend the configure event in a nice fashion, that
> tiling WM will love (e.g. for decorations).
>
>
>> Anyway, that's just what came to my mind now. I don't recall any of the
>> earlier discussions anymore, maybe there were solutions to some of
>> these issues, maybe not.
>>
>> Did we ever discuss the possiblity of fullscreen being a special kind
>> of maximized, btw? If you look at the state list above, everything is
>> orthogonal (toggleable independently) except maximized vs. fullscreen.
>> This is just as a concept, how it maps into protocol is a different
>> matter.
>
>
> Fullscreen, especially for games, is a completely different thing (e.g.
> modesetting). We can have two cases here: “basic” fullscreen, which is just
> maximize with panel removed (and the app will use the normal decoration
> mechanism here, no fullscreen state), and plain fullscreen, which would be
> another surface type.
> I *think* most apps (games) already have heavy switching, so destroying and
> creating a new surface should not be a problem here, imo.
If I'm not wrong, in the previous discussion we also discussed about
the possibility of leaving fullscreen as a shell surface type itself.
Though I don't have strong opinion about this, just trying to leave
another possibility open.
--
Rafael Antognolli
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 6:25 AM, wrote:
> On 12/06/2013 11:18, Pekka Paalanen wrote:
>>
>> On Wed, 12 Jun 2013 10:23:33 +0200
>> sardemff7+wayl...@sardemff7.net wrote:
>>
>>> On 12/06/2013 09:57, Pekka Paalanen wrote:
To get the big picture, let me reiterate the surface classification as
a whole, the way I see it.
Surface roles, exclusive:
- cursor
- drag icon
- shell surface
>>>
>>>
>>> Each role is an interface then? Simple and efficient, I love it.
>>
>>
>> No, a role is just a concept. In protocol it is currently assigned by
>> passing the wl_surface as an argument for a specific request, that
>> assigns the role.
>>
>> Only shell surface has a new interface associated, IIRC.
>
>
> That’s fine: if the role is complex enough, put it in an interface.
>
>
>
Shell surface types, exclusive:
- top-level
- transient (umm, what was this for, again?)
- popup (menu?)
>>>
>>>
>>> Transcient is for dialog (modal?) boxes, isn’t it?
>>
>>
>> Tooltips and alike, rather.
>
>
> Ok, so we should add something here for modal dialogs.
>
>
> [snip]
>
Protocol-wise, this means that requests set_maximized and
set_fullscreen would be deprecated as is, and replaced with the state
setting request. Request set_toplevel would deprecate the part of its
behaviour where it changes a surface into normal state.
We cannot remove the deprecated functionality, I believe, so it must be
kept working, and just plumbed into the new kind of internal state
change machinery inside weston.
However, it's not that simple. Some states need parameters. Maximized
needs an output, and fullscreen a few things more. Always-on-top
equivalent might want a layer number or something. Therefore I'm not
sure a single set_state request will work.
>>>
>>>
>>> At protocol level, we may be better using new interfaces.
>>>
>>> wl_shell will gain three requests:
>>> — get_toplevel_surface(class, title): returns a new
>>> wl_shell_toplevel_surface
>>> — get_transcient_surface(wl_shell_toplevel_surface): returns a
>>> transcient one
>>> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>>>
>>> That would duplicate some requests between the three interfaces (or
>>> maybe two, if transcient and popup can share one).
>>> Backward-compatibility would be both easier and harder than keeping
>>> wl_shell_surface around, as we have to maintain a compatibility struct
>>> in the compositor, but that would be a simple struct { type; union {
>>> toplevel; transcient; popup; }; }.
>>>
>>> That would allow to extend the configure event in a nice fashion, that
>>> tiling WM will love (e.g. for decorations).
>>
>>
>> That is certainly a novel suggestion. I wonder what toolkit authors
>> would think.
>
>
> I would probably provide patches for GTK+ at least, to test the stuff, and
> the old interface (less powerful) would still be there for a while.
For EFL we are just waiting for the new API and implementation (which
I hope to actually work on it). The idea is to use the new interface
ASAP, but the already released versions would keep the old one, I
guess.
--
Rafael Antognolli
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 5:23 AM, wrote:
> On 12/06/2013 09:57, Pekka Paalanen wrote:
>>
>> To get the big picture, let me reiterate the surface classification as
>> a whole, the way I see it.
>>
>> Surface roles, exclusive:
>> - cursor
>> - drag icon
>> - shell surface
>
>
> Each role is an interface then? Simple and efficient, I love it.
>
>
>
>> Shell surface types, exclusive:
>> - top-level
>> - transient (umm, what was this for, again?)
>> - popup (menu?)
>
>
> Transcient is for dialog (modal?) boxes, isn’t it?
> Each type is a one-shot request on a new created surface. Again, simple and
> efficient, love it too.
> It may be a bit more clear, see below.
>
>
>> Top-level shell surface states, each more or less toggleable on its own:
>> - maximized
>> - fullscreen
>> - minimized
>> - sticky
>> - always-on-top or some equivalent layer thing
>> ...
>
>
>> Does this make sense?
>
>
> Yes.
>
>
>
>> That is, only a top-level surface, which we should probably be calling
>> as an application window, can be maximized etc., and I think the
>> discussion was that it can be many things at once, like maximized and
>> minimized.
>
>
> Right, it is useful and not that hard to implement.
>
>
>
>> I don't think the states make sense as types, I would prefer the above
>> hierarchy. A shell surface can only have one type at a time, but the
>> states are not that restricted. It gives a nice tree-like hierarchy,
>> instead of a directed graph where several surface types can have the
>> same states. The tiling-WM developers would be concerned only about the
>> top-level shell surface states, and could hopefully support all the
>> shell surface types, which should make the difference between floating
>> and tiling WMs more manageable.
>
>
> I agree.
>
>
>
>> Protocol-wise, this means that requests set_maximized and
>> set_fullscreen would be deprecated as is, and replaced with the state
>> setting request. Request set_toplevel would deprecate the part of its
>> behaviour where it changes a surface into normal state.
>>
>> We cannot remove the deprecated functionality, I believe, so it must be
>> kept working, and just plumbed into the new kind of internal state
>> change machinery inside weston.
>>
>> However, it's not that simple. Some states need parameters. Maximized
>> needs an output, and fullscreen a few things more. Always-on-top
>> equivalent might want a layer number or something. Therefore I'm not
>> sure a single set_state request will work.
>
>
> At protocol level, we may be better using new interfaces.
>
> wl_shell will gain three requests:
> — get_toplevel_surface(class, title): returns a new
> wl_shell_toplevel_surface
> — get_transcient_surface(wl_shell_toplevel_surface): returns a transcient
> one
> — get_popup(wl_shell_toplevel_surface): returns a popup surface
>
> That would duplicate some requests between the three interfaces (or maybe
> two, if transcient and popup can share one).
> Backward-compatibility would be both easier and harder than keeping
> wl_shell_surface around, as we have to maintain a compatibility struct in
> the compositor, but that would be a simple struct { type; union { toplevel;
> transcient; popup; }; }.
>
> That would allow to extend the configure event in a nice fashion, that
> tiling WM will love (e.g. for decorations).
>
Hmm... I'm still trying to understand this part, but are these calls
used to create the shell surfaces?
I also don't get exactly what would be the approach for passing
parameters to the "state set" calls. Would we have a custom data field
on the state_set call, or have specialized state set functions, each
with its own set of parameters, like state_maximized_set,
state_minimized_set, etc?
I'll try to summarize things here:
https://github.com/antognolli/wayland/wiki/Surface-States
Feel free to edit it if you want, I think that it's open to anyone to edit.
Regards,
--
Rafael Antognolli
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Transcient is for dialog (modal?) boxes, isn’t it? It means "this window stays above another one". Transient cannot be a type, but instead a state of a surface. It has to be done by setting a "parent surface" which means that the compositor keeps the surface above the parent. It does not imply anything else, in particular the client decides whether either surface is currently visible. The client has to be able to arbitrarily rearrange the parent pointers. This means it can set them to null (since otherwise it is not possible to get all rearrangements if the compositor rejects any attempts that make a loop). Therefore a "transient surface" can become a "main surface" and thus they must be the same object. This is a requirement so that non-trivial clients can be written that are not forced to blink the transient windows to change their parenting. Popups are also transient windows (and thus normal windows) but they have some effects on event delivery when they are first mapped. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 4:39 PM, Bill Spitzak wrote: > >>> Shell surface types, exclusive: >>> - top-level >>> - transient (umm, what was this for, again?) >>> - popup (menu?) >> >> >> Transcient is for dialog (modal?) boxes, isn’t it? > > > It means "this window stays above another one". > > Transient cannot be a type, but instead a state of a surface. It has to be > done by setting a "parent surface" which means that the compositor keeps the > surface above the parent. It does not imply anything else, in particular the > client decides whether either surface is currently visible. > > The client has to be able to arbitrarily rearrange the parent pointers. This > means it can set them to null (since otherwise it is not possible to get all > rearrangements if the compositor rejects any attempts that make a loop). > Therefore a "transient surface" can become a "main surface" and thus they > must be the same object. In this case, it's the "transient" state could be set/unset on surfaces that have a parent. However, if the surface has its parent set to NULL, the "transient" state must be automatically unset too, otherwise we would have an inconsistent state. Is this correct? > This is a requirement so that non-trivial clients can be written that are > not forced to blink the transient windows to change their parenting. > > Popups are also transient windows (and thus normal windows) but they have > some effects on event delivery when they are first mapped. So this would be a different state, that has the "transient" state being set as a requirement, or would it be a flag passed to the "transient" state when setting it? (I think the latter makes more sense to me). -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, Jun 12, 2013 at 7:39 PM, Rafael Antognolli wrote: > On Wed, Jun 12, 2013 at 4:39 PM, Bill Spitzak wrote: >> Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) >>> >>> >>> Transcient is for dialog (modal?) boxes, isn’t it? >> >> >> It means "this window stays above another one". >> >> Transient cannot be a type, but instead a state of a surface. It has to be >> done by setting a "parent surface" which means that the compositor keeps the >> surface above the parent. It does not imply anything else, in particular the >> client decides whether either surface is currently visible. >> >> The client has to be able to arbitrarily rearrange the parent pointers. This >> means it can set them to null (since otherwise it is not possible to get all >> rearrangements if the compositor rejects any attempts that make a loop). >> Therefore a "transient surface" can become a "main surface" and thus they >> must be the same object. > > In this case, it's the "transient" state could be set/unset on > surfaces that have a parent. However, if the surface has its parent > set to NULL, the "transient" state must be automatically unset too, > otherwise we would have an inconsistent state. Is this correct? > >> This is a requirement so that non-trivial clients can be written that are >> not forced to blink the transient windows to change their parenting. >> >> Popups are also transient windows (and thus normal windows) but they have >> some effects on event delivery when they are first mapped. > > So this would be a different state, that has the "transient" state > being set as a requirement, or would it be a flag passed to the > "transient" state when setting it? (I think the latter makes more > sense to me). > > -- > Rafael Antognolli I've just updated the proposal, considering my last statement. Take a look at it and see if it fits your suggestion. This lets us with 2 surface types (toplevel and fullscreen), and 5 states (maximized, minimized, sticky, always_on_top and transient) and their respective parameters. https://github.com/antognolli/wayland/wiki/Surface-States -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
Rafael Antognolli wrote: Rafael Antognolli I've just updated the proposal, considering my last statement. Take a look at it and see if it fits your suggestion. This lets us with 2 surface types (toplevel and fullscreen), and 5 states (maximized, minimized, sticky, always_on_top and transient) and their respective parameters. https://github.com/antognolli/wayland/wiki/Surface-States Possibly, if setting the "transient" state requires also sending the parent as a parameter, and clearing it is how you set it to null? But you need to solve your question about how to give parameters when setting states. I personally feel this api and the subwindow api should be merged as they are extremely similar. The only difference is that the compositor is allowed to insert other surfaces between the transient window and it's parent, but not subwindows and their parent. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On 12/06/2013 21:39, Bill Spitzak wrote: Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Transcient is for dialog (modal?) boxes, isn’t it? It means "this window stays above another one". Transient cannot be a type, but instead a state of a surface. It has to be done by setting a "parent surface" which means that the compositor keeps the surface above the parent. It does not imply anything else, in particular the client decides whether either surface is currently visible. It can be a type as long as we allow type switching. Regarding the types we more or less agreed on already, thas sounds sensible to me. The client has to be able to arbitrarily rearrange the parent pointers. This means it can set them to null (since otherwise it is not possible to get all rearrangements if the compositor rejects any attempts that make a loop). Therefore a "transient surface" can become a "main surface" and thus they must be the same object. This is a requirement so that non-trivial clients can be written that are not forced to blink the transient windows to change their parenting. Do you have a use case for this scenario ? There are probably some I cannot see, but maybe could we solve them another way. Popups are also transient windows (and thus normal windows) but they have some effects on event delivery when they are first mapped. Same question, do you have a use case for a popup surface that you would reparent? For our current use case (menus, do we have another one?) this is unlikely (afaict, I am not a toolkit guy). Thanks, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, 12 Jun 2013 18:31:17 -0700 Bill Spitzak wrote: > Rafael Antognolli wrote: > > >> Rafael Antognolli > > > > I've just updated the proposal, considering my last statement. Take > > a look at it and see if it fits your suggestion. > > > > This lets us with 2 surface types (toplevel and fullscreen), and 5 > > states (maximized, minimized, sticky, always_on_top and transient) > > and their respective parameters. > > > > https://github.com/antognolli/wayland/wiki/Surface-States > > Possibly, if setting the "transient" state requires also sending the > parent as a parameter, and clearing it is how you set it to null? But > you need to solve your question about how to give parameters when > setting states. > > I personally feel this api and the subwindow api should be merged as > they are extremely similar. The only difference is that the > compositor is allowed to insert other surfaces between the transient > window and it's parent, but not subwindows and their parent. There is no other subwindow API than what the wl_shell offers, i.e. precisely set_transient and friends. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
sardemff7+wayl...@sardemff7.net wrote: This is a requirement so that non-trivial clients can be written that are not forced to blink the transient windows to change their parenting. Do you have a use case for this scenario ? There are probably some I cannot see, but maybe could we solve them another way. A "toolbox" that must remain all of the N document windows, no matter which is raised. I propose that rather than the client having to send a directed acyclic graph to describe this situation, it only has to send a tree but it can edit it . Before the client raises any document window it reparents the toolbox to the new top-most window. Same question, do you have a use case for a popup surface that you would reparent? For our current use case (menus, do we have another one?) this is unlikely (afaict, I am not a toolkit guy). The exact same situation, because a client needs to be able to turn a "popup" into a "transient", for instance if the user can pin the menu. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Thu, Jun 13, 2013 at 5:42 PM, Bill Spitzak wrote: > sardemff7+wayl...@sardemff7.net wrote: > >>> This is a requirement so that non-trivial clients can be written >>> that are not forced to blink the transient windows to change their >>> parenting. >> >> >> Do you have a use case for this scenario ? There are probably some I >> cannot see, but maybe could we solve them another way. > > > A "toolbox" that must remain all of the N document windows, no matter which > is raised. > > I propose that rather than the client having to send a directed acyclic > graph to describe this situation, it only has to send a tree but it can edit > it . Before the client raises any document window it reparents the toolbox > to the new top-most window. > > >> Same question, do you have a use case for a popup surface that you would >> reparent? For our current use case (menus, do we have another one?) this >> is unlikely (afaict, I am not a toolkit guy). > > > The exact same situation, because a client needs to be able to turn a > "popup" into a "transient", for instance if the user can pin the menu. Just in case people have some filters set, I've sent some patches to the list, changing maximized and fullscreen to states. I don't real reviews on that, but at least a quick look to see if the overall approach is good, so I can continue. I want to know basically two things: 1) Will we have 2 new APIs for *each* surface states, so we can add the needed parameters to them, or a generic set/unset API with something like a void * parameter that will be used for any state? 2) Is fullscreen staying as another state, or as a surface type? After that I can add the events from server to inform that such states should be set, and then work on the minimize itself. Regards, -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
