DE-components (Re: Window placement)

[Pekka Paalanen]

On Thu, 3 Jul 2014 22:26:49 +0200
Fabrice Rey <fabounet03 at gmail.com> wrote:

> > "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 ;-)

So you just completely ignored my explanation below on why we
(as Wayland upstream developers) do not want to do this at this
time?

We still have a lot of work to be done to support even the normal
applications that are not DE components. That stuff must be
standardised to have even *normal* applications work across
different compositors. I really don't think there is time to invest
in creating and standardising non-essential protocols and their
implementations.

For example, I would consider supporting games needing mouse-look
as a much higher priority than DE widgets.

If you have the time to design, implement, and convince one or two
major DEs to support your DE-component interfaces, please do! I do
think that at least one big DE needs to buy in on this, rather
than just Weston. Even then, you are welcome to use Weston as your
development environment, but it might be hard to catch reviewers.

I outlined the plan to come up with these optional standard
protocol extensions below, and I really think that is how it should
go. In any case, I think you probably won't have your standard
DE-component interfaces in before a few years passes, so it would
be good to start experimenting sooner than later. Someone has to do
the hard work, before other developers can simply reap the benefits
by making cool desklets and stuff.


Thanks,
pq


> 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
> >