Re: minimized and stick windows
On Thu, Jun 13, 2013 at 5:42 PM, Bill Spitzak spit...@gmail.com 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
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 spit...@gmail.com 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 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, 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.
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, sardemff7+wayl...@sardemff7.net 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, 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.
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
On Wed, Jun 12, 2013 at 4:39 PM, Bill Spitzak spit...@gmail.com 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 antogno...@gmail.com wrote: On Wed, Jun 12, 2013 at 4:39 PM, Bill Spitzak spit...@gmail.com 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 Thu, Jun 6, 2013 at 3:50 PM, Kristian Høgsberg k...@bitplanet.net wrote: On Tue, May 28, 2013 at 1:10 PM, Rafael Antognolli antogno...@gmail.com wrote: On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak spit...@gmail.com 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, May 28, 2013 at 1:10 PM, Rafael Antognolli antogno...@gmail.com wrote: On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak spit...@gmail.com 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, May 16, 2013 at 2:12 PM, Bill Spitzak spit...@gmail.com 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 antogno...@gmail.comwrote: On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak spit...@gmail.com 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 Wed, 15 May 2013 15:26:02 +0200 Alexander Preisinger alexander.preisin...@gmail.com wrote: 2013/5/15 Pekka Paalanen ppaala...@gmail.com On Wed, 15 May 2013 14:20:21 +0200 Alexander Preisinger alexander.preisin...@gmail.com 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 @@ arg name=output type=object interface=wl_output allow-null=true/ /request +request name=set_minimized +description summary=minimize the surface +Minimize the surface. + +The compositor responds with state_update event. +/description +/request + request name=set_title description summary=set surface title Set a short title for the surface. @@ -867,6 +875,30 @@ arg name=height type=int/ /event +enum name=state + description summary=different states for a surfaces + /description + entry name=toplevel value=1 summary=surface is neither maximized, minizized or fullscreen/ + entry name=maximized value=2 summary=surface is maximized/ + entry name=minimized value=3 summary=surface is minizimed/ + entry name=fullscreen value=4 summary=surface is fullscreen/ +/enum + +event name=state_update +description summary=update surface state +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. +/description +arg name=state type=uint summary=new surface state/ +/event + event name=popup_done description summary=popup interaction is done 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
Re: minimized and stick windows
On Wed, 15 May 2013 12:27:17 -0700 Bill Spitzak spit...@gmail.com 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
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 @@ arg name=output type=object interface=wl_output allow-null=true/ /request +request name=set_minimized +description summary=minimize the surface +Minimize the surface. + +The compositor responds with state_update event. +/description +/request + request name=set_title description summary=set surface title Set a short title for the surface. @@ -867,6 +875,30 @@ arg name=height type=int/ /event +enum name=state + description summary=different states for a surfaces + /description + entry name=toplevel value=1 summary=surface is neither maximized, minizized or fullscreen/ + entry name=maximized value=2 summary=surface is maximized/ + entry name=minimized value=3 summary=surface is minizimed/ + entry name=fullscreen value=4 summary=surface is fullscreen/ +/enum + +event name=state_update +description summary=update surface state +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. +/description +arg name=state type=uint summary=new surface state/ +/event + event name=popup_done description summary=popup interaction is done 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 k...@bitplanet.net On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Mon, 13 May 2013 17:26:28 -0500 Jason Ekstrand ja...@jlekstrand.net wrote: On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli antogno...@gmail.comwrote: Hi Jason, On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand ja...@jlekstrand.net 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
Re: minimized and stick windows
On Wed, 15 May 2013 14:20:21 +0200 Alexander Preisinger alexander.preisin...@gmail.com 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 @@ arg name=output type=object interface=wl_output allow-null=true/ /request +request name=set_minimized +description summary=minimize the surface +Minimize the surface. + +The compositor responds with state_update event. +/description +/request + request name=set_title description summary=set surface title Set a short title for the surface. @@ -867,6 +875,30 @@ arg name=height type=int/ /event +enum name=state + description summary=different states for a surfaces + /description + entry name=toplevel value=1 summary=surface is neither maximized, minizized or fullscreen/ + entry name=maximized value=2 summary=surface is maximized/ + entry name=minimized value=3 summary=surface is minizimed/ + entry name=fullscreen value=4 summary=surface is fullscreen/ +/enum + +event name=state_update +description summary=update surface state +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. +/description +arg name=state type=uint summary=new surface state/ +/event + event name=popup_done description summary=popup interaction is done 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
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 ja...@jlekstrand.net 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 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: interface
Re: minimized and stick windows
Alexander Preisinger wrote: + entry name=toplevel value=1 summary=surface is neither maximized, minizized or fullscreen/ 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: interface name=wl_shell_surface version=1 ... enum name=state description summary=surface states This is a bitmask of capabilities this seat has; if a member is set, then it is present on the seat. /description entry name=maximized value=1/ entry name=minimized value=2/ entry name=sticky value=3/ entry name=always_on_top value=4/ /enum 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. request name=set since=2 description summary=Set the specified surface state/ arg name=state type=uint/ /request 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'? request name=clear since=2 description summary=Clear the specified surface state/ arg name=state type=uint/ /request 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. ... event name=request_set since=2 description summary=request to set the specified surface state/ arg name=state type=uint/ /event event name=request_clear since=2 description summary=request to clear the specified surface state/ arg name=state type=uint/ /event event name=request_close since=2/ /interface How does that look? Excellent ;)
Re: minimized and stick windows
On May 15, 2013 9:37 PM, Mikko Levonmaa mikko.levon...@gmail.com 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: interface name=wl_shell_surface version=1 ... enum name=state description summary=surface states This is a bitmask of capabilities this seat has; if a member is set, then it is present on the seat. /description entry name=maximized value=1/ entry name=minimized value=2/ entry name=sticky value=3/ entry name=always_on_top value=4/ /enum 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.) request name=set since=2 description summary=Set the specified surface state/ arg name=state type=uint/ /request 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
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 Mon, 13 May 2013 17:26:28 -0500 Jason Ekstrand ja...@jlekstrand.net wrote: On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli antogno...@gmail.comwrote: Hi Jason, On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand ja...@jlekstrand.net 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 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
Hi Jason, On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand ja...@jlekstrand.net 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. 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 antogno...@gmail.comwrote: Hi Jason, On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand ja...@jlekstrand.net 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 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
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 antogno...@gmail.comwrote: 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
