<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 18, 2014 at 5:31 AM, nerdopolis <span dir="ltr"><<a href="mailto:bluescreen_avenger@verizon.net" target="_blank">bluescreen_avenger@verizon.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Friday, July 18, 2014 08:25:33 AM Jasper St. Pierre wrote:<br>
> The lack of an unset_minimized feature is very intentional. The *goal*, it<br>
> sounds like, is to present the window immediately again, but an<br>
> unset_minimized won't do that. What if the window is on a different<br>
> workspace, or has been simply stacked behind another set of windows?<br>
><br>
> unset_minimized won't solve any of these issues. Destroying and creating an<br>
> xdg_surface will, certainly.<br>
><br>
> If there's a valid use case, and I'm *very* skeptical that there is, I<br>
> would be fine in "present_window" request that tries as hard as possible to<br>
> present the window to the user (unminimizing, changing workspaces, stacking<br>
> to the top). However, I do want to make the guarantee that it isn't<br>
> immediate. Compositors may implement this request by instead showing a<br>
> blinking icon in the taskbar, to prevent an application from suddenly<br>
> stealing the user's focus.<br>
><br>
> So, what is the use case for unset_minimized?<br>
><br>
</div>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.<br>

<br>
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...<br></blockquote><div><br>
</div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>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.<br>
</div><div><br></div><div>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.<br>
<br></div><div>--Jason Ekstrand<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">><br>
> On Fri, Jul 18, 2014 at 7:33 AM, Philippe Coval <<br>
> <a href="mailto:philippe.coval@open.eurogiciel.org">philippe.coval@open.eurogiciel.org</a>> wrote:<br>
><br>
> ><br>
> >> We've gone through enough churn of xdg-shell that we're now feeling<br>
> >> confident enough to commit to this much. Let's do it.<br>
> >><br>
> ><br>
> > Ok good news, I guess you're want to gather some feedback<br>
> > before it lands into next release<br>
> ><br>
> > As a qtwayland developer it seems ok for us<br>
> > (note current master branch is aligned to latest release wl-1.5)<br>
> > may giucam confirm too,<br>
> > I'll probably upgrade to 1.6 soon or later...<br>
> ><br>
> ><br>
> > But as mentionned in<br>
> ><br>
> > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=53214" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=53214</a><br>
> ><br>
> > We at Tizen feels the unset_minimized request is missing<br>
> > (may it be part of the states enum too ?)<br>
> ><br>
> ><br>
> > If we compare to maximize both are there :<br>
> ><br>
> >    <request name="set_maximized" /><br>
> >    <request name="unset_maximized" /><br>
> ><br>
> ><br>
> > While there is only :<br>
> ><br>
> >    <request name="set_minimized" /><br>
> ><br>
> ><br>
> > Would it make sense to add this one :<br>
> ><br>
> >    <request name="unset_minimized" /><br>
> ><br>
> ><br>
> > I supose it's not there because there is no real need,<br>
> > but it wasnt intentional please confirm ?<br>
> ><br>
> > We can share some patches if it maters.<br>
> ><br>
> > To be tracked here and at  :<br>
> ><br>
> > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=53214" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=53214</a><br>
> ><br>
> ><br>
> > Regards<br>
> ><br>
> ><br>
> > --<br>
> >  mailto:<a href="mailto:philippe.coval@eurogiciel.fr">philippe.coval@eurogiciel.fr</a>  --  gpg:0x467094BC<br>
> >  <a href="mailto:xmpp%3Aphilippe.coval.pro@gmail.com">xmpp:philippe.coval.pro@gmail.com</a><br>
> >  <a href="https://dockr.eurogiciel.fr/blogs/embedded/author/pcl/" target="_blank">https://dockr.eurogiciel.fr/blogs/embedded/author/pcl/</a><br>
> >                                                                        .<br>
> ><br>
> > _______________________________________________<br>
> > wayland-devel mailing list<br>
> > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
> > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
> ><br>
><br>
><br>
><br>
><br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div>