On Sat, Jul 19, 2014 at 12:46 AM, Manuel Bachmann < manuel.bachm...@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 <ja...@jlekstrand.net>: > > >> >> >> On Fri, Jul 18, 2014 at 5:31 AM, nerdopolis < >> bluescreen_aven...@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.co...@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.co...@eurogiciel.fr -- gpg:0x467094BC >>> > > xmpp:philippe.coval....@gmail.com >>> > > https://dockr.eurogiciel.fr/blogs/embedded/author/pcl/ >>> > > >>> . >>> > > >>> > > _______________________________________________ >>> > > wayland-devel mailing list >>> > > wayland-devel@lists.freedesktop.org >>> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> > > >>> > >>> > >>> > >>> > >>> >>> _______________________________________________ >>> wayland-devel mailing list >>> wayland-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> >> >> >> _______________________________________________ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >> > > > -- > Regards, > > > > *Manuel BACHMANN Tizen Project VANNES-FR* >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel