Window placement

[Fabrice Rey]

> "They have fundamentally different needs than the average
application"
Well yes, I'm very aware they are, but when you say "DE-component", I see a
huge PITA for the developpers who would want to add such features in the
desktop.
Now, I wouldn't mind some sort of EWMH-like extensions, however, if a
developper has to first focus a DE, make a new extension for it, make it
accepted in the DE code-base, and then build its app, it's dead from the
beginning.
So our last hope would be that a DE really exposes a third-party-friendly
interface and that others follow... Ubuntu did with their Launcher API,
indicators API, etc, and it didn't spread very much.

I think if Weston implements an interface it will have a chance though, so
I'll still try to push some other ideas on this ML ;-)


2014-07-03 9:03 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:

> On Wed, 2 Jul 2014 16:16:36 -0700
> Jason Gerecke <killertofu at gmail.com> wrote:
>
> > On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey <fabounet03 at gmail.com>
> 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:
> > > http://www.webupd8.org/2011/10/gnome-pie-02-released.html and a video:
> > > https://www.youtube.com/watch?v=TFQDyZyMxO4.
> > > 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.
>
>
> Thanks,
> pq
>
> > [1]: https://www.youtube.com/watch?v=McJMnMJydes
> >
> > Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140703/a1488ec2/attachment.html>