fabounet03 at gmail.com
Sun Jun 29 09:41:51 PDT 2014
> "xdg-shell is between desktop applications and the compositor, not
between some concept of "desklets" and the compositor. I don't even know
what a "desklet" is."
Well, a desklet is a desktop widget, for instance a clock or a weather
They are a bit particular in the sense that they should be placed at a
given position and have no decorations, but that's all, and as far as I
know, they have always been implemented using standard normal windows.
2014-06-29 18:26 GMT+02:00 Jasper St. Pierre <jstpierre at mecheye.net>:
> On Sun, Jun 29, 2014 at 12:21 PM, Fabrice Rey <fabounet03 at gmail.com>
>> > "By the application and the compositor they're designed for having a
>> specific extension that they use to negotiate the position. The compositor
>> may allow this extension only to known applications it launches. Or maybe
>> not at all: the compositor may want to do that only via plugins running on
>> the compositor itself."
>> Plug-ins are not portable, it would mean a complete fragmentation of the
>> desktop, I hope we can avoid it.
>> What would be this "specific extension" ? Isn't xdg-shell the place where
>> such feature should be ?
> No. xdg-shell is between desktop applications and the compositor, not
> between some concept of "desklets" and the compositor. I don't even know
> what a "desklet" is.
>> > "Either way, as far as I know, the process is not going to be
>> Ok, but this is going to be fixed, right ? I mean, if something is
>> missing, it's probably the time to think of it, before the protocol is
>> written into the rock.
>> > "This should be solved for all kinds of popups, including menus."
>> Yes, I guess you can place a window relatively to its parent. That's
>> good, but still not enough for the use-case I presented. Since the client
>> doesn't know where it is on the desktop, it will act as if it's in the
>> top-left corner (by default), which will be wrong most of the time.
>> 2014-06-29 17:55 GMT+02:00 Thiago Macieira <thiago at kde.org>:
>> Em dom 29 jun 2014, às 17:44:46, Fabrice Rey escreveu:
>>> > Hi,
>>> > First thank you for hard work on Wayland/X.
>>> > As I understand, there is no window placement on the client side in
>>> > Because of that, a desklet application can't place its desklets on the
>>> > desktop. Currently in Weston, they are automatically placed (randomly,
>>> > time at a different position).
>>> > How is this going to be addressed by Wayland ?
>>> By the application and the compositor they're designed for having a
>>> extension that they use to negotiate the position. The compositor may
>>> this extension only to known applications it launches. Or maybe not at
>>> the compositor may want to do that only via plugins running on the
>>> Either way, as far as I know, the process is not going to be
>>> > Another similar problem is that when receiving a Configure event, the
>>> > position is not in the event. So for instance in GTK the coordinates
>>> > always (0;0).
>>> That's expected. Any application knows only about its own windows and
>>> knows about the global position.
>>> > This is problematic, because the application might want to display
>>> > differently depending on where it is.
>>> > For instance, on right-click, the desklet would pop the menu above it
>>> > it's in the bottom half of the screen, and vice-versa.
>>> This kind of issue should be solved on the particular use-case, as
>>> opposed to
>>> telling the application about its global position. This should be solved
>>> all kinds of popups, including menus.
>>> > It seems that xdg-shell is to bring answers to these kind of
>>> > desktop-specific problems, so is this planned to be added in this
>>> > ?
>>> > Fabounet.
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel Open Source Technology Center
>>> PGP/GPG: 0x6EF45358; fingerprint:
>>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel