Re: Weston : ideas about xdg_sell, and implementation for a taskbar
sardemff7+wayl...@sardemff7.net wrote: I was suggesting that one method of minimizing multiple surfaces would be for the client to arrange them all as children of one of them and then minimize the parent. The primary purpose is so the compositor/taskbar knows all those windows are "related", for instance to produce on a single taskbar entry. All scenarii are supported. You can reparent or simply minimize everyone. I was thinking the compositor would need the parent information. For instance if may show one taskbar entry per minimize request. But there may be other methods of doing this. No, because if the client wants to redraw or raise or show or hide any other surface as a side-effect of the minimize, these changes will not be atomic with the minimize, resulting in unwanted flickering of an intermediate display. There has to be a way for the minimized window to not disappear until the client does some kind of commit. The commit *is* the .set_minimized. You can raise, draw everything you want *then* send the .set_minimized request. It is the last step of the minimization process. In the scenario of multiple .set_minimized requests, the last one must be the “main” one (either the one requested by the compositor or the one triggered by client UI). Okay this is an interesting method for making atomic minimization without having to send a parent tree to the compositor. My main concern is that I think the parent tree is going to be needed anyway so I'm not sure this adds anything. Also I am unsure how a client indicates which minimize is the "main" one, as the compositor can't tell if another minimize is coming. This is a problem even for compositor-generated minimizes as the client may want to respond to a minimize request in a dialog box by minimizing the entire application, not just the dialog box. I mean “unfocus”. There is no reason to treat the minimized with a special event. The client already reparented surfaces and raised everything relevant. As long as the client is in charge of mimimizing itself (which it now sounds like you are proposing and is exactly what I was trying to propose originally) then this is ok. In fact the client could even assume that it loses the focus so no unfocus event is needed (but it appears a Wayland design criteria is to ensure pairing of events so it should be sent, though IMHO this enforced pairing is a waste of time as no sane client will rely on it). A surface without focus can be minimized, it's just that the client will be unable to tell if it worked. It is true that a client may display incorrect graphics if the set_minimized is ignored. If it expects an unfocus it could detect this after a delay but even then the drawing will blink. But I don't think this is a major concern. No, I am describing a .request_set_minimized/.set_minimized use case: 1a. The compositor send the .request_set_minimized event. 1b. The client “minimize” button is pressed. 2. The client reparent, draw, raise, do whatever it needs to keep the UI consistent. 3. The client send the .set_minimized request. 4. The relevant surfaces are hidden by the compositor. In case 1b with a compositor not supporting minimization, the client will just looks a bit weird. But: 1. I believe that a user will not expect anything better when using such a compositor. 2. Using flags in the configure event to inform the client which actions are supported will just remove such a weird case. Okay, that sounds exactly like what I proposed, which is the client is in final control over the minimization. Nothing happens until the client sends the set_minimized request. I definately prefer this but I must have misread your description as it sure sounded like you wanted communication after the compositor minimized the window, not before. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
On 11/02/2014 02:23, Bill Spitzak wrote: May not have explained it correctly. It sounded like you were not going to allow dialogs to be minimized except as a side-effect of minimizing the parent. I was, but I am not any more. I certainly want to allow this! And I certainly want to support minimizing multiple surfaces. I agree, it is needed. I was suggesting that one method of minimizing multiple surfaces would be for the client to arrange them all as children of one of them and then minimize the parent. The primary purpose is so the compositor/taskbar knows all those windows are "related", for instance to produce on a single taskbar entry. All scenarii are supported. You can reparent or simply minimize everyone. No, because if the client wants to redraw or raise or show or hide any other surface as a side-effect of the minimize, these changes will not be atomic with the minimize, resulting in unwanted flickering of an intermediate display. There has to be a way for the minimized window to not disappear until the client does some kind of commit. The commit *is* the .set_minimized. You can raise, draw everything you want *then* send the .set_minimized request. It is the last step of the minimization process. In the scenario of multiple .set_minimized requests, the last one must be the “main” one (either the one requested by the compositor or the one triggered by client UI). I assume you mean "minimize", not "unfocus"? It must be possible to minimize windows that don't have focus. I mean “unfocus”. There is no reason to treat the minimized with a special event. The client already reparented surfaces and raised everything relevant. It sounds like you are describing the 3-way communication I proposed. I see 3 steps: 1. Client decides it wants to minimize, tells compositor (this step is not done if the compositor chooses to do so). 2. Compositor tells client that the minimize is happening. 3. (the step you are missing) client tells compositor it has corrected all it's surfaces to reflect the result of minimizing and it is ok to perform it. No, I am describing a .request_set_minimized/.set_minimized use case: 1a. The compositor send the .request_set_minimized event. 1b. The client “minimize” button is pressed. 2. The client reparent, draw, raise, do whatever it needs to keep the UI consistent. 3. The client send the .set_minimized request. 4. The relevant surfaces are hidden by the compositor. In case 1b with a compositor not supporting minimization, the client will just looks a bit weird. But: 1. I believe that a user will not expect anything better when using such a compositor. 2. Using flags in the configure event to inform the client which actions are supported will just remove such a weird case. […] The rest of your email should be answered already. Thanks, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
sardemff7+wayl...@sardemff7.net wrote: Not sure why you want to limit it like this. I certainly would like the ability to minimized dialog windows. If you want a dialog window to be minimized, then it makes even more sense to allow minimizing multiple surfaces. The client could want to minimize everything if you minimize the toolbox. May not have explained it correctly. It sounded like you were not going to allow dialogs to be minimized except as a side-effect of minimizing the parent. I certainly want to allow this! And I certainly want to support minimizing multiple surfaces. I was suggesting that one method of minimizing multiple surfaces would be for the client to arrange them all as children of one of them and then minimize the parent. The primary purpose is so the compositor/taskbar knows all those windows are "related", for instance to produce on a single taskbar entry. 2. Do not assume anything (e.g. do not draw “inactive” window borders) before the real events (frame callback, focus events and friends) [compositor relevant features] This will not work. The actual vanishing of the minimized window must be deferred until *after* the client has done this, or it will not be atomic. This will work perfectly. As you said, the window vanished, which means an “unfocus” event and no more frame callback. The compositor can safely hide a window even if the decorations were not updated accordingly. Also, minimizing should not be treated specifically, we already have the frame callback and focus events. No, because if the client wants to redraw or raise or show or hide any other surface as a side-effect of the minimize, these changes will not be atomic with the minimize, resulting in unwanted flickering of an intermediate display. There has to be a way for the minimized window to not disappear until the client does some kind of commit. 4. Have a way for the client to know which features are supported [client UI consistence] From my previous point, the client UI consistence is assured without such a mechanism since the client will see no “unfocus” event. I assume you mean "minimize", not "unfocus"? It must be possible to minimize windows that don't have focus. It sounds like you are describing the 3-way communication I proposed. I see 3 steps: 1. Client decides it wants to minimize, tells compositor (this step is not done if the compositor chooses to do so). 2. Compositor tells client that the minimize is happening. 3. (the step you are missing) client tells compositor it has corrected all it's surfaces to reflect the result of minimizing and it is ok to perform it. You may be right that the client does need to know if the compositor would obey the minimize. I thought it was not a problem but as you point out the client may redraw the activation or move things around on the assumption that it is going to work. My first thought is to make this a 3-way communication. If you hit a minimize button the client sends a minimize-request-command to the compositor. The compositor then responds with a minimize-request-event. The client then knows it is going to work, adjusts all it's display, and sends a minimize-command. It may be better to just have an event that says whether the compositor will obey things, like you suggest. Just use the well-defined “unfocus” event and the minimize request. Again not sure why you said "unfocus", but I believe you are describing my 3-step version. 2. Compositor sends a minimize-notify (or not if it does not want to minimize). However (here is the tricky part) the surface has not really minimized! It is still visible on-screen and everything works as before until the compositor sees a commit that it knows is in response to the minimize-notify. There is just no point for the surface to still be visible. Unless some weird client wants to draw “Oh my god I am minimizing, bye!” in its surface. That is *EXACTLY* what I want to support, although it may be a little more sensible to imagine it writing it in a *different* window that stays on-screen. My primary goal is to allow the client to change the parent/child relationships. This is to avoid having to communicate a directed acyclic graph from the client to compositor of window relationships, which is really messy and is still making assumptions about how the ui should work. In fact I did not think about drawing until you mentioned redrawing things inactive, which is why I thought it was acceptable for the compositor to ignore minimize without the client knowing. The surfaces relation are already taken care of from point 1 here, no harm in actually hide everything. No, not if the relationships are more complex than the compositor can handle. Rather than make the compositor handle all possible window relationships I would like this to remain in the client, where it is a lot easier to develop and test new ideas. Summary: 1. .request_set_minimized (fr
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
(Some parts are reordered to makes more sense in my answers. Agreed parts are removed.) On 10/02/2014 23:42, Bill Spitzak wrote: sardemff7+wayl...@sardemff7.net wrote: Based on Bill’s events and requests, here is what I think should handle all cases the right way while keeping the global policy on the compositor’s side [in square brackets, the part(s) that the point ensure]: 1. States that the client *must* call .set_minimized at least on the same surface as the .request_set_minimized [compositor policy, client surfaces relations] Yes I think that is a way to detect dead clients. Rather than send minimize on many surfaces I propose the client arranges all the windows it wants to vanish as children of each other and then sends the minimize request to the top one (the one that the compositor requested must either be this top one or in the list). Multiple minimizes can then mean that the client wants multiple taskbar entries or that unminimizing one window is different than the other. 3. Only ever use “toplevel” (= no parent) surfaces compositor-side for the .request_set_minimized [client surfaces relations] Not sure why you want to limit it like this. I certainly would like the ability to minimized dialog windows. If you want a dialog window to be minimized, then it makes even more sense to allow minimizing multiple surfaces. The client could want to minimize everything if you minimize the toolbox. 2. Do not assume anything (e.g. do not draw “inactive” window borders) before the real events (frame callback, focus events and friends) [compositor relevant features] This will not work. The actual vanishing of the minimized window must be deferred until *after* the client has done this, or it will not be atomic. This will work perfectly. As you said, the window vanished, which means an “unfocus” event and no more frame callback. The compositor can safely hide a window even if the decorations were not updated accordingly. Also, minimizing should not be treated specifically, we already have the frame callback and focus events. 4. Have a way for the client to know which features are supported [client UI consistence] From my previous point, the client UI consistence is assured without such a mechanism since the client will see no “unfocus” event. You may be right that the client does need to know if the compositor would obey the minimize. I thought it was not a problem but as you point out the client may redraw the activation or move things around on the assumption that it is going to work. My first thought is to make this a 3-way communication. If you hit a minimize button the client sends a minimize-request-command to the compositor. The compositor then responds with a minimize-request-event. The client then knows it is going to work, adjusts all it's display, and sends a minimize-command. It may be better to just have an event that says whether the compositor will obey things, like you suggest. Just use the well-defined “unfocus” event and the minimize request. ALTERNATIVE: Actually after I typed this I think there may be a scheme that works more like you want but I'm not sure if it is practical: 1. Client sends a minimize-request on a surface, or the compositor just decides to minimize a surface. 2. Compositor sends a minimize-notify (or not if it does not want to minimize). However (here is the tricky part) the surface has not really minimized! It is still visible on-screen and everything works as before until the compositor sees a commit that it knows is in response to the minimize-notify. There is just no point for the surface to still be visible. Unless some weird client wants to draw “Oh my god I am minimizing, bye!” in its surface. The surfaces relation are already taken care of from point 1 here, no harm in actually hide everything. 3. Client then can respond to the minimize-notify by rearranging the surface tree, redrawing surfaces, doing minimize-request on other surfaces, etc. It then eventually does a commit, and the serial number can be used to identify that it is in response to the minimize-notify (is this possible in wayland?). Note the client is unable to stop the surface from minimizing, but can get ready for it. 4. If the client is dead then the compositor just does the minimize using the current surface parent/child tree. As I said, it /should/ be irrelevant. Summary: 1. .request_set_minimized (from the compositor) on a surface *must be obeyed* by the client, at least on said surface (e.g. a toolbox can minimize everything). 2. On .request_set_minimized, the client is free to reparent other surfaces to keep its UI in a consistent state. 3. The client just handle the “focus/unfocus” event and frame callback to draw its UI. Minimizing is not a special case as it does not need to be. It should work in all cases, especially the thumbnails preview: the surface is drawn inactive but updated as soon as the preview is visible (whil
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
sardemff7+wayl...@sardemff7.net wrote: First, a compositor may have no mechanism of “minimization”, so it must not be forced to obey such a request with no meaning for it. I agree the compositor does not have to obey the minimize request. I think I am not explaining things clearly: *BOTH* the client and compositor must decide to minimize or it does not work. You may be right that the client needs to know it won't work. Based on Bill’s events and requests, here is what I think should handle all cases the right way while keeping the global policy on the compositor’s side [in square brackets, the part(s) that the point ensure]: 1. States that the client *must* call .set_minimized at least on the same surface as the .request_set_minimized [compositor policy, client surfaces relations] Yes I think that is a way to detect dead clients. Rather than send minimize on many surfaces I propose the client arranges all the windows it wants to vanish as children of each other and then sends the minimize request to the top one (the one that the compositor requested must either be this top one or in the list). Multiple minimizes can then mean that the client wants multiple taskbar entries or that unminimizing one window is different than the other. 2. Do not assume anything (e.g. do not draw “inactive” window borders) before the real events (frame callback, focus events and friends) [compositor relevant features] This will not work. The actual vanishing of the minimized window must be deferred until *after* the client has done this, or it will not be atomic. 3. Only ever use “toplevel” (= no parent) surfaces compositor-side for the .request_set_minimized [client surfaces relations] Not sure why you want to limit it like this. I certainly would like the ability to minimized dialog windows. 4. Have a way for the client to know which features are supported [client UI consistence] You may be right that the client does need to know if the compositor would obey the minimize. I thought it was not a problem but as you point out the client may redraw the activation or move things around on the assumption that it is going to work. My first thought is to make this a 3-way communication. If you hit a minimize button the client sends a minimize-request-command to the compositor. The compositor then responds with a minimize-request-event. The client then knows it is going to work, adjusts all it's display, and sends a minimize-command. It may be better to just have an event that says whether the compositor will obey things, like you suggest. ALTERNATIVE: Actually after I typed this I think there may be a scheme that works more like you want but I'm not sure if it is practical: 1. Client sends a minimize-request on a surface, or the compositor just decides to minimize a surface. 2. Compositor sends a minimize-notify (or not if it does not want to minimize). However (here is the tricky part) the surface has not really minimized! It is still visible on-screen and everything works as before until the compositor sees a commit that it knows is in response to the minimize-notify. 3. Client then can respond to the minimize-notify by rearranging the surface tree, redrawing surfaces, doing minimize-request on other surfaces, etc. It then eventually does a commit, and the serial number can be used to identify that it is in response to the minimize-notify (is this possible in wayland?). Note the client is unable to stop the surface from minimizing, but can get ready for it. 4. If the client is dead then the compositor just does the minimize using the current surface parent/child tree. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
On 10/02/2014 21:57, Bill Spitzak wrote: Okay this sounds like it is going in exactly the wrong direction. And you sound like you do not understand the strong need here: the compositor *must be in charge* of everything. But, please, do not start to yell now, it can perfectly work well with your need as well, let me explain. What I am trying to do is restore the ability to use overlapping windows which was broken in approximatly 1990 when everybody started doing "click raises" (when even then it was *trivial* for a client to raise it's own windows), and has only gotten worse as "roles" and "layers" and so on have been added so that we can no longer even know if the user will be able to close a dialog box or whether it is visible when we don't have the focus. Current schemes are about as useful as the compositor drawing into your surface automatically in response to various mouse clicks (like always drawing a line on the assumption that you are a sketching program), then claiming you can "fix" it by drawing the correct picture again afterwards. This is obviously nonsense but for some reason the same logic is not being applied to surfaces. All I want is for the client to have final say over exactly what surfaces are visible and what their stacking order is. Then we may be able to implement floating dialog boxes again after 25 years of the dark ages. This means that no surface disappears, appears, or changes stacking order until after the client has been allowed to adjust all the other surfaces it owns. That sounds ok to me. And that means there cannot be a "you were minimized" event. There can only be a "I want you to minimize" event. It also means that a request from the client to be minimized must be obeyed. Partly wrong. First, a compositor may have no mechanism of “minimization”, so it must not be forced to obey such a request with no meaning for it. Second, the client must define relations between its surfaces, we both agree on that and I am pretty sure everyone does agree to some extent. The compositor is allowed to detect "dead" clients (and misbehaviong clients) and fake anything it wants, but this should not be used to dictate the api. True. The api should be designed and described for well-behaved clients (with perhaps a few notes on things that a compositor can detect that tells it that the client is behaving badly enough that the api should be ignored). No. It *must* have a properly defined behaviour for all cases *that will keep the compositor in charge*. The compositor is also the shell, and the shell is user’s choice because it implies a policy that the user wants. Based on Bill’s events and requests, here is what I think should handle all cases the right way while keeping the global policy on the compositor’s side [in square brackets, the part(s) that the point ensure]: 1. States that the client *must* call .set_minimized at least on the same surface as the .request_set_minimized [compositor policy, client surfaces relations] 2. Do not assume anything (e.g. do not draw “inactive” window borders) before the real events (frame callback, focus events and friends) [compositor relevant features] 3. Only ever use “toplevel” (= no parent) surfaces compositor-side for the .request_set_minimized [client surfaces relations] 4. Have a way for the client to know which features are supported [client UI consistence] IMO, the same points (adapted) apply to all features that may have UI both client-side and compositor-side. Concerning point 4, it could be a decoration flag in the configure event, the same way we want side ones (to support tiling!). Thanks, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Okay this sounds like it is going in exactly the wrong direction. What I am trying to do is restore the ability to use overlapping windows which was broken in approximatly 1990 when everybody started doing "click raises" (when even then it was *trivial* for a client to raise it's own windows), and has only gotten worse as "roles" and "layers" and so on have been added so that we can no longer even know if the user will be able to close a dialog box or whether it is visible when we don't have the focus. Current schemes are about as useful as the compositor drawing into your surface automatically in response to various mouse clicks (like always drawing a line on the assumption that you are a sketching program), then claiming you can "fix" it by drawing the correct picture again afterwards. This is obviously nonsense but for some reason the same logic is not being applied to surfaces. All I want is for the client to have final say over exactly what surfaces are visible and what their stacking order is. Then we may be able to implement floating dialog boxes again after 25 years of the dark ages. This means that no surface disappears, appears, or changes stacking order until after the client has been allowed to adjust all the other surfaces it owns. And that means there cannot be a "you were minimized" event. There can only be a "I want you to minimize" event. It also means that a request from the client to be minimized must be obeyed. The compositor is allowed to detect "dead" clients (and misbehaviong clients) and fake anything it wants, but this should not be used to dictate the api. The api should be designed and described for well-behaved clients (with perhaps a few notes on things that a compositor can detect that tells it that the client is behaving badly enough that the api should be ignored). Manuel Bachmann wrote: Agreed ; it makes a lot more sense this way. BTW, I'm not sure we *really* need to add things to xdg-shell. We'd just need it if we want to have client-side logic. A pure server-side logic just needs modifications in desktop-shell. I think my question is really what a Weston implementation should do. Currently, the code can do it both ways. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
I need to read the rest of the responses, but this does *not* sound like what I think is necessary. There should not be any need for an event saying "you have been minimized" as this should never happen without the client first requesting it. As I see it, if the compositor decides to minimize the window it sends your xdg_surface_request_set_minimized event. Nothing on-screen changes yet. The client gets this request, or interprets some other action (like clicking the minimize button on the window border). It then rearranges the window parent tree in any way it wants, so that windows it wants to disappear atomically are children of the minimized window, and windows it does not want to disapper are not. It then sends xdg_surface_set_minimized command to the compositor. The compositor is expected to respond to this by doing whatever it considers "minimizing" to the surface and all current child surfaces. A client "knows" it has been minimized because it sents a minimize request. There should not be any other way that the client is minimized and therefore there is no need for communication saying this. The compositor *may* detect dead clients that are not responding to pings or just don't respond quickly to the minimize request event, and do the minimize anyway. But this is not normal behavior. In normal behavior the client has absolute final say over what happens. As an aside, I think to avoid a huge number of requests and responses, there should instead be a single request and response with a bit flag saying what states are "on", with rules over what takes precedence. For instance "minimized" takes precedence over "fullscreen" and that takes precedence over "maximized". Manuel Bachmann wrote: Hi Bill, hi Jasper, hi everybody again, I just updated my taskbar code to make it work against Weston 1.4.0 : https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar And with regards to our former conversation, I added a logic that allows the client to "know" when it has been minimized : https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Agreed ; it makes a lot more sense this way.
BTW, I'm not sure we *really* need to add things to xdg-shell. We'd just
need it if we want to have client-side logic. A pure server-side logic just
needs modifications in desktop-shell.
I think my question is really what a Weston implementation should do.
Currently, the code can do it both ways.
Regards,
Tarnyko
2014-02-10 16:54 GMT+01:00 Giulio Camuffo :
> If the client will be hidden anyway the naming of
> request_set_minimize() seems odd to me, then. It should be like
> notify_set_minimize(), after which the client is not required to call
> set_minimized(), since it is so already.
>
> Giulio
>
> 2014-02-10 17:45 GMT+02:00 Manuel Bachmann
> :
> > Oh, and I forgot to add, the taskbar has its own logic asking the
> compositor
> > to hide, so clicking on the taskbar will do this, too. Sorry for the
> > additional noise.
> >
> > Regards,
> > Manuel
> >
> >
> > 2014-02-10 16:43 GMT+01:00 Manuel Bachmann
> > :
> >
> >> Hi Guilio,
> >>
> >> In fact, the client will be hidden anyway, because in order to keep some
> >> consistency, the compositor will hide it :
> >>
> >> "set_minimized()" function in "shell.c" :
> >>
> >>
> https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385
> >>
> >> What the client does, here, is that it knows it has been mimimized, and
> >> will handle in a specific way (slowing its rendering down, e.g.).
> >>
> >> It seemed like a good compromise between some opinions expressed before
> :
> >> server-side or client-side. Here the server-side will hide the window,
> but
> >> the client-side *may* do some useful stuff.
> >>
> >> I may be wrong of course, and in that case we could just handle this
> >> server-side (the code just did this before).
> >>
> >> Regards
> >> Tarnyko,
> >>
> >>
> >> 2014-02-10 16:33 GMT+01:00 Giulio Camuffo :
> >>
> >>> 2014-02-10 17:25 GMT+02:00 Manuel Bachmann
> >>> :
> >>> > Hi Bill, hi Jasper, hi everybody again,
> >>> >
> >>> > I just updated my taskbar code to make it work against Weston 1.4.0 :
> >>> > https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
> >>> >
> >>> > And with regards to our former conversation, I added a logic that
> >>> > allows the
> >>> > client to "know" when it has been minimized :
> >>> >
> >>> >
> https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
> >>> >
> >>> > Here is how it works :
> >>> >
> >>> > - there are 2 new compositor-to-client requests in "xdg_shell.xml"
> (not
> >>> > upstream, added them for the demo) :
> >>> > xdg_surface_request_set_minimized
> >>> > xdg_surface_request_unset_minimized
> >>> >
> >>> > - when a client using toytoolkit (weston-terminal for instance) wants
> >>> > to be
> >>> > minimized, he asks the compositor :
> >>> > xdg_surface_set_minimized(xdg_surface);
> >>> >
> >>> > - the compositor handles this with its own logic. In my current
> >>> > implementation, he hides it from view, but the code is in #ifdef
> >>> > HAVE_TASKBAR and he could very well do anything else ;
> >>> >
> >>> > - when the compositor is done, he tells the client surface it has
> been
> >>> > minimized by sending :
> >>> > xdg_surface_send_request_set_minimized(shsurf->resource);
> >>> >
> >>> > - the client gets its answer in :
> >>> > xdg_surface_request_set_minimized( ... ) { }
> >>>
> >>> I don't think that's a good idea. If i click on the taskbar I want the
> >>> client to hide, even if it doesn't call the
> >>> xdg_surface_request_set_minimized for any reason (it's frozen, it's
> >>> broken, ...). It may make sense to send an event telling the client it
> >>> has been minimized, thought it should not mean the client can stop
> >>> rendering.
> >>>
> >>> >
> >>> > and in the specific case of toytoolkit, decides to suspend the redraw
> >>> > with :
> >>> >
> >>> > window_defer_redraw_until_configure (window);
> >>> >
> >>> > So it doesn't consume too much CPU until it's unminimized again.
> >>> >
> >>> > - if later, the surface would be un-mimimized, then the client would
> >>> > get the
> >>> > answer with "request_unset_minimized()" and redraw its surface with :
> >>> > window_schedule_redraw (window);
> >>> >
> >>> > So a video player, for example, could cpntinue playing sound but
> avoid
> >>> > decoding some frames.
> >>> >
> >>> > BTW, if you remove the last commit of my code, the logic is
> >>> > compositor-only,
> >>> > but with this commit, it becomes a kind of communication :
> >>> > "client->compositor->shell" / "shell->compositor->client".
> >>> >
> >>> > What do you think of this ?
> >>> >
> >>> > Regards,
> >>> > Manuel
> >>> >
> >>> > -
> >>> >
> >>> >
> >>> > 2014-01-31 7:11 GMT+01:00 Bill Spitzak :
> >>> >
> >>> >>
> >>> >>
> >>> >> Jasper St. Pierre wrote:
> >>> >>
> >>> >>> A toolbox over a painting program that has two documents open.
> >>> >>>
> >>> >>> So, what is the expected behavior here exactly? There's a minimize
> >>> >>> button
> >>> >>> on both of the con
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
If the client will be hidden anyway the naming of
request_set_minimize() seems odd to me, then. It should be like
notify_set_minimize(), after which the client is not required to call
set_minimized(), since it is so already.
Giulio
2014-02-10 17:45 GMT+02:00 Manuel Bachmann
:
> Oh, and I forgot to add, the taskbar has its own logic asking the compositor
> to hide, so clicking on the taskbar will do this, too. Sorry for the
> additional noise.
>
> Regards,
> Manuel
>
>
> 2014-02-10 16:43 GMT+01:00 Manuel Bachmann
> :
>
>> Hi Guilio,
>>
>> In fact, the client will be hidden anyway, because in order to keep some
>> consistency, the compositor will hide it :
>>
>> "set_minimized()" function in "shell.c" :
>>
>> https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385
>>
>> What the client does, here, is that it knows it has been mimimized, and
>> will handle in a specific way (slowing its rendering down, e.g.).
>>
>> It seemed like a good compromise between some opinions expressed before :
>> server-side or client-side. Here the server-side will hide the window, but
>> the client-side *may* do some useful stuff.
>>
>> I may be wrong of course, and in that case we could just handle this
>> server-side (the code just did this before).
>>
>> Regards
>> Tarnyko,
>>
>>
>> 2014-02-10 16:33 GMT+01:00 Giulio Camuffo :
>>
>>> 2014-02-10 17:25 GMT+02:00 Manuel Bachmann
>>> :
>>> > Hi Bill, hi Jasper, hi everybody again,
>>> >
>>> > I just updated my taskbar code to make it work against Weston 1.4.0 :
>>> > https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
>>> >
>>> > And with regards to our former conversation, I added a logic that
>>> > allows the
>>> > client to "know" when it has been minimized :
>>> >
>>> > https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
>>> >
>>> > Here is how it works :
>>> >
>>> > - there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
>>> > upstream, added them for the demo) :
>>> > xdg_surface_request_set_minimized
>>> > xdg_surface_request_unset_minimized
>>> >
>>> > - when a client using toytoolkit (weston-terminal for instance) wants
>>> > to be
>>> > minimized, he asks the compositor :
>>> > xdg_surface_set_minimized(xdg_surface);
>>> >
>>> > - the compositor handles this with its own logic. In my current
>>> > implementation, he hides it from view, but the code is in #ifdef
>>> > HAVE_TASKBAR and he could very well do anything else ;
>>> >
>>> > - when the compositor is done, he tells the client surface it has been
>>> > minimized by sending :
>>> > xdg_surface_send_request_set_minimized(shsurf->resource);
>>> >
>>> > - the client gets its answer in :
>>> > xdg_surface_request_set_minimized( ... ) { }
>>>
>>> I don't think that's a good idea. If i click on the taskbar I want the
>>> client to hide, even if it doesn't call the
>>> xdg_surface_request_set_minimized for any reason (it's frozen, it's
>>> broken, ...). It may make sense to send an event telling the client it
>>> has been minimized, thought it should not mean the client can stop
>>> rendering.
>>>
>>> >
>>> > and in the specific case of toytoolkit, decides to suspend the redraw
>>> > with :
>>> >
>>> > window_defer_redraw_until_configure (window);
>>> >
>>> > So it doesn't consume too much CPU until it's unminimized again.
>>> >
>>> > - if later, the surface would be un-mimimized, then the client would
>>> > get the
>>> > answer with "request_unset_minimized()" and redraw its surface with :
>>> > window_schedule_redraw (window);
>>> >
>>> > So a video player, for example, could cpntinue playing sound but avoid
>>> > decoding some frames.
>>> >
>>> > BTW, if you remove the last commit of my code, the logic is
>>> > compositor-only,
>>> > but with this commit, it becomes a kind of communication :
>>> > "client->compositor->shell" / "shell->compositor->client".
>>> >
>>> > What do you think of this ?
>>> >
>>> > Regards,
>>> > Manuel
>>> >
>>> > -
>>> >
>>> >
>>> > 2014-01-31 7:11 GMT+01:00 Bill Spitzak :
>>> >
>>> >>
>>> >>
>>> >> Jasper St. Pierre wrote:
>>> >>
>>> >>> A toolbox over a painting program that has two documents open.
>>> >>>
>>> >>> So, what is the expected behavior here exactly? There's a minimize
>>> >>> button
>>> >>> on both of the content window's decorations, and clicking on one
>>> >>> should
>>> >>> minimize all three windows?
>>> >>
>>> >>
>>> >> Clicking minimize of one of the documents makes only the document
>>> >> disappear. But then clicking on the minimize of the other document
>>> >> makes
>>> >> both the document and toolbox disappear.
>>> >>
>>> >>
>>> >>> What should using the "minimize keyboard shortcut" functionality of
>>> >>> your
>>> >>> compositor do? Should it differ from using the button in the UI? What
>>> >>> does
>>> >>> it do right now on X11 or other platforms?
>>> >>
>>> >>
>>> >> It should do EXACTLY the same thing as a minimize button. Any
>>> >> different
>>> >> behavior
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Hi Guilio,
In fact, the client will be hidden anyway, because in order to keep some
consistency, the compositor will hide it :
"set_minimized()" function in "shell.c" :
https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385
What the client does, here, is that it knows it has been mimimized, and
will handle in a specific way (slowing its rendering down, e.g.).
It seemed like a good compromise between some opinions expressed before :
server-side or client-side. Here the server-side will hide the window, but
the client-side *may* do some useful stuff.
I may be wrong of course, and in that case we could just handle this
server-side (the code just did this before).
Regards
Tarnyko,
2014-02-10 16:33 GMT+01:00 Giulio Camuffo :
> 2014-02-10 17:25 GMT+02:00 Manuel Bachmann
> :
> > Hi Bill, hi Jasper, hi everybody again,
> >
> > I just updated my taskbar code to make it work against Weston 1.4.0 :
> > https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
> >
> > And with regards to our former conversation, I added a logic that allows
> the
> > client to "know" when it has been minimized :
> >
> https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
> >
> > Here is how it works :
> >
> > - there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
> > upstream, added them for the demo) :
> > xdg_surface_request_set_minimized
> > xdg_surface_request_unset_minimized
> >
> > - when a client using toytoolkit (weston-terminal for instance) wants to
> be
> > minimized, he asks the compositor :
> > xdg_surface_set_minimized(xdg_surface);
> >
> > - the compositor handles this with its own logic. In my current
> > implementation, he hides it from view, but the code is in #ifdef
> > HAVE_TASKBAR and he could very well do anything else ;
> >
> > - when the compositor is done, he tells the client surface it has been
> > minimized by sending :
> > xdg_surface_send_request_set_minimized(shsurf->resource);
> >
> > - the client gets its answer in :
> > xdg_surface_request_set_minimized( ... ) { }
>
> I don't think that's a good idea. If i click on the taskbar I want the
> client to hide, even if it doesn't call the
> xdg_surface_request_set_minimized for any reason (it's frozen, it's
> broken, ...). It may make sense to send an event telling the client it
> has been minimized, thought it should not mean the client can stop
> rendering.
>
> >
> > and in the specific case of toytoolkit, decides to suspend the redraw
> with :
> >
> > window_defer_redraw_until_configure (window);
> >
> > So it doesn't consume too much CPU until it's unminimized again.
> >
> > - if later, the surface would be un-mimimized, then the client would get
> the
> > answer with "request_unset_minimized()" and redraw its surface with :
> > window_schedule_redraw (window);
> >
> > So a video player, for example, could cpntinue playing sound but avoid
> > decoding some frames.
> >
> > BTW, if you remove the last commit of my code, the logic is
> compositor-only,
> > but with this commit, it becomes a kind of communication :
> > "client->compositor->shell" / "shell->compositor->client".
> >
> > What do you think of this ?
> >
> > Regards,
> > Manuel
> >
> > -
> >
> >
> > 2014-01-31 7:11 GMT+01:00 Bill Spitzak :
> >
> >>
> >>
> >> Jasper St. Pierre wrote:
> >>
> >>> A toolbox over a painting program that has two documents open.
> >>>
> >>> So, what is the expected behavior here exactly? There's a minimize
> button
> >>> on both of the content window's decorations, and clicking on one should
> >>> minimize all three windows?
> >>
> >>
> >> Clicking minimize of one of the documents makes only the document
> >> disappear. But then clicking on the minimize of the other document makes
> >> both the document and toolbox disappear.
> >>
> >>
> >>> What should using the "minimize keyboard shortcut" functionality of
> your
> >>> compositor do? Should it differ from using the button in the UI? What
> does
> >>> it do right now on X11 or other platforms?
> >>
> >>
> >> It should do EXACTLY the same thing as a minimize button. Any different
> >> behavior is a bug.
> >>
> >>
> >>> A client can ignore attempts to close it with the close box.
> >>>
> >>> Are you talking about simply having a minimize button in the
> server-side
> >>> decoration that does nothing? Or are you talking about the compositor
> >>> forcibly minimizing a window with e.g. a keyboard shortcut?
> >>>
> >>> The former is an application bug (the button does nothing because it
> was
> >>> wired to do nothing), and while it's certainly frustrating from a user
> >>> perspective, the compositor can still forcibly minimize or close the
> window.
> >>
> >>
> >> I would expect that a compositor shortcut key to close a window would
> >> first try sending a message to the app saying it wants to close, and
> the app
> >> can decide to not close (ideally by asking the user if they are sure,
> and
> >> the user says
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Oh, and I forgot to add, the taskbar has its own logic asking the
compositor to hide, so clicking on the taskbar will do this, too. Sorry for
the additional noise.
Regards,
Manuel
2014-02-10 16:43 GMT+01:00 Manuel Bachmann <
manuel.bachm...@open.eurogiciel.org>:
> Hi Guilio,
>
> In fact, the client will be hidden anyway, because in order to keep some
> consistency, the compositor will hide it :
>
> "set_minimized()" function in "shell.c" :
>
> https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385
>
> What the client does, here, is that it knows it has been mimimized, and
> will handle in a specific way (slowing its rendering down, e.g.).
>
> It seemed like a good compromise between some opinions expressed before :
> server-side or client-side. Here the server-side will hide the window, but
> the client-side *may* do some useful stuff.
>
> I may be wrong of course, and in that case we could just handle this
> server-side (the code just did this before).
>
> Regards
> Tarnyko,
>
>
> 2014-02-10 16:33 GMT+01:00 Giulio Camuffo :
>
> 2014-02-10 17:25 GMT+02:00 Manuel Bachmann
>> :
>> > Hi Bill, hi Jasper, hi everybody again,
>> >
>> > I just updated my taskbar code to make it work against Weston 1.4.0 :
>> > https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
>> >
>> > And with regards to our former conversation, I added a logic that
>> allows the
>> > client to "know" when it has been minimized :
>> >
>> https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
>> >
>> > Here is how it works :
>> >
>> > - there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
>> > upstream, added them for the demo) :
>> > xdg_surface_request_set_minimized
>> > xdg_surface_request_unset_minimized
>> >
>> > - when a client using toytoolkit (weston-terminal for instance) wants
>> to be
>> > minimized, he asks the compositor :
>> > xdg_surface_set_minimized(xdg_surface);
>> >
>> > - the compositor handles this with its own logic. In my current
>> > implementation, he hides it from view, but the code is in #ifdef
>> > HAVE_TASKBAR and he could very well do anything else ;
>> >
>> > - when the compositor is done, he tells the client surface it has been
>> > minimized by sending :
>> > xdg_surface_send_request_set_minimized(shsurf->resource);
>> >
>> > - the client gets its answer in :
>> > xdg_surface_request_set_minimized( ... ) { }
>>
>> I don't think that's a good idea. If i click on the taskbar I want the
>> client to hide, even if it doesn't call the
>> xdg_surface_request_set_minimized for any reason (it's frozen, it's
>> broken, ...). It may make sense to send an event telling the client it
>> has been minimized, thought it should not mean the client can stop
>> rendering.
>>
>> >
>> > and in the specific case of toytoolkit, decides to suspend the redraw
>> with :
>> >
>> > window_defer_redraw_until_configure (window);
>> >
>> > So it doesn't consume too much CPU until it's unminimized again.
>> >
>> > - if later, the surface would be un-mimimized, then the client would
>> get the
>> > answer with "request_unset_minimized()" and redraw its surface with :
>> > window_schedule_redraw (window);
>> >
>> > So a video player, for example, could cpntinue playing sound but avoid
>> > decoding some frames.
>> >
>> > BTW, if you remove the last commit of my code, the logic is
>> compositor-only,
>> > but with this commit, it becomes a kind of communication :
>> > "client->compositor->shell" / "shell->compositor->client".
>> >
>> > What do you think of this ?
>> >
>> > Regards,
>> > Manuel
>> >
>> > -
>> >
>> >
>> > 2014-01-31 7:11 GMT+01:00 Bill Spitzak :
>> >
>> >>
>> >>
>> >> Jasper St. Pierre wrote:
>> >>
>> >>> A toolbox over a painting program that has two documents open.
>> >>>
>> >>> So, what is the expected behavior here exactly? There's a minimize
>> button
>> >>> on both of the content window's decorations, and clicking on one
>> should
>> >>> minimize all three windows?
>> >>
>> >>
>> >> Clicking minimize of one of the documents makes only the document
>> >> disappear. But then clicking on the minimize of the other document
>> makes
>> >> both the document and toolbox disappear.
>> >>
>> >>
>> >>> What should using the "minimize keyboard shortcut" functionality of
>> your
>> >>> compositor do? Should it differ from using the button in the UI? What
>> does
>> >>> it do right now on X11 or other platforms?
>> >>
>> >>
>> >> It should do EXACTLY the same thing as a minimize button. Any different
>> >> behavior is a bug.
>> >>
>> >>
>> >>> A client can ignore attempts to close it with the close box.
>> >>>
>> >>> Are you talking about simply having a minimize button in the
>> server-side
>> >>> decoration that does nothing? Or are you talking about the compositor
>> >>> forcibly minimizing a window with e.g. a keyboard shortcut?
>> >>>
>> >>> The former is an application bug (the button does nothing because it
>> was
>> >>>
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
2014-02-10 17:25 GMT+02:00 Manuel Bachmann
:
> Hi Bill, hi Jasper, hi everybody again,
>
> I just updated my taskbar code to make it work against Weston 1.4.0 :
> https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
>
> And with regards to our former conversation, I added a logic that allows the
> client to "know" when it has been minimized :
> https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
>
> Here is how it works :
>
> - there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
> upstream, added them for the demo) :
> xdg_surface_request_set_minimized
> xdg_surface_request_unset_minimized
>
> - when a client using toytoolkit (weston-terminal for instance) wants to be
> minimized, he asks the compositor :
> xdg_surface_set_minimized(xdg_surface);
>
> - the compositor handles this with its own logic. In my current
> implementation, he hides it from view, but the code is in #ifdef
> HAVE_TASKBAR and he could very well do anything else ;
>
> - when the compositor is done, he tells the client surface it has been
> minimized by sending :
> xdg_surface_send_request_set_minimized(shsurf->resource);
>
> - the client gets its answer in :
> xdg_surface_request_set_minimized( ... ) { }
I don't think that's a good idea. If i click on the taskbar I want the
client to hide, even if it doesn't call the
xdg_surface_request_set_minimized for any reason (it's frozen, it's
broken, ...). It may make sense to send an event telling the client it
has been minimized, thought it should not mean the client can stop
rendering.
>
> and in the specific case of toytoolkit, decides to suspend the redraw with :
>
> window_defer_redraw_until_configure (window);
>
> So it doesn't consume too much CPU until it's unminimized again.
>
> - if later, the surface would be un-mimimized, then the client would get the
> answer with "request_unset_minimized()" and redraw its surface with :
> window_schedule_redraw (window);
>
> So a video player, for example, could cpntinue playing sound but avoid
> decoding some frames.
>
> BTW, if you remove the last commit of my code, the logic is compositor-only,
> but with this commit, it becomes a kind of communication :
> "client->compositor->shell" / "shell->compositor->client".
>
> What do you think of this ?
>
> Regards,
> Manuel
>
> -
>
>
> 2014-01-31 7:11 GMT+01:00 Bill Spitzak :
>
>>
>>
>> Jasper St. Pierre wrote:
>>
>>> A toolbox over a painting program that has two documents open.
>>>
>>> So, what is the expected behavior here exactly? There's a minimize button
>>> on both of the content window's decorations, and clicking on one should
>>> minimize all three windows?
>>
>>
>> Clicking minimize of one of the documents makes only the document
>> disappear. But then clicking on the minimize of the other document makes
>> both the document and toolbox disappear.
>>
>>
>>> What should using the "minimize keyboard shortcut" functionality of your
>>> compositor do? Should it differ from using the button in the UI? What does
>>> it do right now on X11 or other platforms?
>>
>>
>> It should do EXACTLY the same thing as a minimize button. Any different
>> behavior is a bug.
>>
>>
>>> A client can ignore attempts to close it with the close box.
>>>
>>> Are you talking about simply having a minimize button in the server-side
>>> decoration that does nothing? Or are you talking about the compositor
>>> forcibly minimizing a window with e.g. a keyboard shortcut?
>>>
>>> The former is an application bug (the button does nothing because it was
>>> wired to do nothing), and while it's certainly frustrating from a user
>>> perspective, the compositor can still forcibly minimize or close the window.
>>
>>
>> I would expect that a compositor shortcut key to close a window would
>> first try sending a message to the app saying it wants to close, and the app
>> can decide to not close (ideally by asking the user if they are sure, and
>> the user says no). If it just killed the app or destroyed the window that
>> could be very user-unfriendly and I am rather suprised anybody would suggest
>> that.
>>
>> If an app is non-cooperative the compositor can do some stuff. For close
>> it can kill the client if it is not responding to pings. Minimize probably
>> should also force-hide the surface after a timeout even if the client is
>> responding to pings. However this fallback stuff should not be part of the
>> Wayland api and can be left up to the compositor writers to decide.
>>
>
>
>
> --
> Regards,
>
> Manuel BACHMANN
> Tizen Project
> VANNES-FR
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Hi Bill, hi Jasper, hi everybody again,
I just updated my taskbar code to make it work against Weston 1.4.0 :
https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
And with regards to our former conversation, I added a logic that allows
the client to "know" when it has been minimized :
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
Here is how it works :
- there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
upstream, added them for the demo) :
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized
- when a client using toytoolkit (weston-terminal for instance) wants to be
minimized, he asks the compositor :
xdg_surface_set_minimized(xdg_surface);
- the compositor handles this with its own logic. In my current
implementation, he hides it from view, but the code is in #ifdef
HAVE_TASKBAR and he could very well do anything else ;
- when the compositor is done, he tells the client surface it has been
minimized by sending :
xdg_surface_send_request_set_minimized(shsurf->resource);
- the client gets its answer in :
xdg_surface_request_set_minimized( ... ) { }
and in the specific case of toytoolkit, decides to suspend the redraw with :
window_defer_redraw_until_configure (window);
So it doesn't consume too much CPU until it's unminimized again.
- if later, the surface would be un-mimimized, then the client would get
the answer with "request_unset_minimized()" and redraw its surface with :
window_schedule_redraw (window);
So a video player, for example, could cpntinue playing sound but avoid
decoding some frames.
BTW, if you remove the last commit of my code, the logic is
compositor-only, but with this commit, it becomes a kind of communication :
"client->compositor->shell" / "shell->compositor->client".
What do you think of this ?
Regards,
Manuel
-
2014-01-31 7:11 GMT+01:00 Bill Spitzak :
>
>
> Jasper St. Pierre wrote:
>
> A toolbox over a painting program that has two documents open.
>>
>> So, what is the expected behavior here exactly? There's a minimize button
>> on both of the content window's decorations, and clicking on one should
>> minimize all three windows?
>>
>
> Clicking minimize of one of the documents makes only the document
> disappear. But then clicking on the minimize of the other document makes
> both the document and toolbox disappear.
>
>
> What should using the "minimize keyboard shortcut" functionality of your
>> compositor do? Should it differ from using the button in the UI? What does
>> it do right now on X11 or other platforms?
>>
>
> It should do EXACTLY the same thing as a minimize button. Any different
> behavior is a bug.
>
>
> A client can ignore attempts to close it with the close box.
>>
>> Are you talking about simply having a minimize button in the server-side
>> decoration that does nothing? Or are you talking about the compositor
>> forcibly minimizing a window with e.g. a keyboard shortcut?
>>
>> The former is an application bug (the button does nothing because it was
>> wired to do nothing), and while it's certainly frustrating from a user
>> perspective, the compositor can still forcibly minimize or close the window.
>>
>
> I would expect that a compositor shortcut key to close a window would
> first try sending a message to the app saying it wants to close, and the
> app can decide to not close (ideally by asking the user if they are sure,
> and the user says no). If it just killed the app or destroyed the window
> that could be very user-unfriendly and I am rather suprised anybody would
> suggest that.
>
> If an app is non-cooperative the compositor can do some stuff. For close
> it can kill the client if it is not responding to pings. Minimize probably
> should also force-hide the surface after a timeout even if the client is
> responding to pings. However this fallback stuff should not be part of the
> Wayland api and can be left up to the compositor writers to decide.
>
>
--
Regards,
*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Jasper St. Pierre wrote: A toolbox over a painting program that has two documents open. So, what is the expected behavior here exactly? There's a minimize button on both of the content window's decorations, and clicking on one should minimize all three windows? Clicking minimize of one of the documents makes only the document disappear. But then clicking on the minimize of the other document makes both the document and toolbox disappear. What should using the "minimize keyboard shortcut" functionality of your compositor do? Should it differ from using the button in the UI? What does it do right now on X11 or other platforms? It should do EXACTLY the same thing as a minimize button. Any different behavior is a bug. A client can ignore attempts to close it with the close box. Are you talking about simply having a minimize button in the server-side decoration that does nothing? Or are you talking about the compositor forcibly minimizing a window with e.g. a keyboard shortcut? The former is an application bug (the button does nothing because it was wired to do nothing), and while it's certainly frustrating from a user perspective, the compositor can still forcibly minimize or close the window. I would expect that a compositor shortcut key to close a window would first try sending a message to the app saying it wants to close, and the app can decide to not close (ideally by asking the user if they are sure, and the user says no). If it just killed the app or destroyed the window that could be very user-unfriendly and I am rather suprised anybody would suggest that. If an app is non-cooperative the compositor can do some stuff. For close it can kill the client if it is not responding to pings. Minimize probably should also force-hide the surface after a timeout even if the client is responding to pings. However this fallback stuff should not be part of the Wayland api and can be left up to the compositor writers to decide. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
On Thu, Jan 30, 2014 at 9:03 PM, Bill Spitzak wrote: > Jasper St. Pierre wrote: > > A simple problem is a floating window shared by two main windows. >> >> Can you give a concrete example of such a case? Not because I'm assuming >> none exist, but because I want a specific example to evaluate and think >> about. >> > > A toolbox over a painting program that has two documents open. > So, what is the expected behavior here exactly? There's a minimize button on both of the content window's decorations, and clicking on one should minimize all three windows? What should using the "minimize keyboard shortcut" functionality of your compositor do? Should it differ from using the button in the UI? What does it do right now on X11 or other platforms? > since there are a billion other ways a client can misbehave and you >> are not stopping them all with this one api. >> >> Like what? >> > > A client can ignore attempts to close it with the close box. > Are you talking about simply having a minimize button in the server-side decoration that does nothing? Or are you talking about the compositor forcibly minimizing a window with e.g. a keyboard shortcut? The former is an application bug (the button does nothing because it was wired to do nothing), and while it's certainly frustrating from a user perspective, the compositor can still forcibly minimize or close the window. -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Jasper St. Pierre wrote: A simple problem is a floating window shared by two main windows. Can you give a concrete example of such a case? Not because I'm assuming none exist, but because I want a specific example to evaluate and think about. A toolbox over a painting program that has two documents open. since there are a billion other ways a client can misbehave and you are not stopping them all with this one api. Like what? A client can ignore attempts to close it with the close box. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Manuel Bachmann wrote: Hi Bill, and thanks a lot for sharing your thoughts, GTK+ seems to have an impl, so I will check what it does. I think it may be trying to use X "window groups" which is an example of an excessively complex api to try to solve this. It has not worked and Gimp is now giving up on having floating windows, just like everybody else. I also tried X window groups to fix this for our software and was unable to get it to work at all, though it was partly due to broken implementaions, not just design. It was ridiculously complex, too, and still could not do the arbitrary window ordering I wanted. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak wrote: > Jasper St. Pierre wrote: > > Hiding windows should not have any influence over the client, as many >> desktop environments, including Weston, want to show live previews for >> minimized or hidden windows in alt-tab or Expose-alikes. >> >> Also, it matches user expectations. If the user clicks minimize on a >> window, they want it hidden, and they mean it, not get bested with >> "surprise! You tried to hide me but I resist by mapping my subsurfaces >> elsewhere!" >> > > The problem is that it makes window management very complicated, or > limiting. This is why no modern applications use overlapping windows, > instead doing their own tiled window layout inside one big window. They > cannot get the window system to overlay windows correctly except for > trivial temporary popups. > > A simple problem is a floating window shared by two main windows. Some > parts of the compositor want to know that the floating window belongs to at > least one main window (for instance to not show it in a toolbar). But the > client does not want it to vanish when that window is closed, yet it should > vanish when both windows are closed. > Can you give a concrete example of such a case? Not because I'm assuming none exist, but because I want a specific example to evaluate and think about. > This will require the client to tell the compositor that both of the main > windows are parents, thus giving rise to a Directed Acyclic Graph of > parents. I believe reliably updating this structure from the client is > enormously more complex and error-prone than a simple tree. Also I suspect > there are desirable window manipulations that cannot be described by a DAG > and thus even more complex api must be provided in Wayland. > > Kristin has proposed that nothing be sent from the client to the > compositor, I think he is worried about the api bloat this may cause. > > I feel that an intermediate solution that limits the data to a tree, since > only a "set parent" api is needed to manage it. When a client requests that > a window be raised or hidden then this tree causes children to do the same. > But this is only done after a request from the client, so the client can > first rearrange or delete the tree in order to get the behavior it wants. > The main reason for this is that I think it is necessary so wayland clients > can be displayed remotely on non-wayland systems that support such trees, > otherwise remote display may be very blinky when users raise windows. > > Both of these however require that all decisions about window > relationships be left to the client. There is no way around this, no matter > how much you want to pretend otherwise. > > A client that fails to hide the window after the request and a timeout can > get force-hidden, if you think this is a problem. But you cannot use > misbehaving clients as a reason for designing an api, since there are a > billion other ways a client can misbehave and you are not stopping them all > with this one api. > Like what? -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Jasper St. Pierre wrote: Hiding windows should not have any influence over the client, as many desktop environments, including Weston, want to show live previews for minimized or hidden windows in alt-tab or Expose-alikes. Also, it matches user expectations. If the user clicks minimize on a window, they want it hidden, and they mean it, not get bested with "surprise! You tried to hide me but I resist by mapping my subsurfaces elsewhere!" The problem is that it makes window management very complicated, or limiting. This is why no modern applications use overlapping windows, instead doing their own tiled window layout inside one big window. They cannot get the window system to overlay windows correctly except for trivial temporary popups. A simple problem is a floating window shared by two main windows. Some parts of the compositor want to know that the floating window belongs to at least one main window (for instance to not show it in a toolbar). But the client does not want it to vanish when that window is closed, yet it should vanish when both windows are closed. This will require the client to tell the compositor that both of the main windows are parents, thus giving rise to a Directed Acyclic Graph of parents. I believe reliably updating this structure from the client is enormously more complex and error-prone than a simple tree. Also I suspect there are desirable window manipulations that cannot be described by a DAG and thus even more complex api must be provided in Wayland. Kristin has proposed that nothing be sent from the client to the compositor, I think he is worried about the api bloat this may cause. I feel that an intermediate solution that limits the data to a tree, since only a "set parent" api is needed to manage it. When a client requests that a window be raised or hidden then this tree causes children to do the same. But this is only done after a request from the client, so the client can first rearrange or delete the tree in order to get the behavior it wants. The main reason for this is that I think it is necessary so wayland clients can be displayed remotely on non-wayland systems that support such trees, otherwise remote display may be very blinky when users raise windows. Both of these however require that all decisions about window relationships be left to the client. There is no way around this, no matter how much you want to pretend otherwise. A client that fails to hide the window after the request and a timeout can get force-hidden, if you think this is a problem. But you cannot use misbehaving clients as a reason for designing an api, since there are a billion other ways a client can misbehave and you are not stopping them all with this one api. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Well, having read Jasper's comment, he has some valid points, the most important being in my opinion : > it matches user expectations. If the user clicks minimize on a window, they want it hidden It the logic of what should *really* happen when a window is minimized is implemented client-side, that means the UI experience will differ among client applications. Some may hide, some may iconify, some may just do nothing... One could object that the logic is to be implemented in the toolkit, so all applications using the same toolkit will end up doing the same. But that still means that if we have, for example, an application using GTK+, another one using EFL, another one using toytoolkit (weston-terminal), they'll behave differently ? We'd really like to avoid that. Maybe a middle ground can be found if : 1) the desktop-shell-component can force a behaviour which WON'T touch any wl_surface nor wl_shell_surface state (i.e. no switch to any new MINIMIZED or whatever state, surface still considered fullscreen or maximized if it was before) 2) the client application can still get the response back, and react the way it wants Which would imply, taking the case of Weston : - if no desktop_shell_taskbar or whatever manager plugin is present as a module, then client app just gets its response, and react the way it wants ; - if it is present, then this plugin communicates with the compositor to enforce some behaviour, BUT the client app still react the way it wants. What do you think of that ? Regards, Tarnyko 2014-01-31 Manuel Bachmann : > Hi Bill, and thanks a lot for sharing your thoughts, > > > You must allow a "toplevel" to become a non-toplevel and vice-versa > > That's true ; the current implementation doesn't address this case. > > > My recommendation is that a surface has a "parent" that can be changed > at any time to any other surface or to NULL > > So for an application having a "main" surface (let's say, the first that > has been created) and child (transient ?) surfaces, the schema would be : > NULL -> shell_surface -> shell_surface -> shell_surface > |->shell_surface > > In that case, an implementation *could* just display a button for the > first shell_surface on the left, and minimize it and all its children at > the same time. Well, I suppose it's really something up to the actual > implementation, so a sample impl. could just do it the easiest way. > > > NO! The compositor must only send a "hide request" to the client. The > client MUST be in final control over when and how it's surfaces disappear. > > Have just been reading the other (old) thread on this issue, so I get your > objection :-). > I suppose I'll have to write a sample client application able to process > such a request. GTK+ seems to have an impl, so I will check what it does. > > > I'm not clear on why the former api can't do this and you felt a new api > had to be added. > > Well it's just a demo, I don't really feel like it should be merged in > this state.In fact, I'd like to avoid adding any API. > > > Taking your comments into account, here's what I think I should do next : > > - write a sample client able to send "xdg_shell_set_minimized()" requests, > and process the responses to it ; > - write a minimal implementation for a "taskbar/main_shell_surfaces_list" > (?) in the "shell" directory, and allow it to be built on demand ; > - make sure these 2 components communicate and react well. > > Thank you ; any further recommendation appreciated ! > > Regards, > Manuel > > > 2014-01-31 Bill Spitzak : > > >> - When the compositor creates a shell_surface having the TOPLEVEL type, >>> it sets a numeral ID for it, and sends a "map" event to the >>> desktop_shell client ; >>> >> >> You must allow a "toplevel" to become a non-toplevel and vice-versa, >> otherwise useful api for rearranging windows is impossible. My >> recommendation is that a surface has a "parent" that can be changed at any >> time to any other surface or to NULL, the only restriction is that a loop >> cannot be created. In any case please do not make a "type" called TOPLEVEL. >> >> >> - if it should be hidden, then the compositor sends the shell_surface to >>> a new >>> weston_layer named "taskbar_layer". This layer is not displayed at all. >>> >> >> NO! The compositor must only send a "hide request" to the client. The >> client MUST be in final control over when and how it's surfaces disappear. >> This is to allow it to atomically remove child surfaces or to reparent them >> to other surfaces that are not being hidden. >> >> >> When their "minimize" button is pressed, they now call a >>> taskbar_move_surface() >>> function which will do the former, and additionally send a hint to the >>> desktop_shell >>> that this has been done (so the corresponding taskbar button stays >>> tuned). >>> >> >> I'm not clear on why the former api can't do this and you felt a new api >> had to be added. >> > > > > -- > Regar
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
Hi Bill, and thanks a lot for sharing your thoughts, > You must allow a "toplevel" to become a non-toplevel and vice-versa That's true ; the current implementation doesn't address this case. > My recommendation is that a surface has a "parent" that can be changed at any time to any other surface or to NULL So for an application having a "main" surface (let's say, the first that has been created) and child (transient ?) surfaces, the schema would be : NULL -> shell_surface -> shell_surface -> shell_surface |->shell_surface In that case, an implementation *could* just display a button for the first shell_surface on the left, and minimize it and all its children at the same time. Well, I suppose it's really something up to the actual implementation, so a sample impl. could just do it the easiest way. > NO! The compositor must only send a "hide request" to the client. The client MUST be in final control over when and how it's surfaces disappear. Have just been reading the other (old) thread on this issue, so I get your objection :-). I suppose I'll have to write a sample client application able to process such a request. GTK+ seems to have an impl, so I will check what it does. > I'm not clear on why the former api can't do this and you felt a new api had to be added. Well it's just a demo, I don't really feel like it should be merged in this state.In fact, I'd like to avoid adding any API. Taking your comments into account, here's what I think I should do next : - write a sample client able to send "xdg_shell_set_minimized()" requests, and process the responses to it ; - write a minimal implementation for a "taskbar/main_shell_surfaces_list" (?) in the "shell" directory, and allow it to be built on demand ; - make sure these 2 components communicate and react well. Thank you ; any further recommendation appreciated ! Regards, Manuel 2014-01-31 Bill Spitzak : > > - When the compositor creates a shell_surface having the TOPLEVEL type, >> it sets a numeral ID for it, and sends a "map" event to the desktop_shell >> client ; >> > > You must allow a "toplevel" to become a non-toplevel and vice-versa, > otherwise useful api for rearranging windows is impossible. My > recommendation is that a surface has a "parent" that can be changed at any > time to any other surface or to NULL, the only restriction is that a loop > cannot be created. In any case please do not make a "type" called TOPLEVEL. > > > - if it should be hidden, then the compositor sends the shell_surface to >> a new >> weston_layer named "taskbar_layer". This layer is not displayed at all. >> > > NO! The compositor must only send a "hide request" to the client. The > client MUST be in final control over when and how it's surfaces disappear. > This is to allow it to atomically remove child surfaces or to reparent them > to other surfaces that are not being hidden. > > > When their "minimize" button is pressed, they now call a >> taskbar_move_surface() >> function which will do the former, and additionally send a hint to the >> desktop_shell >> that this has been done (so the corresponding taskbar button stays tuned). >> > > I'm not clear on why the former api can't do this and you felt a new api > had to be added. > -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR* ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak wrote: > > - When the compositor creates a shell_surface having the TOPLEVEL type, >> it sets a numeral ID for it, and sends a "map" event to the desktop_shell >> client ; >> > > You must allow a "toplevel" to become a non-toplevel and vice-versa, > otherwise useful api for rearranging windows is impossible. My > recommendation is that a surface has a "parent" that can be changed at any > time to any other surface or to NULL, the only restriction is that a loop > cannot be created. In any case please do not make a "type" called TOPLEVEL. > This type already exists in wl_shell_surface_set_toplevel. It says nothing about transient parents, only that it's a toplevel as opposed to a subsurface. Perhaps a misguided name, which is why xdg-shell removes the terminology. However, weston's shell.c still contains a type called "TOPLEVEL" since it started as an implementation for wl_shell_surface. > - if it should be hidden, then the compositor sends the shell_surface to a >> new >> weston_layer named "taskbar_layer". This layer is not displayed at all. >> > > NO! The compositor must only send a "hide request" to the client. The > client MUST be in final control over when and how it's surfaces disappear. > This is to allow it to atomically remove child surfaces or to reparent them > to other surfaces that are not being hidden. > Hiding windows should not have any influence over the client, as many desktop environments, including Weston, want to show live previews for minimized or hidden windows in alt-tab or Expose-alikes. Also, it matches user expectations. If the user clicks minimize on a window, they want it hidden, and they mean it, not get bested with "surprise! You tried to hide me but I resist by mapping my subsurfaces elsewhere!" > When their "minimize" button is pressed, they now call a >> taskbar_move_surface() >> function which will do the former, and additionally send a hint to the >> desktop_shell >> that this has been done (so the corresponding taskbar button stays tuned). >> > > I'm not clear on why the former api can't do this and you felt a new api > had to be added. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston : ideas about xdg_sell, and implementation for a taskbar
- When the compositor creates a shell_surface having the TOPLEVEL type, it sets a numeral ID for it, and sends a "map" event to the desktop_shell client ; You must allow a "toplevel" to become a non-toplevel and vice-versa, otherwise useful api for rearranging windows is impossible. My recommendation is that a surface has a "parent" that can be changed at any time to any other surface or to NULL, the only restriction is that a loop cannot be created. In any case please do not make a "type" called TOPLEVEL. - if it should be hidden, then the compositor sends the shell_surface to a new weston_layer named "taskbar_layer". This layer is not displayed at all. NO! The compositor must only send a "hide request" to the client. The client MUST be in final control over when and how it's surfaces disappear. This is to allow it to atomically remove child surfaces or to reparent them to other surfaces that are not being hidden. When their "minimize" button is pressed, they now call a taskbar_move_surface() function which will do the former, and additionally send a hint to the desktop_shell that this has been done (so the corresponding taskbar button stays tuned). I'm not clear on why the former api can't do this and you felt a new api had to be added. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
