Screen dimensions, top level surface positioning...

[Jari Vuomajoki]

Hi Jasper,

Thank you very much for your very clear and comprehensible answer. I
understand the challenges you are addressing.

I want to build applications that can facilitate the screen layout to the
fullest and still collaborate with WM.

I don't really get the "fight" between WM and client. Maybe it is an
invitation for someone to build a really nice WM / compositor, satisfying
all needs.

However, stating it bluntly - Client side surface positioning relationship
to screen dimensions or multiple screen topology is a must.

I think it can be done without compromising the simplicity and clarity of
the protocol. Or is there something that I am not seeing?

Thank you,
Jari Vuomajoki


On 21 November 2017 at 20:02, Jasper St. Pierre <jstpierre at mecheye.net>
wrote:

> Hi,
>
> There's a few reasons that Wayland not to report or allow clients to
> choose absolute screen position.
>
> The biggest is that from our experience with X11, it's hard to even
> *define* such a space. Laptops plug into external monitors and projectors.
> People with differently sized monitors have gaps -- the space isn't as
> cleanly defined as a large rectangle. In my experience working on X11 WMs,
> clients often "fight" the WM over placement, preferring to request a
> position which is now offscreen because the user undocked their computer.
> Simply not defining a coordinate space to position windows in is easier
> than defining one, with all the complexities and edge cases that arrive
> from 30+ years of developments in computer interaction.
>
> One of Wayland's design goals is that where possible, compositors, not
> clients, have the final say. While it can be more difficult to program for,
> Wayland has concepts based around a relative positioning model. This allows
> the compositor to place clients where it sees fit, and allows compositors
> to more freely make constrainment choices so that menus don't get stuck
> behind taskbar panels, or similar things.
>
> It certainly has made some things more complicated, so it might have been
> an overreaction to the complexity we all faced with X11. Hopefully that
> gives you some insight into why we chose not to expose positioning to the
> client.
>
> On Tue, Nov 21, 2017 at 8:47 AM, Jari Vuomajoki <rakkaudentuli at gmail.com>
> wrote:
>
>> Hello!
>>
>> I have been getting to know the Wayland protocol from the client side for
>> only couple of months... So bare with me if my questions sound immature.
>>
>> It took a while to get going, the documentation is there and it is
>> informative enough to build a client. It could be a lot better though or
>> maybe I didn't find a proper source for it. Doxygen documentation ended up
>> being the most useful.
>>
>> Here is my list of questions and thoughts. Feel free to anwer or comment
>> on any of them.
>>
>> I want to compose clients based on screen dimensions. I know there are
>> fullscreen and maximized options. But I want to have total control of top
>> level surface sizes and placements in the screen. Now talking about single
>> screen, but this can be extented to multiple screens.
>>
>> This option is not part of the protocol. I can query the screen size
>> through wl_output interface, so why I cannot position a surface in arbitary
>> position? Why this option has been left out?
>>
>> I want to be able to manage the positions of all the top level shell
>> surfaces of the client connection.
>>
>> Ok, so now I asked it in three different ways...
>>
>> I can naturally extend weston shell and implement this option, but it
>> seems a bit overkill for such a simple option to have. What I am not
>> getting in the picture?
>>
>> Best Regards,
>> Jari Vuomajoki
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>
>
> --
>   Jasper
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171122/4eb8473f/attachment.html>