DE-components (Re: Window placement)

Fri Jul 4 03:03:38 PDT 2014

HI Fabrice,

Just to follow on what Pekka said ; I don't think, either, that it's good
idea to try to define zillions of DE-oriented interfaces now ; but it may
be worth working on testing/demo implementations.

A real-world example : Weston has nothing such as a "taskbar". Some months
ago, I proposed patches to enable such a bar under Weston (
https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg12908.html
- https://www.youtube.com/watch?v=7Svrb3iGBAs). It wasn't merged, but
that's not the topic here =>

Now, say you're app developer that wants to have certain features in the
taskbar for your app (right-click menu, options in right-click menu,
applets, indicators...) *and* want them exposed in all or most compositors.

A good idea would then be to "push" the candidate interface by providing an
implementation, or find a motivated developer to provide an implementation.
At worst, provide an installable plugin. It it is good and functional, it
may then "win" the battle of DE interfaces in the future.

An example of this if the Weston virtual keyboard. Its interface is not in
libwayland, but there at least another client program that uses it (
https://github.com/etrunko/weekeyboard). If this move massifies, we can
then hope if will become the "standard" interface for VKs, and most future
VK software will use it.

Regards,

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

> 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
> > >
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

-- 
Regards,

*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140704/a6b52aa7/attachment-0001.html>