Window placement

Pekka Paalanen ppaalanen at
Thu Jul 3 00:03:52 PDT 2014

On Wed, 2 Jul 2014 16:16:36 -0700
Jason Gerecke <killertofu at> wrote:

> On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey <fabounet03 at> wrote:
> >> "The question is: what action triggers it to make this ring of icons
> >> appear?"
> > A global shortkey (and yes I know it's not yet possible on Wayland, that's
> > another problem on its own).
> >
> >> "What's the application doing? Does it have keyboard focus but is
> >> potentially not under the mouse pointer? Do you have a screenshot or video
> >> of this feature you can share?"
> > I'm not the developper of it, I actually don't even use it ^^ I was just
> > thinking of it to see how it would fit in Wayland, what's potentially
> > missing now in the protocol.
> > Here is an article about it:
> > and a video:
> >
> > Basically, it appears under the mouse when you trigger the shortkey, and you
> > can also use the keyboard to navigate in the items.
> > So I see 2 main points here:
> > - it places its window not relatively to a parent (which there is not), but
> > to the mouse
> > - it takes the (keyboard) focus when it appears
> > The second point is not related to this topic, so we can probably think of
> > it later.
> >
> >
> >
> This reminds me of a something similar[1] that comes with the Wacom
> drivers on Windows and Mac. Its not a normal application that you
> would open, interact with, (possibly switch away from temporarily),
> and close. Rather, the application sits in the background and waits
> for some button/mouse/hotkey to be pressed before spawning a window
> under the mouse that you interact with for only a moment before
> returning to your original task.

Right, though on a quick glimpse on that video without really
understanding what's going on there, the circular menu seems more like
belonging to the image processing application.

Fabrice's example OTOH is obviously a DE component, as it is a
launcher, window control, and stuff.

> I do not mean to put words into Pekka's mouth, but I believe what he
> means when saying that things like this are "a DE-component" he's
> speaking conceptually more than anything else. Alternative menu
> systems like this and desklets essentially exist to augment the
> desktop itself. Just because they can be written in a DE-agnostic
> manner and run on GNOME, KDE, or TWM (all hail xeyes?) doesn't change
> that. They have fundamentally different needs than the average
> application, and -- at least as far as I understand Wayland -- it
> makes sense to leave some of these things up to the desktops to
> define.

Quite right. Defining a generic protocol (designed from above, a
little like the core Wayland protocol has been done) for adding DE
components like pagers, task bars, launcher systems, window management
thingies, desklets, etc. is so far an explicit non-goal.

On Wayland, desktop environments are intended to be much more tightly
integrated than on X11. We are not planning to intentionally design
support for custom desktop environment arrangements where you pick the
window manager from here, pager from there, a 3rd party task bar, and
then a few desklets all from different other DEs. Yes, you can say it is
a loss for the people who like to build their own DE from various
pieces (I'm one of them, but mostly just because I can't bother
learning anything else). However, it should be a great win in
freedom of design, stability and usablity for the seriously developed
DEs used by the masses.

Every DE has its own thing for DE components already. Inventing yet
another way that doesn't really fit well for any DE and forcing
everyone to support that is not a good plan. Some components in some
DEs could be not programs but plugins, some may talk via dbus rather
than the display protocol, and so on.

Instead, we are trying to allow DEs to define their own interfaces for
these DE components, and if there actually emerges some common
interfaces that could be standardised, then we can look into it.
One hope is, that one DE starts to use a public interface for some DE
components, some other DE finds it good and starts using it too, and so
it slowly becomes a standard. Note, that nothing requires the
standard protocol to be part of the display (Wayland) protocol.

Unfortunately such organic, cooperative protocol design does not really
work for the core protocol that all applications will depend on, and
that's why we have and are "centrally" designing the Wayland core
protocols and xdg_shell. We cannot really test much without a stable
core protocol, and we cannot be sure the core protocol is good until it
is put into serious use; we also have already been bitten by this
chicken-and-egg problem.


> [1]:
> Jason

More information about the wayland-devel mailing list