<div dir="ltr"><div>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. </div><div>A real-world example : Weston has nothing such as a "taskbar". Some months ago, I proposed patches to enable such a bar under Weston (<a href="https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg12908.html">https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg12908.html</a> - <a href="https://www.youtube.com/watch?v=7Svrb3iGBAs">https://www.youtube.com/watch?v=7Svrb3iGBAs</a>). It wasn't merged, but that's not the topic here => </div><div>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. </div><div>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 (<a href="https://github.com/etrunko/weekeyboard">https://github.com/etrunko/weekeyboard</a>). 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, </div></div><div class="gmail_extra"> <div class="gmail_quote">2014-07-04 9:42 GMT+02:00 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 3 Jul 2014 22:26:49 +0200 Fabrice Rey <<a href="mailto:fabounet03@gmail.com">fabounet03@gmail.com</a>> 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 <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>>: > > > On Wed, 2 Jul 2014 16:16:36 -0700 > > Jason Gerecke <<a href="mailto:killertofu@gmail.com">killertofu@gmail.com</a>> wrote: > > > > > On Wed, Jul 2, 2014 at 3:33 PM, Fabrice Rey <<a href="mailto:fabounet03@gmail.com">fabounet03@gmail.com</a>> > > 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: > > > > <a href="http://www.webupd8.org/2011/10/gnome-pie-02-released.html" target="_blank">http://www.webupd8.org/2011/10/gnome-pie-02-released.html</a> and a video: > > > > <a href="https://www.youtube.com/watch?v=TFQDyZyMxO4" target="_blank">https://www.youtube.com/watch?v=TFQDyZyMxO4</a>. > > > > 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]: <a href="https://www.youtube.com/watch?v=McJMnMJydes" target="_blank">https://www.youtube.com/watch?v=McJMnMJydes</a> > > > > > > Jason > > _______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote></div> -- <div dir="ltr">Regards, Manuel BACHMANN Tizen Project VANNES-FR </div> </div>