Window placement

Sun Jun 29 10:25:04 PDT 2014

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

They set the hints "skip_taskbar" and "skip_pager"; therefore their
position on the stack is usually fixed, like always on top or on the
opposite always below. For instance, I like to have a clock widget always
on top and transparent to click.

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

Why not, that can be a solution, although it will break the behavior of the
existing applications.
Currently though, each time I launch some desklets under Weston they are
placed randomly (and by randomly I mean at a different place each time,
even out of the screen).

By the way they don't need to be aware of the current transformation
matrix, nor if the Exposé view is active or not. Of course, the interesting
parameter here is the position on the desktop at a normal time.
The compositor places them wherever it wants, like with any window.
Really, just like it works now with any WM that have some desktop effects
(so almost all).

Now, I see your point, but will the compositor really be able to place them
correctly ?
Say I positionned a desklet to be on the bottom-right corner of the screen;
each time the resolution is changed, the desklet can reposition itself
accordingly to stay in the corner. How will the compositor fill the same
role ? I'm afraid when the resolution goes higher, it will just let the
desklet at its current position, which will become somewhere on the screen.

About letting know the position, which is in my opinion more important,
because I can't see a workaround like for the previous feature: I don't
think adding the position in the Configure events would complicate things
(the application that doesn't need it can just ignore it).
It also doesn't add a new event to the API, and all toolkits already
provide the (wrong) information anyway. As a developper, I find this lack
of information quite inconvenient.

2014-06-29 18:50 GMT+02:00 Jasper St. Pierre <jstpierre at mecheye.net>:

>
> 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/d6f8e9d7/attachment-0001.html>