<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 19, 2014 at 12:46 AM, Manuel Bachmann <span dir="ltr"><<a href="mailto:manuel.bachmann@open.eurogiciel.org" target="_blank">manuel.bachmann@open.eurogiciel.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p>Hi Jasper, Jaspon, thanks for taking good arguments to the table,</p><div class=""><p>"Destroying and creating an xdg_surface will, certainly."</p>
</div><p>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.</p>
<p>"xdg_surface_present_window()"</p><p>"window" may be an excessive high-level word ; what do you think of "xdg_surface_present()" alone ?</p><p></p><div class="">"I do want to make the guarantee that it isn't "immediate""<br>
</div><div class="">
"The point here is that we don't want minimize/unminimize to get abused by apps."</div><p></p><p>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..</p>
<div class="">
<p>"So, what is the use case for unset_minimized?"</p></div><p>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.</p>
<div class="">
<p>"Unfortunately, toolkits really like to work in terms of show/hide which,<br>while easy, doesn't fit exactly."</p></div><p>Agreed. In the EFL, we mapped "xdg_surface_set_minimized()" to <br>"ecore_wl_window_iconified_set()". One could argue about the "iconified" word ; however we didn't want to use "hide()" which does something different.</p>
<div class="">
<p>"when a window gets unminimized and things of that nature<br>need to be determined by two things: App intentions communicated to the<br>compositor, and compositor policy. If the app has important information<br>
for the user, it should indicate that to the compositor. The compositor<br>can then respond by showing the window, switching workspaces, making<br>something blink/bounce, etc. depending on its *policy*. For something like<br>
Tizen, that could be "if the app has the focus-stealing permission, show<br>the window, otherwise blink the notification bar" or something like that."</p></div><p>I think you summed it up nicely. We want the window to be able to be shown back, however not in all cases.</p>
<p>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.<br>
When clicked, the balloon would then make the surface appear back on the current screen, positioned as it was before.</p><p>What do you think of that ?</p></div></blockquote><div>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.<br>
</div><div>--Jason Ekstrand<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-18 18:55 GMT+02:00 Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>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 style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div>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><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.<span><font color="#888888"><br>
<br></font></span></div><span><font color="#888888"><div>--Jason Ekstrand<br></div></font></span><div><div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div><div>><br>
> On Fri, Jul 18, 2014 at 7:33 AM, Philippe Coval <<br>
> <a href="mailto:philippe.coval@open.eurogiciel.org" target="_blank">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" target="_blank">philippe.coval@eurogiciel.fr</a> -- gpg:0x467094BC<br>
> > <a href="mailto:xmpp%3Aphilippe.coval.pro@gmail.com" target="_blank">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" target="_blank">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" target="_blank">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></div></div><br></div></div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">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></blockquote></div></div></div><br><br clear="all"><div class=""><br>-- <br><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div>
</div></div>
</blockquote></div><br></div></div>