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

Fri Jul 18 09:55:46 PDT 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140718/f13ac169/attachment.html>