<div dir="ltr"><div>Hi Everyone!</div><div><br></div><div>Thank you all for clear answers. I can understand the problematic of providing parallel solutions for several graphics environments...</div><div><br></div><div>...so here is the use-case I am puzzled with:</div><div><br></div><div>I am implementing a desktop application consisting of several windows. I can create proper implementation using the existing client API. However there is one scenario that falls out of the possibilities. </div><div><br></div><div>Let's say that the environment is a desktop computer with single screen. The workflow consists using several applications with some applications having several top-level windows and jumping between them using shortcuts, jumping between applications as well as application windows. Composers usually have uniform solution jumping between applications and application windows that can be associated with shortcuts, expose-style layout solutions, other gestures...</div><div><br></div><div>At this point everything works well with current Wayland client API. But if a client wants to organize it's top-level windows in more suitable ways like organizing windows side by side, creating a grid or organizing them in a special purpose custom layout... it is no longer possible with top level windows. This is only possible for sub-surfaces, therefore breaking the integration with the shortcuts and exposure with the composer/WM. </div><div><br></div><div>I think this kind of scenario is relatively common: One screen, multiple applications with multiple windows. </div><div><br></div><div>Of course a solution is implementing composer or shell, but this breaks compatibility across composers/WMs.</div><div><br></div><div>Best,</div><div>Jari</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 November 2017 at 09:44, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 22 Nov 2017 10:07:47 +0800<br>
Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
<br>
> On Wed, Nov 22, 2017 at 03:43:43AM +0200, Jari Vuomajoki wrote:<br>
> > Hi Jasper,<br>
> ><br>
> > Thank you very much for your very clear and comprehensible answer. I<br>
> > understand the challenges you are addressing.<br>
> ><br>
> > I want to build applications that can facilitate the screen layout to the<br>
> > fullest and still collaborate with WM.<br>
> ><br>
> > I don't really get the "fight" between WM and client. Maybe it is an<br>
> > invitation for someone to build a really nice WM / compositor, satisfying<br>
> > all needs.<br>
> ><br>
> > However, stating it bluntly - Client side surface positioning relationship<br>
> > to screen dimensions or multiple screen topology is a must.<br>
><br>
> It is a must for a very specific subset of specalized clients that<br>
> construct desktop environment components such as panels, launchers etc.<br>
> For regular applications, complete control of positioning is generally<br>
> only used to implement some functionality the compositor would be better<br>
> at.<br>
><br>
> ><br>
> > I think it can be done without compromising the simplicity and clarity of<br>
> > the protocol. Or is there something that I am not seeing?<br>
><br>
> I don't know what type of client it is that you are trying to implement,<br>
> but with the assumption made above, you'll have to look into extensions<br>
> allowing you to achieve the outcome you are working towards.<br>
><br>
> However, you cannot rely on every desktop environment / compositor to<br>
> support every use case that was possible on X11. This is to make it<br>
> possible for highly integrated environments such to be implementable.<br>
><br>
> With that said, this does not stop any compositor to add protocols<br>
> for "plug-n-play" kind of environments. One project which goal is to<br>
> provide these types of protocols is wayland-wall:<br>
> <a href="https://github.com/wayland-wall/wayland-wall" rel="noreferrer" target="_blank">https://github.com/wayland-<wbr>wall/wayland-wall</a><br>
><br>
> Now, you might be trying to implement something else, such as a splash<br>
> screen or something. That is might something that hasn't had a protocol<br>
> defined for it defined yet, but I would have to know what it is that you<br>
> are doing to be able to comment on that.<br>
<br>
</div></div>Hi,<br>
<br>
I agree with everything Jasper and Jonas have said, but I would like to<br>
point out one more thing.<br>
<br>
The discussion so far has been about desktops. We do not want to expose<br>
a global coordinate system on desktops specifically, for all the reasons<br>
said.<br>
<br>
One detail why clients should not be able to position their floating<br>
windows in absolute positions is that they cannot know what other<br>
windows are on screen, therefore they cannot do positioning always<br>
right. Also consider tiling window manager environments, VR<br>
environments where the global space is actually 3D, not 2D, etc.<br>
The HiDPI support where different outputs have different scaling<br>
factors that the compositor automatically applies as necessary (a<br>
feature that has been impossible on X11 so far) makes it harder to even<br>
define a global coordinate system at the protocol level.<br>
<br>
That is on desktops. Those are also reasons why the Wayland core<br>
protocol does not have any kind of wl_surface positioning at all.<br>
<br>
But, if what you are building is not a desktop, then the situation is<br>
completely different. A custom non-desktop environment can and probably<br>
should use a custom shell protocol extension that replaces the desktop<br>
shell protocol extensions. Doing that, it can provide whatever you<br>
want. The major drawback is that you need to add explicit protocol<br>
support to all compositors and toolkits you want working with it.<br>
<br>
An example of an alternate shell protocol implementation is Weston's<br>
fullscreen-shell, which is tailored for a single exclusive application<br>
controlling all outputs. You can achieve per-output absolute<br>
positioning there by using sub-surfaces.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>