Fwd: [PATCH weston] xdg-shell: Make stable

Mon Jul 21 10:07:00 PDT 2014

On Sat, Jul 19, 2014 at 12:46 AM, Manuel Bachmann <
manuel.bachmann at open.eurogiciel.org> wrote:

> Hi Jasper, Jaspon, thanks for taking good arguments to the table,
>
> "Destroying and creating an xdg_surface will, certainly."
>
> Yes, that's what we have been doing for some time, but it has the serious
> drawback that the new surface will not be positioned the same.
>
> "xdg_surface_present_window()"
>
> "window" may be an excessive high-level word ; what do you think of
> "xdg_surface_present()" alone ?
>
> "I do want to make the guarantee that it isn't "immediate""
> "The point here is that we don't want minimize/unminimize to get abused by
> apps."
>
> I fully understand this. One on the reasons the patch was still WIP is
> that I wanted to avoid application abuses of this API -by trying to steal
> the focus or to keep their window constantly in foreground by
> minimizing/unminimizing quickly e.g..
>
> "So, what is the use case for unset_minimized?"
>
> Take the case when an application has been minimized, and an event happens
> (nerdopolis gave the case of opening a new document, could be an alert) the
> application wants you to know so you can easily bring its surface back if
> needed.
>
> "Unfortunately, toolkits really like to work in terms of show/hide which,
> while easy, doesn't fit exactly."
>
> Agreed. In the EFL, we mapped "xdg_surface_set_minimized()" to
> "ecore_wl_window_iconified_set()". One could argue about the "iconified"
> word ; however we didn't want to use "hide()" which does something
> different.
>
> "when a window gets unminimized and things of that nature
> need to be determined by two things:  App intentions communicated to the
> compositor, and compositor policy.  If the app has important information
> for the user, it should indicate that to the compositor.  The compositor
> can then respond by showing the window, switching workspaces, making
> something blink/bounce, etc. depending on its *policy*.  For something like
> Tizen, that could be "if the app has the focus-stealing permission, show
> the window, otherwise blink the notification bar" or something like that."
>
> I think you summed it up nicely. We want the window to be able to be shown
> back, however not in all cases.
>
> I could demonstrate the API use case by doing the following in a temp
> Weston patch : if an application sends the "xdg_surface_present()" request,
> then a little blinking balloon, technically similar to a panel tooltip,
> will appear at the bottom of the screen for some time.
> When clicked, the balloon would then make the surface appear back on the
> current screen, positioned as it was before.
>
> What do you think of that ?
>
That seems reasonable.  As you mentioned on IRC, this could be an excuse
for your task-bar.  I have nothing against the idea of a task-bar, I just
never got around to looking that hard at the patches.
--Jason Ekstrand

>
>
> 2014-07-18 18:55 GMT+02:00 Jason Ekstrand <jason at jlekstrand.net>:
>
>
>>
>>
>> On Fri, Jul 18, 2014 at 5:31 AM, nerdopolis <
>> bluescreen_avenger at verizon.net> wrote:
>>
>>> On Friday, July 18, 2014 08:25:33 AM Jasper St. Pierre wrote:
>>> > The lack of an unset_minimized feature is very intentional. The
>>> *goal*, it
>>> > sounds like, is to present the window immediately again, but an
>>> > unset_minimized won't do that. What if the window is on a different
>>> > workspace, or has been simply stacked behind another set of windows?
>>> >
>>> > unset_minimized won't solve any of these issues. Destroying and
>>> creating an
>>> > xdg_surface will, certainly.
>>> >
>>> > If there's a valid use case, and I'm *very* skeptical that there is, I
>>> > would be fine in "present_window" request that tries as hard as
>>> possible to
>>> > present the window to the user (unminimizing, changing workspaces,
>>> stacking
>>> > to the top). However, I do want to make the guarantee that it isn't
>>> > immediate. Compositors may implement this request by instead showing a
>>> > blinking icon in the taskbar, to prevent an application from suddenly
>>> > stealing the user's focus.
>>> >
>>> > So, what is the use case for unset_minimized?
>>> >
>>> I know for example when I open and minimize kate, (text editor), and
>>> then I open another text file from my file manager, the existing kate
>>> window unmimimizes itself, and opens the second file in the same window,
>>> instead of staying minimized.
>>>
>>> I feel if kate didn't have this feature, if it was minimized, and unable
>>> to unmiminize itself, it's probably easy to forget about the existing
>>> instance, and it would seem irresponsive...
>>>
>>
>> I really like Jasper's "present" request solution to this problem. (It
>> could probably also be called "attention").  If kwin wants to implement
>> that as "move to the appropriate workspace and unminimize, then it can do
>> that.  Otherwise, it could start flashing the task-bar icon or something.
>>
>> The point here is that we don't want minimize/unminimize to get abused by
>> apps.  The *only* reason for a minimized request is to allow an app to ask
>> to be minimized.  That is all.  It is *not* so that the app can know if
>> it's minimzied and stop drawing or so that it can show/hide itself.  We
>> want to make the protocol describe the intention of the app, not the exact
>> thing to do on-screen.  In the case of the kate example, the intention of
>> kate is that is has new content now (requested by the user) that it would
>> like the user to see.  It is asking for the user's attention.  You could
>> make the argument that the create/destroy solution is also acceptable since
>> you are effectively creating a new window that just happens to contain the
>> old tab.  That said, I think I'd rather go with present/attention for that.
>>
>> Unfortunately, toolkits really like to work in terms of show/hide which,
>> while easy, doesn't fit exactly.  That does mean that xdg_shell needs to be
>> the one to change.  The other problem is that app developers tend to get an
>> idea in their head of exactly what they want the user's workflow to look
>> like and then try to make their app do exactly that.  This usually doesn't
>> result in as good of an overall user experience as the app developer thinks
>> it will.  Also, it results in the compositor and the app fighting with app
>> developers constantly trying to find new ways of making the window manage
>> do exactly what they want and window managers trying to corral apps.
>> Allowing the app any sort absolute control is also dangerous because as
>> soon as you provide a protocol that allows the client to boss the
>> compositor around, it *will* be abused.
>>
>> To sum things up, when a window gets unminimized and things of that
>> nature need to be determined by two things:  App intentions communicated to
>> the compositor, and compositor policy.  If the app has important
>> information for the user, it should indicate that to the compositor.  The
>> compositor can then respond by showing the window, switching workspaces,
>> making something blink/bounce, etc. depending on its *policy*.  For
>> something like Tizen, that could be "if the app has the focus-stealing
>> permission, show the window, otherwise blink the notification bar" or
>> something like that.  However, allowing the app to say "you need to show me
>> now" and being able to expect that its demand will be followed to the
>> letter will be bad news.
>>
>> --Jason Ekstrand
>>
>> >
>>> > On Fri, Jul 18, 2014 at 7:33 AM, Philippe Coval <
>>> > philippe.coval at open.eurogiciel.org> wrote:
>>> >
>>> > >
>>> > >> We've gone through enough churn of xdg-shell that we're now feeling
>>> > >> confident enough to commit to this much. Let's do it.
>>> > >>
>>> > >
>>> > > Ok good news, I guess you're want to gather some feedback
>>> > > before it lands into next release
>>> > >
>>> > > As a qtwayland developer it seems ok for us
>>> > > (note current master branch is aligned to latest release wl-1.5)
>>> > > may giucam confirm too,
>>> > > I'll probably upgrade to 1.6 soon or later...
>>> > >
>>> > >
>>> > > But as mentionned in
>>> > >
>>> > > https://bugs.freedesktop.org/show_bug.cgi?id=53214
>>> > >
>>> > > We at Tizen feels the unset_minimized request is missing
>>> > > (may it be part of the states enum too ?)
>>> > >
>>> > >
>>> > > If we compare to maximize both are there :
>>> > >
>>> > >    <request name="set_maximized" />
>>> > >    <request name="unset_maximized" />
>>> > >
>>> > >
>>> > > While there is only :
>>> > >
>>> > >    <request name="set_minimized" />
>>> > >
>>> > >
>>> > > Would it make sense to add this one :
>>> > >
>>> > >    <request name="unset_minimized" />
>>> > >
>>> > >
>>> > > I supose it's not there because there is no real need,
>>> > > but it wasnt intentional please confirm ?
>>> > >
>>> > > We can share some patches if it maters.
>>> > >
>>> > > To be tracked here and at  :
>>> > >
>>> > > https://bugs.freedesktop.org/show_bug.cgi?id=53214
>>> > >
>>> > >
>>> > > Regards
>>> > >
>>> > >
>>> > > --
>>> > >  mailto:philippe.coval at eurogiciel.fr  --  gpg:0x467094BC
>>> > >  xmpp:philippe.coval.pro at gmail.com
>>> > >  https://dockr.eurogiciel.fr/blogs/embedded/author/pcl/
>>> > >
>>>    .
>>> > >
>>> > > _______________________________________________
>>> > > wayland-devel mailing list
>>> > > wayland-devel at lists.freedesktop.org
>>> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>> > >
>>> >
>>> >
>>> >
>>> >
>>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>
>>
>> _______________________________________________
>> 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/20140721/7d7cefa6/attachment.html>