Window placement

Sun Jun 29 09:50:56 PDT 2014

On Sun, Jun 29, 2014 at 12:41 PM, Fabrice Rey <fabounet03 at gmail.com> wrote:

> > "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
> widget.
> 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.
>

Are they stacked like regular windows, where they're raised to the top when
you click on them or are they always stacked below application windows? Can
you alt-tab to them? Do they appear in any taskbar?

These things will need to be extensions. Maybe they belong inside
xdg-shell, maybe not.

Really, it sounds like what you want is not for the desklet to tell the
compositor where it should be placed, but for the compositor to remember
where to place specific windows like desklets. I am of the opinion that the
compositor is in a much better position to remember where windows go than
every single application.

The reason we omitted global window positioning is that it over-complicates
things considerably, has security issues, and doesn't work too well with
dynamic multimonitor setups. Not to mention that in some cases, like remote
window display or an expose-like view, you're effectively lying to the
window, unless you allow them to be in multiple places or give them a full
transform matrix of how they're currently displayed on the screen. And at
that point, why even bother?

Constraining popup menus is indeed something that we need to solve. Our
current thoughts is that you give the compositor a parent window and a
rectangle, and the compositor will hand you back an adapted rectangle
clipped to the coordinates of the screen, allowing you to figure out where
the screen edges are with a single round-trip.

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>
>> wrote:
>>
>> > "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
>>> standardised."
>>> 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
>>>> Wayland.
>>>> > Because of that, a desklet application can't place its desklets on the
>>>> > desktop. Currently in Weston, they are automatically placed
>>>> (randomly, each
>>>> > 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
>>>> 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.
>>>>
>>>> Either way, as far as I know, the process is not going to be
>>>> standardised.
>>>>
>>>> > Another similar problem is that when receiving a Configure event, the
>>>> > position is not in the event. So for instance in GTK the coordinates
>>>> are
>>>> > always (0;0).
>>>>
>>>> That's expected. Any application knows only about its own windows and
>>>> never
>>>> knows about the global position.
>>>>
>>>> > This is problematic, because the application might want to display
>>>> things
>>>> > differently depending on where it is.
>>>> > For instance, on right-click, the desklet would pop the menu above it
>>>> if
>>>> > 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 for
>>>> 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
>>>> interface
>>>> > ?
>>>> >
>>>> > 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
>>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>>
>>
>>
>> --
>>   Jasper
>>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140629/884c311f/attachment-0001.html>