Screen dimensions, top level surface positioning...

Jonas Ã…dahl jadahl at gmail.com
Wed Nov 22 02:07:47 UTC 2017


On Wed, Nov 22, 2017 at 03:43:43AM +0200, Jari Vuomajoki wrote:
> 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.

It is a must for a very specific subset of specalized clients that
construct desktop environment components such as panels, launchers etc.
For regular applications, complete control of positioning is generally
only used to implement some functionality the compositor would be better
at.

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

I don't know what type of client it is that you are trying to implement,
but with the assumption made above, you'll have to look into extensions
allowing you to achieve the outcome you are working towards.

However, you cannot rely on every desktop environment / compositor to
support every use case that was possible on X11. This is to make it
possible for highly integrated environments such to be implementable.

With that said, this does not stop any compositor to add protocols
for "plug-n-play" kind of environments. One project which goal is to
provide these types of protocols is wayland-wall:
https://github.com/wayland-wall/wayland-wall

Now, you might be trying to implement something else, such as a splash
screen or something. That is might something that hasn't had a protocol
defined for it defined yet, but I would have to know what it is that you
are doing to be able to comment on that.


Jonas


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

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



More information about the wayland-devel mailing list