Screen dimensions, top level surface positioning...

[Pekka Paalanen]

On Fri, 24 Nov 2017 18:40:13 +0200
Jari Vuomajoki <rakkaudentuli at gmail.com> wrote:

> Hi Everyone!
> 
> Thank you all for clear answers. I can understand the problematic of
> providing parallel solutions for several graphics environments...
> 
> ...so here is the use-case I am puzzled with:
> 
> 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.
> 
> 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...
> 
> 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.
> 
> I think this kind of scenario is relatively common: One screen, multiple
> applications with multiple windows.
> 
> Of course a solution is implementing composer or shell, but this breaks
> compatibility across composers/WMs.

Hi Jari,

yes, you are right, there is currently no solution to do that as far as
I know. Introducing one means adding a protocol extension that can e.g.
position top-levels relative to other top-levels of the same client. If
the compositor knows that this window should be side-by-side on the
right of that window for instance, it can reposition both such that
they both fit on the screen. If fitting on the screen is impossible,
the compositor can choose to break the proposed positioning to ensure
the windows are still accessible to the user, or propose resizing to
the app.

A protocol extension necessarily means adding an implementation in all
compositors and all toolkits.

An alternative solution could be application session save/restore
protocol feature, that would allow the app to recall old top-level
window positions, without exposing any global coordinate system, and
automatically adapting to cases where e.g. some screens have
disappeared but the windows should still be accessible.

I don't know if either feature have been worked on, at least I don't
remember seeing any proposals to wayland-protocols.

These are just two examples of many use cases which require protocol
extensions, but which may have not been worked on yet.


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/20171127/a78997f5/attachment.sig>