Discussion:
Weston : ideas about xdg_sell, and implementation for a taskbar
(too old to reply)
Manuel Bachmann
2014-01-30 16:15:39 UTC
Permalink
Hi folks,

Where I work, we need to have some logic to manage surfaces from a client
point of view (application or toolkit). For example, we need to be able to :
- minimize (hide/show or more) surfaces, just like most desktop
environments allow ;
- manage layers, by arranging surfaces by z-orders e.g. ;
- ...

Having searched a bit, and because the core Wayland protocol does not
provide this, it seems that the xdg_shell protocol would be the way to go.

I just looked in the current Weston codebase, and found there are already
stubbed implementations for xdg_shell_set_minimize() e.g.. I plan to write
a minimal implementation adding the call handling to shell.c, and a new
taskbar.c plugin eventually receiving calls.
-----
As a proof-of-concept, I just wrote a patch for weston 1.3.x that
implements all the logic needed for a graphical taskbar, and manages
minimization/raise events for surfaces.

Here's the patched version, which basically modifies shell, desktop_shell
and toytoolkit :
https://github.com/Tarnyko/weston-taskbar

Here are some screenshots :
Loading Image...
Loading Image...

And for the lazy ;-) , here is a video :

-----
Here's how it works :

- 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 ;

- the desktop_shell client receives the event, and then creates a
button on the taskbar associated with this ID. If the surface has a title
(typically set client-side with wl_shell_surface_set_title()), the button
will display it ; otherwise it will just contain "Default:<ID>".

- when the button is clicked, and the window is shown, it asks the
compositor
to hide it... or asks the contrary in the other case ;-) ;

- 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. If
it
shouldn't, then it's moved back to the current workspace layer.

- lots of weston clients use the toytoolkit library ("weston-terminal"
e.g.).
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).
---

As lots of code changed in 1.4, and xdg_shell interface is now implemented,
I will try to port it to git master along with xdg_shell additions.

Comments on this subject are very welcome !

PS : I will be at FOSDEM this w-e (
https://fosdem.org/2014/schedule/event/porting_legacy_x11_to_wayland/) if
anyone wants to discuss the subject with me.
--
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140130/b8e741d9/attachment.html>
Bill Spitzak
2014-01-30 23:31:33 UTC
Permalink
Post by Manuel Bachmann
- 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.
Post by Manuel Bachmann
- 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.
Post by Manuel Bachmann
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.
Jasper St. Pierre
2014-01-31 00:27:17 UTC
Permalink
Post by Manuel Bachmann
- When the compositor creates a shell_surface having the TOPLEVEL type,
Post by Manuel Bachmann
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.
Post by Manuel Bachmann
- if it should be hidden, then the compositor sends the shell_surface to a
Post by Manuel Bachmann
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!"
Post by Manuel Bachmann
When their "minimize" button is pressed, they now call a
Post by Manuel Bachmann
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140130/bf63d0ea/attachment.html>
Bill Spitzak
2014-01-31 01:48:56 UTC
Permalink
Post by Jasper St. Pierre
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.
Jasper St. Pierre
2014-01-31 01:52:52 UTC
Permalink
Post by Jasper St. Pierre
Hiding windows should not have any influence over the client, as many
Post by Jasper St. Pierre
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.
Post by Jasper St. Pierre
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140130/b30a7506/attachment.html>
Bill Spitzak
2014-01-31 02:03:00 UTC
Permalink
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Jasper St. Pierre
2014-01-31 02:08:19 UTC
Permalink
Post by Bill Spitzak
A simple problem is a floating window shared by two main windows.
Post by Jasper St. Pierre
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?
Post by Bill Spitzak
since there are a billion other ways a client can misbehave and you
Post by Jasper St. Pierre
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140130/7f5f5444/attachment.html>
Bill Spitzak
2014-01-31 06:11:39 UTC
Permalink
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Manuel Bachmann
2014-02-10 15:25:34 UTC
Permalink
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

-
Post by Bill Spitzak
A toolbox over a painting program that has two documents open.
Post by Jasper St. Pierre
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
Post by Jasper St. Pierre
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.
Post by Jasper St. Pierre
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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140210/d7d8bab3/attachment.html>
Giulio Camuffo
2014-02-10 15:33:26 UTC
Permalink
2014-02-10 17:25 GMT+02:00 Manuel Bachmann
Post by Manuel Bachmann
Hi Bill, hi Jasper, hi everybody again,
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
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
- there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized
- when a client using toytoolkit (weston-terminal for instance) wants to be
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
xdg_surface_send_request_set_minimized(shsurf->resource);
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.
Post by Manuel Bachmann
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
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,
"client->compositor->shell" / "shell->compositor->client".
What do you think of this ?
Regards,
Manuel
-
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Manuel Bachmann
2014-02-10 15:43:46 UTC
Permalink
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,
Post by Giulio Camuffo
2014-02-10 17:25 GMT+02:00 Manuel Bachmann
Post by Manuel Bachmann
Hi Bill, hi Jasper, hi everybody again,
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
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
Post by Manuel Bachmann
- there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized
- when a client using toytoolkit (weston-terminal for instance) wants to
be
Post by Manuel Bachmann
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
xdg_surface_send_request_set_minimized(shsurf->resource);
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.
Post by Manuel Bachmann
and in the specific case of toytoolkit, decides to suspend the redraw
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
Post by Manuel Bachmann
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,
Post by Manuel Bachmann
"client->compositor->shell" / "shell->compositor->client".
What do you think of this ?
Regards,
Manuel
-
Post by Bill Spitzak
Post by Bill Spitzak
A toolbox over a painting program that has two documents open.
So, what is the expected behavior here exactly? There's a minimize
button
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
What should using the "minimize keyboard shortcut" functionality of
your
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
compositor do? Should it differ from using the button in the UI? What
does
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
wired to do nothing), and while it's certainly frustrating from a user
perspective, the compositor can still forcibly minimize or close the
window.
Post by Manuel Bachmann
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
can decide to not close (ideally by asking the user if they are sure,
and
Post by Manuel Bachmann
Post by Bill Spitzak
the user says no). If it just killed the app or destroyed the window
that
Post by Manuel Bachmann
Post by Bill Spitzak
could be very user-unfriendly and I am rather suprised anybody would
suggest
Post by Manuel Bachmann
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140210/eb75fb31/attachment.html>
Manuel Bachmann
2014-02-10 15:45:41 UTC
Permalink
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 <
Post by Manuel Bachmann
Hi Guilio,
In fact, the client will be hidden anyway, because in order to keep some
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.).
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 17:25 GMT+02:00 Manuel Bachmann
Post by Manuel Bachmann
Post by Manuel Bachmann
Hi Bill, hi Jasper, hi everybody again,
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
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
Post by Manuel Bachmann
- there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized
- when a client using toytoolkit (weston-terminal for instance) wants
to be
Post by Manuel Bachmann
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
xdg_surface_send_request_set_minimized(shsurf->resource);
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.
Post by Manuel Bachmann
and in the specific case of toytoolkit, decides to suspend the redraw
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
Post by Manuel Bachmann
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,
Post by Manuel Bachmann
"client->compositor->shell" / "shell->compositor->client".
What do you think of this ?
Regards,
Manuel
-
Post by Bill Spitzak
Post by Bill Spitzak
A toolbox over a painting program that has two documents open.
So, what is the expected behavior here exactly? There's a minimize
button
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
on both of the content window's decorations, and clicking on one
should
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
both the document and toolbox disappear.
Post by Bill Spitzak
What should using the "minimize keyboard shortcut" functionality of
your
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
compositor do? Should it differ from using the button in the UI? What
does
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
wired to do nothing), and while it's certainly frustrating from a user
perspective, the compositor can still forcibly minimize or close the
window.
Post by Manuel Bachmann
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Bill Spitzak
can decide to not close (ideally by asking the user if they are sure,
and
Post by Manuel Bachmann
Post by Bill Spitzak
the user says no). If it just killed the app or destroyed the window
that
Post by Manuel Bachmann
Post by Bill Spitzak
could be very user-unfriendly and I am rather suprised anybody would
suggest
Post by Manuel Bachmann
Post by Bill Spitzak
that.
If an app is non-cooperative the compositor can do some stuff. For
close
Post by Manuel Bachmann
Post by Bill Spitzak
it can kill the client if it is not responding to pings. Minimize
probably
Post by Manuel Bachmann
Post by Bill Spitzak
should also force-hide the surface after a timeout even if the client
is
Post by Manuel Bachmann
Post by Bill Spitzak
responding to pings. However this fallback stuff should not be part of
the
Post by Manuel Bachmann
Post by Bill Spitzak
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Regards,
*Manuel BACHMANN Tizen Project VANNES-FR*
--
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140210/5555a0b0/attachment-0001.html>
Giulio Camuffo
2014-02-10 15:54:49 UTC
Permalink
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
Post by Manuel Bachmann
Hi Guilio,
In fact, the client will be hidden anyway, because in order to keep some
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.).
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,
Post by Giulio Camuffo
2014-02-10 17:25 GMT+02:00 Manuel Bachmann
Post by Manuel Bachmann
Hi Bill, hi Jasper, hi everybody again,
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
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
- there are 2 new compositor-to-client requests in "xdg_shell.xml" (not
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized
- when a client using toytoolkit (weston-terminal for instance) wants to be
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
xdg_surface_send_request_set_minimized(shsurf->resource);
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.
Post by Manuel Bachmann
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
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,
"client->compositor->shell" / "shell->compositor->client".
What do you think of this ?
Regards,
Manuel
-
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Regards,
Manuel BACHMANN
Tizen Project
VANNES-FR
--
Regards,
Manuel BACHMANN
Tizen Project
VANNES-FR
Manuel Bachmann
2014-02-10 16:21:05 UTC
Permalink
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
Post by 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
Post by Manuel Bachmann
Oh, and I forgot to add, the taskbar has its own logic asking the
compositor
Post by Manuel Bachmann
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
Post by Manuel Bachmann
Hi Guilio,
In fact, the client will be hidden anyway, because in order to keep some
https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385
Post by Manuel Bachmann
Post by Manuel Bachmann
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
Post by Manuel Bachmann
Post by Manuel Bachmann
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,
Post by Giulio Camuffo
2014-02-10 17:25 GMT+02:00 Manuel Bachmann
Post by Manuel Bachmann
Hi Bill, hi Jasper, hi everybody again,
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
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
- there are 2 new compositor-to-client requests in "xdg_shell.xml"
(not
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized
- when a client using toytoolkit (weston-terminal for instance) wants to be
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
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
xdg_surface_send_request_set_minimized(shsurf->resource);
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.
Post by Manuel Bachmann
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
window_schedule_redraw (window);
So a video player, for example, could cpntinue playing sound but
avoid
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
decoding some frames.
BTW, if you remove the last commit of my code, the logic is compositor-only,
"client->compositor->shell" / "shell->compositor->client".
What do you think of this ?
Regards,
Manuel
-
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
What should using the "minimize keyboard shortcut" functionality of your
compositor do? Should it differ from using the button in the UI?
What
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
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.
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
forcibly minimizing a window with e.g. a keyboard shortcut?
The former is an application bug (the button does nothing because
it
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
was
wired to do nothing), and while it's certainly frustrating from a user
perspective, the compositor can still forcibly minimize or close
the
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
Post by Bill Spitzak
window.
I would expect that a compositor shortcut key to close a window
would
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
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,
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
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
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
is
responding to pings. However this fallback stuff should not be part
of
Post by Manuel Bachmann
Post by Manuel Bachmann
Post by Giulio Camuffo
Post by Manuel Bachmann
Post by Bill Spitzak
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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Regards,
Manuel BACHMANN
Tizen Project
VANNES-FR
--
Regards,
Manuel BACHMANN
Tizen Project
VANNES-FR
--
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140210/9184bbc5/attachment-0001.html>
Bill Spitzak
2014-02-10 20:57:27 UTC
Permalink
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).
Post by Manuel Bachmann
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.
sardemff7+wayland
2014-02-10 21:44:07 UTC
Permalink
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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
Bill Spitzak
2014-02-10 22:42:52 UTC
Permalink
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
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
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.
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
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.
sardemff7+wayland
2014-02-10 23:06:56 UTC
Permalink
(Some parts are reordered to makes more sense in my answers. Agreed
parts are removed.)
Post by Bill Spitzak
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
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.
Post by Bill Spitzak
Post by sardemff7+wayland
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.
Post by Bill Spitzak
Post by sardemff7+wayland
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
Actually after I typed this I think there may be a scheme that works
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.
Post by Bill Spitzak
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
(while hovering the taskbar item associated to the surface).

Thanks,
--
Quentin ?Sardem FF7? Glidic
Bill Spitzak
2014-02-11 01:23:00 UTC
Permalink
Post by sardemff7+wayland
Post by Bill Spitzak
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.
Post by sardemff7+wayland
Post by Bill Spitzak
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
Post by Bill Spitzak
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
Post by Bill Spitzak
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.
Post by sardemff7+wayland
Post by Bill Spitzak
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.
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
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).
Yes I agree
Post by sardemff7+wayland
2. On .request_set_minimized, the client is free to reparent other
surfaces to keep its UI in a consistent state.
This MUST be done before any visible change happens on-screen, so that
these changes are atomic with the minimized window disappearing.
Therefore there must be some kind of "commit" for the client to tell the
compositor to finish the minimize.
Post by sardemff7+wayland
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.
The communication can't be just unfocus because it is possible to
minimize and un-minimize unfocused windows.
Post by sardemff7+wayland
It should work in all cases, especially the thumbnails preview: the
surface is drawn inactive but updated as soon as the preview is visible
(while hovering the taskbar item associated to the surface).
Not sure what you meant by that. I'm pretty certain that once the app is
minimized it will work exactly the way you are saying with previews.
sardemff7+wayland
2014-02-11 11:27:23 UTC
Permalink
Post by Bill Spitzak
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.
Post by Bill Spitzak
I certainly want to allow this! And I certainly want to support
minimizing multiple surfaces.
I agree, it is needed.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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).
Post by Bill Spitzak
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.
Post by Bill Spitzak
It sounds like you are describing the 3-way communication I
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.
Post by Bill Spitzak
[?]
The rest of your email should be answered already.


Thanks,
--
Quentin ?Sardem FF7? Glidic
Bill Spitzak
2014-02-11 20:26:30 UTC
Permalink
Post by sardemff7+wayland
Post by Bill Spitzak
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.
Post by sardemff7+wayland
Post by Bill Spitzak
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.
Post by sardemff7+wayland
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.
Post by sardemff7+wayland
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
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.
Bill Spitzak
2014-02-10 20:42:06 UTC
Permalink
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".
Post by Manuel Bachmann
Hi Bill, hi Jasper, hi everybody again,
https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
And with regards to our former conversation, I added a logic that allows
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
Manuel Bachmann
2014-01-31 00:37:10 UTC
Permalink
Hi Bill, and thanks a lot for sharing your thoughts,
Post by Bill Spitzak
You must allow a "toplevel" to become a non-toplevel and vice-versa
That's true ; the current implementation doesn't address this case.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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
Post by Bill Spitzak
- When the compositor creates a shell_surface having the TOPLEVEL type,
Post by Manuel Bachmann
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
Post by Manuel Bachmann
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
Post by Manuel Bachmann
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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140131/7fe6b405/attachment-0001.html>
Manuel Bachmann
2014-01-31 01:23:12 UTC
Permalink
Well, having read Jasper's comment, he has some valid points, the most
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
Hi Bill, and thanks a lot for sharing your thoughts,
Post by Bill Spitzak
You must allow a "toplevel" to become a non-toplevel and vice-versa
That's true ; the current implementation doesn't address this case.
Post by Bill Spitzak
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
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.
Post by Bill Spitzak
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.
Post by Bill Spitzak
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.
----
- 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
Post by Bill Spitzak
- When the compositor creates a shell_surface having the TOPLEVEL type,
Post by Manuel Bachmann
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
Post by Manuel Bachmann
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
Post by Manuel Bachmann
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*
--
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140131/452fd3b0/attachment.html>
Bill Spitzak
2014-01-31 01:59:55 UTC
Permalink
Post by Manuel Bachmann
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.
Loading...