<div dir="ltr">On Sun, Aug 6, 2017 at 11:11 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jul 25, 2017 at 08:07:01AM -0600, Matt Hoosier wrote:<br>
> On Tue, Jul 25, 2017 at 7:26 AM, Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
><br>
> > On Tue, Jul 25, 2017 at 06:42:34AM -0600, Matt Hoosier wrote:<br>
> > > I'd find it a little bit inconvenient for the title, class, and app-id to<br>
> > > be treated as buffered state. They make a great poor-man's way of<br>
> > > identifying surfaces for embedded systems that implement simple layer<br>
> > > management policies without wholesale adopting IVI shell (whose lack of<br>
> > > wl_shell makes it difficult to integrate off-the-rack Wayland libraries<br>
> > and<br>
> > > apps). Since the surface title doesn't have anything to do with correct<br>
> > > graphical presentation, it'd be nicer if that data is just available<br>
> > > immediately to the rest of the shell rather than being something that<br>
> > only<br>
> > > trickles in whenever the app happens to post a buffer next.<br>
> ><br>
> > There is no need to attach a new buffer to commit a new state. One could<br>
> > for example commit a state only changing the title and nothing else, and<br>
> > it'd be completely correct. The benefit of synchronizing it is for<br>
> > example that a shell can synchronously change some overlay with the<br>
> > content.<br>
> ><br>
><br>
> Yes, agreed. But that's not the way that the Wayland backends of big<br>
> programming frameworks like Qt, Gtk+, etc work. In practice, you need to<br>
> trigger rendering if you want a commit to happen.<br>
<br>
</span>Toolkits could make this work (i.e. just call wl_surface_commit() after<br>
setting the title), I'm sure of, but indeed it could complicate things,<br>
as they need to make sure not to set any pending state too early. For<br>
example gtk did this poorly before, but has since been improved.<br>
<br>
Not sure this slight complication is a reason to not apply the title on<br>
commit though.<br>
<span class=""><br>
><br>
><br>
> ><br>
> > Regarding the app_id, the app_id should normally only ever be set once,<br>
> > as part of the initial state that doesn't have a buffer attached yet.<br>
> ><br>
><br>
> That's a fair point. The title can still change at will though, can't it?<br>
<br>
</span>Yes it can.<br>
<span class=""><br>
> Isn't the regular old window title what gets used to show things like the<br>
> working directly in an xterm or the name of the currently-edited document<br>
> in a word processor?<br>
<br>
</span>Right. The potential purpose of making set_title etc be applied on<br>
commit would be to update for example the window title text in the gnome<br>
shell overview (or any equivalent presentation) at the exact same time<br>
as the content of the document is updated.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jonas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> ><br>
> ><br>
> > Jonas<br>
> ><br>
> > ><br>
> > > On Tue, Jul 25, 2017 at 12:17 AM, Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
> > ><br>
> > > > On Fri, Jul 21, 2017 at 05:21:38PM +0200, Quentin Glidic wrote:<br>
> > > > > On 7/20/17 4:33 PM, Matt Hoosier wrote:<br>
> > > > > > It's useful for the shell implementation to know when these change,<br>
> > > > > > for example to relay the information on to taskbars or similar.<br>
> > > > ><br>
> > > > > The idea is good, we need something like that. (But maybe not, see<br>
> > > > below).<br>
> > > > ><br>
> > > > ><br>
> > > > > > To avoid ABI changes or the need to make the weston_desktop_surface<br>
> > > > > > definition public, new functions are introduced for attaching<br>
> > > > > > listeners to these signals.<br>
> > > > ><br>
> > > > > We don’t care that much about ABI changes, but you’re right that I do<br>
> > > > care<br>
> > > > > about the struct staying private.<br>
> > > > ><br>
> > > > ><br>
> > > > > > Signed-off-by: Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>><br>
> > > > > > ---<br>
> > > > > >   libweston-desktop/libweston-<wbr>desktop.h |  6 ++++++<br>
> > > > > >   libweston-desktop/surface.c           | 21 +++++++++++++++++++++<br>
> > > > > >   2 files changed, 27 insertions(+)<br>
> > > > > ><br>
> > > > > > diff --git a/libweston-desktop/libweston-<wbr>desktop.h<br>
> > > > b/libweston-desktop/libweston-<wbr>desktop.h<br>
> > > > > > index 03b04c7..e38257e 100644<br>
> > > > > > --- a/libweston-desktop/libweston-<wbr>desktop.h<br>
> > > > > > +++ b/libweston-desktop/libweston-<wbr>desktop.h<br>
> > > > > > @@ -164,6 +164,12 @@ weston_desktop_surface_set_<wbr>size(struct<br>
> > > > weston_desktop_surface *surface,<br>
> > > > > >                             int32_t width, int32_t height);<br>
> > > > > >   void<br>
> > > > > >   weston_desktop_surface_close(<wbr>struct weston_desktop_surface<br>
> > > > *surface);<br>
> > > > > > +void<br>
> > > > > > +weston_desktop_surface_add_<wbr>title_listener(struct<br>
> > > > weston_desktop_surface *surface,<br>
> > > > > > +                                     struct wl_listener<br>
> > *listener);<br>
> > > > > > +void<br>
> > > > > > +weston_desktop_surface_add_<wbr>app_id_listener(struct<br>
> > > > weston_desktop_surface *surface,<br>
> > > > > > +                                      struct wl_listener<br>
> > *listener);<br>
> > > > > >   void *<br>
> > > > > >   weston_desktop_surface_get_<wbr>user_data(struct<br>
> > weston_desktop_surface<br>
> > > > *surface);<br>
> > > > > > diff --git a/libweston-desktop/surface.c<br>
> > b/libweston-desktop/surface.c<br>
> > > > > > index d3be936..97a455c 100644<br>
> > > > > > --- a/libweston-desktop/surface.c<br>
> > > > > > +++ b/libweston-desktop/surface.c<br>
> > > > > > @@ -64,6 +64,8 @@ struct weston_desktop_surface {<br>
> > > > > >             char *title;<br>
> > > > > >             char *app_id;<br>
> > > > > >             pid_t pid;<br>
> > > > > > +           struct wl_signal title_signal;<br>
> > > > > > +           struct wl_signal app_id_signal;<br>
> > > > > >     };<br>
> > > > > >     struct {<br>
> > > > > >             struct weston_desktop_surface *parent;<br>
> > > > > > @@ -287,6 +289,9 @@ weston_desktop_surface_create(<wbr>struct<br>
> > > > weston_desktop *desktop,<br>
> > > > > >     wl_list_init(&surface->view_<wbr>list);<br>
> > > > > >     wl_list_init(&surface->grab_<wbr>link);<br>
> > > > > > +   wl_signal_init(&surface-><wbr>title_signal);<br>
> > > > > > +   wl_signal_init(&surface->app_<wbr>id_signal);<br>
> > > > > > +<br>
> > > > > >     return surface;<br>
> > > > > >   }<br>
> > > > > > @@ -511,6 +516,20 @@ weston_desktop_surface_close(<wbr>struct<br>
> > > > weston_desktop_surface *surface)<br>
> > > > > ><br>
> > > > surface->implementation_data);<br>
> > > > > >   }<br>
> > > > > > +WL_EXPORT void<br>
> > > > > > +weston_desktop_surface_add_<wbr>title_listener(struct<br>
> > > > weston_desktop_surface *surface,<br>
> > > > > > +                                     struct wl_listener *listener)<br>
> > > > > > +{<br>
> > > > > > +   wl_signal_add(&surface->title_<wbr>signal, listener);<br>
> > > > > > +}<br>
> > > > > > +<br>
> > > > > > +WL_EXPORT void<br>
> > > > > > +weston_desktop_surface_add_<wbr>app_id_listener(struct<br>
> > > > weston_desktop_surface *surface,<br>
> > > > > > +                                      struct wl_listener<br>
> > *listener)<br>
> > > > > > +{<br>
> > > > > > +   wl_signal_add(&surface->app_<wbr>id_signal, listener);<br>
> > > > > > +}<br>
> > > > > > +<br>
> > > > > >   struct weston_desktop_surface *<br>
> > > > > >   weston_desktop_surface_from_<wbr>client_link(struct wl_list *link)<br>
> > > > > >   {<br>
> > > > > > @@ -687,6 +706,7 @@ weston_desktop_surface_set_<wbr>title(struct<br>
> > > > weston_desktop_surface *surface,<br>
> > > > > >     free(surface->title);<br>
> > > > > >     surface->title = tmp;<br>
> > > > > > +   wl_signal_emit(&surface-><wbr>title_signal, surface->title);<br>
> > > > ><br>
> > > > > I would rather pass the surface as the signal data. Just in case we<br>
> > have<br>
> > > > in<br>
> > > > > the future a value that doesn’t fit in a pointer. And calling a<br>
> > getter is<br>
> > > > > not that bad.<br>
> > > > ><br>
> > > > > Also, I prefer to have one signal only, it would reduce the API size<br>
> > (and<br>
> > > > > avoid it growing too much in the future, since it could work in this<br>
> > > > case).<br>
> > > > > We can move the free() to keep both pointer around until after the<br>
> > signal<br>
> > > > > fired, and a simple pointer comparison will work (if you stored the<br>
> > > > "const<br>
> > > > > char *" directly, which you should as with the signal, we guarantee<br>
> > it<br>
> > > > will<br>
> > > > > exist until destroy or signal).<br>
> > > > ><br>
> > > > ><br>
> > > > > But it raised a question : Jonas, are set_title() and set_app_id()<br>
> > > > supposed<br>
> > > > > to be active without a commit()?<br>
> > > ><br>
> > > > No. As per specification they are not tied to wl_surface.commit(). I<br>
> > > > suppose it is something we can change though, while we can, if it makes<br>
> > > > any sense. Opinions?<br>
> > > ><br>
> > > ><br>
> > > > Jonas<br>
> > > ><br>
> ><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Okay. Well, I'm not sure how you'd like this to proceed. Are you planning to update the spec to require that set_title and set_app_id are buffered? Or is that too much effort and you'd rather than libweston-desktop just gets a patch like what I proposed to allow the state-change to become visible when it arrives?</div></div>