xdg shell status and gaps
Jasper St. Pierre
jstpierre at mecheye.net
Thu Sep 25 23:22:26 PDT 2014
Well, it can't be a state enum, because that's from compositor to client.
We certainly could make it a small extension as part of gtk_shell, though.
On Fri, Sep 26, 2014 at 12:02 AM, Jason Ekstrand <jason at jlekstrand.net>
> On Sep 25, 2014 3:04 PM, "Jasper St. Pierre" <jstpierre at mecheye.net>
> > On Thu, Sep 25, 2014 at 3:58 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> >> On 09/25/2014 01:57 PM, Jasper St. Pierre wrote:
> >> That patch has nothing to do with what is needed.
> >> You don't need a "modal window type". This is trivial for a client to
> do by just pretending that whatever keystrokes it gets go to the "modal"
> window even if the compositor sends them to a different window.
> >> What is needed is a non-flickering and atomic method of creating that
> modal window atop the main one and keeping it there. That requires a
> parent, not a "modal" flag. (well actually it does not require a parent if
> instead there was a way to atomically map and rearrange a set of surfaces,
> but I think the parent will be much easier and matches what programmers are
> familiar with).
> > You mean like the existing set_parent request that has been there since
> xdg-shell has landed?
> If parenting isn't sufficient, it would be easy enough to add a mutter
> extension for modal windows in the form of another state enum. If it turns
> out to be a well-defined thing other compositors want, we can think about
> moving it to core. In any case, it should be trivial from a protocol point
> of view.
> > --
> > Jasper
> > _______________________________________________
> > 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...
More information about the wayland-devel