Wayland and window position/size

Wed May 26 09:29:49 UTC 2021

On Tue, 25 May 2021 22:10:38 -0500
Igor Korot <ikorot01 at gmail.com> wrote:

> Hi, Carsten,
> 
> On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler <raster at rasterman.com> wrote:
> >
> > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot <ikorot01 at gmail.com> said:
> >  
> > > Hi, list,
> > > Couple of questions about Wayland, since more and more distros switching ;-)
> > >
> > > If I understand correctly window positioning/sizing is based on the
> > > compositor/window content.
> > >
> > > 1. Is there a way to select where each individual program will start?  
> >
> > The compositor decides this. It may place it randomly, somewhere intelligently
> > with minimum overlap, relative to some parent surface/window or perhaps it
> > might store the position it saw that named window at last and restore it to
> > that position. The compositor may expose such settings to the user, or maybe
> > not. It's between the compositor and the user and the idea is that it will be
> > consistent with all windows.  
> 
> OK, so there is no "per-program" settings anywhere.

Not by "the Wayland standard", assuming such a standard was even
defined.

But a compositor or a DE may or may not offer per-program settings to
the end user. I literally mean to the end user, not to the application.

So I guess the answer depends on what you mean by settings.

> > > 1a. If not - will there be one?
> > > 2. I am working on the program that should start up with the empty
> > > window - only the toolbar
> > > and the very basic menu.
> > > Then when the user chooses some action from the toolbar some child
> > > windows appear.
> > > I think such program will always start up with very minimal size,
> > > basically the size of the toolbar
> > > under Wayland. Am I wrong?  
> >
> > That is up to your program. It could create a very wide and narrow window with
> > just menu bar and toolbar. That's perfectly possible - the buffer you provide
> > will determine this. Generally for most applications the toolkit you use will
> > handle all of this for you, unless you are making your own toolkit or you are
> > nutty enough to avoid a toolkit entirely and try and write everything "bare
> > metal" in which case essentially your app includes a toolkit and thus the work
> > that toolkits normally do becomes your work.  
> 
> Well, I'm using wxWidgets (cross-platform library) with GTK underneath.
> But that should be irrelevant to the problem.
> 
> My understanding is that the size of the TLW is determined by the content of it
> I can't just call window->SetSize( 100, 100 ); and the window will
> obey my command
> and will be created with the size 100x100.
> Or can I?

That is between you (the application) and your toolkit. Not about
Wayland. I would assume you can tell your toolkit to make the window
(and content along with it) a certain size. If not, pick another
toolkit that works better for you.

Wayland only defines that a window size cannot ever disagree with its
content size. That way there can never be undefined pixels on screen -
something that can happen with X11.

xdg-shell extension further defines what sizes you can choose from and
when.

> > > 3. How can one write a cross-platform application that should behave
> > > the same on the different
> > > platforms when the developer doesn't have control over window position/size.  
> >
> > Don't try and position a window. I write applications and I simply don't go
> > positioning the window in my own code. I leave it to the system to decide. It
> > just so happens my apps work on multiple platforms too because the toolkit
> > handles that. I expect the system to provide some sensible window positioning
> > of its own. I know full well that this falls apart quickly unless you spend a
> > lot of effort doing things like adapting the position you want to the current
> > resolution, and avoiding putting your window under other obstacles like
> > panels/taskbars and other elements. I just let the WM/compositor handle that.
> > If a user has a tiling WM/compositor or a WM capable of tiling modes then
> > trying to position your window instantly falls apart and assuming/expecting
> > this works is a recipe for pain.  
> 
> I understand.
> As I said I believe that the window sizing is based on the window content.
> So all I am doing is calling:
> 
> window->Maximize();
> 
> which actually works on all 3 major platforms (Windows, *nix+X, OSX).
> 
> However, my understanding is that it will not work under Wayland.

It should work just fine. On Wayland, the toolkit will ask the display
server to switch the window to maximized state. If the compositor
agrees, it tells the toolkit so and also tells the toolkit what size it
should be on the next window content update.

> > > 4. How can a developer write a program that should connect to the database?  
> >
> > That has nothing to do with Wayland or display systems in general - that's your
> > job. What kind of database, where it is, how it's dealt with is up to you. A
> > separate problem entirely.  
> 
> Actually it does.
> Most DBMSes provide dialogs for requesting user ID and password.
> Whether it is ODBC or a native library call.
> 
> Now those dialogs are usually centered on screen (at least on Windows w/ODBC).
> And I think the same can be said about OSX.
> 
> Now the user would be very confused when such dialog will appear in
> the corner of the screen.
> 
> Wouldn't you?

I wouldn't, as long as they don't start behind the current window. All
password dialogs I see already work like normal windows on X11.

But taking a step back from personal opinions, there are arguments to
be had whether such dialogs should be centered (on window? on monitor?
on desktop?), or globally-modal, or window-modal or application-modal.
The prevalent opinion I've felt in the community is that globally-modal
is just a bad idea, it takes the whole desktop as a hostage.

Showing a dialog involves Wayland, but Wayland has nothing about
connecting to databases.

Who should create the dialog, I don't know, it depends on the system
software architecture. Wayland says nothing about "who".

All I can say here is that the topic of this kind of "special dialogs"
is complex and I am not aware of the details. I wonder if "portals" (a
Wayland related concept but not tied to Wayland) would do something
here.

Then again, if you used a ready-made toolkit, you would have none of
these questions. You'd just use a suitable type of dialog from the
toolkit if you need to show the dialog yourself, or let system/desktop
services do it for you if there is an API for that. You wouldn't be
touching Wayland.

> > > 5. I know there was a plan to respect a save/restore window
> > > positioning/size. Is it implemented?  
> >
> > This is up to compositors to do. Your job is to provide a name for your
> > window(s) in Wayland so a compositor can implement this sanely.  
> 
> Name of the window or a name of the application?
> 
> Can you collaborate a little?

The xdg-shell extension has the bits Carsten refers to, I believe.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/stable/xdg-shell

> > > 6. How complete is Wayland API currently in terms of window
> > > positioning/sizing?  
> >
> > Positioning - Don't position and Wayland discourages it by not having such an
> > API. Sizing - do whatever you like.  
> 
> It just discourages it, so it is not completely impossible, correct?

I'd say Wayland strongly discourages client dictated positioning.

First, there is no Wayland protocol interface that would allow you to
position a window (unless you invent a protocol extension to do it and
then implement it also in any Wayland compositors you want to run on -
some extensions like that exist and their support in different
compositors varies, and they are mostly privileged or reserved for
desktop components instead of apps). It might be possible to play
tricks with existing generic interfaces to *maybe* eventually end up in
some position, but that is extremely fragile and an outright abuse which
might also cause strange UI behaviour.

Second, Wayland does not define a coordinate system that would be
useful for window positioning. Every window has its own local
coordinate system, but they exist in a "vacuum" and independently of
each other and of monitors. So at most you can position a window
respective to another window, but not globally or per-monitor.

Third, Wayland does not allow you to find out about other windows or
desktop elements that you might want to stay clear of, nor about
monitor edges (well... not for this purpose). So it's hard to choose
your position properly.

So, is it possible depends on how badly you are willing to break things
to get there.

As for sizing, I'd think the xdg-shell protocol extensions are mature.
They allow you to freely size your window when the window state
supports it, and they include the provision for the display server to
tell you what size you should or must be, depending on window state. It
also has an interface for positioning your popups such that they don't
go out of view but also match where they should be respective to your
window.

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/20210526/faa60fb9/attachment.sig>