Screen dimensions, top level surface positioning...

[Pekka Paalanen]

On Wed, 22 Nov 2017 10:07:47 +0800
Jonas Ådahl <jadahl at gmail.com> wrote:

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

Hi,

I agree with everything Jasper and Jonas have said, but I would like to
point out one more thing.

The discussion so far has been about desktops. We do not want to expose
a global coordinate system on desktops specifically, for all the reasons
said.

One detail why clients should not be able to position their floating
windows in absolute positions is that they cannot know what other
windows are on screen, therefore they cannot do positioning always
right. Also consider tiling window manager environments, VR
environments where the global space is actually 3D, not 2D, etc.
The HiDPI support where different outputs have different scaling
factors that the compositor automatically applies as necessary (a
feature that has been impossible on X11 so far) makes it harder to even
define a global coordinate system at the protocol level.

That is on desktops. Those are also reasons why the Wayland core
protocol does not have any kind of wl_surface positioning at all.

But, if what you are building is not a desktop, then the situation is
completely different. A custom non-desktop environment can and probably
should use a custom shell protocol extension that replaces the desktop
shell protocol extensions. Doing that, it can provide whatever you
want. The major drawback is that you need to add explicit protocol
support to all compositors and toolkits you want working with it.

An example of an alternate shell protocol implementation is Weston's
fullscreen-shell, which is tailored for a single exclusive application
controlling all outputs. You can achieve per-output absolute
positioning there by using sub-surfaces.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171122/3e7fd672/attachment.sig>