Wayland and window position/size

[Carsten Haitzler]

On Thu, 27 May 2021 17:02:24 -0500 Igor Korot <ikorot01 at gmail.com> said:

> Hi, Pekka,
> 
> On Wed, May 26, 2021 at 4:30 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > 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.
> 
> But then I, as a developer, will not be able to produce truly
> cross-platform software.
> Because it will behave differently in different environments.

that... is life. :) you need to just be aware of where your abilities or
responsibilities lie and where they stop and where something else becomes
responsible. different platforms have different boundaries here. that is normal
and how it works.

> So, if I have Ubuntu with Wayland and the user is set to compositor 1,
> the software will behave
> according to scenario 1.
> But if the user uses Debian with comp[ositor 2, the software will
> behave by scenario 2.

correct. this has ALWAYS been the case on *nix (unixes/bsd's/linuxes etc. with
x11). you have no idea of all the little and even large behavior differences.
within x11 this continues. the whole point of x11 separating mechanism and
policy with the xserver dealing with the mechanism and the window manager
dealing with policy. different wm's can have vastly different policies.

for example. you may ask to maximize a window and the wm may go "no - you may
not. i do not allow maximized windows". that is perfectly legal - and that
will be the case because the user chose that option/policy in that wm or they
chose that wm because it implements this policy. 

i've been writing x11 wm's for 25 years and now wayland compositors too. most
app devs know very little of the standards which wm and compositor devs need to
know  very well. trust me when i say that assuming a single kind of behaviour
across all wms is a huge mistake quite a few apps make. they don't understand
what they can expect to control and what they can't. even in x11 there is no
guarantee you can place your window.

tiling wm's are one of the more extreme examples where a wm will enforce a
specific sizing and placement policy (if you don't know what these are - look
them up but once you realize what they do you will realise how bad your
assumptions on placement are). tiling wm's  will actively force your window to
place where they want, not where you want, even if you ask it to be placed
somewhere even in x11. wayland has learned mistakes from the x11 world and by
design is avoiding many mistakes. placement is one of those. that is the entire
point of their layout policy and what a tiling wm does. if it didn't do this
users would be incredibly annoyed that they didn't get the behaviour they want
- and they want all their windows to tile and not place themselves wherever the
author of that app thought they should go. (i won't get into override-redirect
windows which allow you to bypass a wm but then life gets very tough).

you can have a kiosk-style wm's that force a window to fill the screen and only
have one visible at a time and will refuse to allow windows to place themselves
too because this is the point of the wm - they have a policy specifically to
implement a kiosk ui.

my favorite examples though are "what if your window is wrapped around a 3d
bunny rabbit? what does explicit placement mean then?" ... this is not as silly
as it sounds. imagine VR. yes - imagine a wayland compositor that has a VR
world and your app is just somewhere inside of it. what does absolute placement
relative to the screen mean then when .. "there is no screen". there is a 3d
world in which a user lives and moves around - your app may float somewhere in
it... how can you define that? this is the point of abstracting this to allow
things like VR compositors and apps to work sensibly within it. the compositor
may take your app and map it to the side of some wall in the virtual world...
wrap it around a sphere... or a 3d bunny-rabbit.

i'm giving you these examples to help you stand back and re-think what a
display system is and what environments may exist and policies may exist and to
perhaps rethink how much control you really have or even should have.

> And if the user has Red Hat with X the software will behave by scenario 3.
> And if I add Windows/OSX to the picture....
> 
> Will there be any consistency? ;-)

Nope. and that is the whole idea. see above. it is the POINT of these
compositors to implement what the USER wants. if the user wants a 3D VR world
in which their app windows float around in 3D space alongside some game world
filled with dinosaurs wandering around that you command to eat the windows to
close them... that is what is meant to be possible. and if the user runs that
same compositor on all their platforms then they get consistent usage across
them. of course they can't run this on osx or windows - they don't readily alow
this kind of flexibility (replacing the compositor as you like). so even if you
use ubuntu, redhat, arch linux, gnetoo, you CAN run the same compositor/desktop
on all of these and thus get consistent behavior. but if you use a different
one then expect differences in behaviour.

> > So I guess the answer depends on what you mean by settings.
> 
> What I mean is the following:
> 
> At any given time the user can have X number of applications running.
> When the user starts the application - their position is defined by
> the compositor.
> 
> Now I, as a developer, don't know what compositor does. I don't care,
> and I shouldn't.
> But what I'd like is for my program and my program only to start at
> consistent position and size
> at any given point of time.

you as the developer should never do this. the fact you are TRYING to do it is
a sign of having gotten used to "poor platforms". I can't much comment on OSX
but windows definitely does not have a history of doing things like
auto-remembering the position of windows for the user. on the flip side the
wm/compositor I write and have been working on for over 25 years does this for
any window the user asks the wm to do this with. I have used this feature for
decades to force applications to place and size where i want them to. the wm
auto-remembers if i move and resize those windows and next time the app runs
the windows are placed and sized as i last used them. if resolution changed or
i unplugged screens etc. it will adapt the sizing and positioning appropriately
to be sane. apps don't have to go around re-implementing this again and again
across 100's of apps. it's implemented ONCE in the wm and apps don't need to do
anything. they can be dumb and the wm will just do whatever the user asks in
this regard. the fact that other platforms do NOT do this is actually making
life harder for you. you are bringing the mindset of "but i must do this as an
app dev because i have always had to do this" and we come from "well no - you
should never have to do this. the fact you have had to do this and waste your
time and code on this is sad. you should focus on other things in your app and
the platform (display system) should be handling this for you... it certainly
is for me".

here are some of the options a user can ask the wm to remember for a given
window:

http://www.enlightenment.org/ss/e-60b021466ccfd5.43959291.png

not just position and size. staking too - is it above or below other things.
was it fullscreen or maximized. was the window sticky (you may not be familiar
with this idea - it's part of virtual desktops where a window sticks to the
screen and does not move with the virtual desktops and thus is always there as
if no virtual desktops existed - this is an area where both mac and windows
have been decades behind x11 and wayland worlds that have done virtual
desktops pretty much since the 1980's). the wm will remember even the screen
the window belonged to. if i reconfigure the arrangement of the screens (move
my monitors and cabling around) the wm will do the right thing and remember the
screen.

> Will this be possible?
> I don't care about any other applications - itsd their business what
> they want to do.
> I want mine to behave consistently. Because consistency is important.

actually it is NOT their business. it is the business of the wm/compositor. it
is thus not your business either. :) that is the whole point. :) it should not
be the business of ANY app to store its own window positions and restore them
and then handle all the complexities of multiple screens, those screens
dynamically being plugged and unplugged, changing resolution and other screen
elements like panels and other desktop controls coming and going, being
reconfigured etc. that you know nothing about. :)

> > > > > 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.
> 
> So what you say here ios that the Wayland only concern is about positioning,
> right?
> And window sizing will still work as before (with X).

actually in both x11 and wayland you don't have full explicit control wm's can
decide that you do not. i have explicit code in my wm to say "hell no" to
applications that position themselves. these are called "locks" to lock the app
out from doing certain things like changing its size or moving itself around or
changing stacking etc. the wm exposes these locks to the user allowing a user
to lock an app out from changing these things. tiling em's are another example
where you may not have this control either - in x11 as well. so you come in
with the wrong assumption already. :)

> Do I understand it correctly?
> 
> >
> > 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.
> 
> And here we will have a problem.
> As said - the window initially does not have a content.
> Only a toolbar and a status bar.

then just have a big blank area below the toolbar that can resize up and down.
or whatever works for you. this is between you and your widget set (wx) and has
nothing to do with wayland, wm's or compositors.

> And so when my application will start on Wayland I will get a very small
> window in size which will display only the toolbar.

this is not a wayland issue but an issue with your usage of wx widgets or an wx
widgets bug or issue. i don't use wx or know a lot about it specifically.

> > xdg-shell extension further defines what sizes you can choose from and
> > when.
> 
> Now this contradicts what you wrote above ("Not about Wayland").
> 
> >
> > > > > 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.
> 
> And what happens when the compositor disagree?
> Will I get a very small and narrow window, as explained above? Or
> something else?

if the compositor disagrees you had better play nice and provide a buffer of
the size the compositor tells you to. if you do not the compositor may do
anything it likes. it may just refuse to update or display your window until
you finally provide the right sized buffer. it considers your display
incomplete until that buffer comes around and thus will not show anything as
it'd look wrong/bad. i know that is what i would do and i think this would be
the general policy most compositors will take in order to get every pixel
perfect. the compositor is in charge ultimately and it can kill your connection
forcing your app to die and have no display system access. it can position your
window where it wants to position it. it can tell you the size you must be and
you can choose to disagree and then the compositor has the final say - because
without it you display nothing. if it decides that it said you must be 800x800
and you provide a buffer of 300x300 then it is perfectly allowed to ignore your
buffer until it is 800x800.

> Because remember - the content of my window is not created immediately.

as above. provide some content with something (eg a blank resizable region
below the toolbar) - fill in the rest later when you get around to it. this is
a client-side issue.

> > > > > 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.
> 
> Well, we are not talking about modality here - this thread is about
> positioning the dialogs.
> So, when I start my application and I click the button "Connect to the DBMS"
> I expect some consistency, so that the user of my application, should
> they decide to switch the OS
> will not be pleasantly surprised.

and you should provide that dialog and configure it in a way that makes sense.
display it in-line within the window you have just as some widgets, show a new
window/dialog with the parent of that dialog set to be your main window. the
wm/compositor if it is sensible probably should place that dialog somewhere sane
relative to your main window (e.g. center it over the parent window). gthe idea
is all apps that show such dialogs now consistently behave the same in that
compositor - they center over their parent windows. it's consistent for all the
apps the user is using all day on that system because the compositor makes it
so.

> > 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.
> 
> I wouldn't.
> However I doubt the toolkit I choose (or any toolkit for that matter) will
> have a ready to use credentials dialogs just to satisfy switching to the
> Wayland from X.

Making one is a trivial bit of work. a table, optional 2 labels (username,
password) 2 entries (user, password), and an ok/cancel button probably...  you
may find some toolkits actually do have these already made too as they are
common. they certainly have file selectors and such built in.

> All they will have is some generic dialog API based on which user can
> create one generic
> dialogs.

And what is wrong with that? You can choose a toolkit that has this done for
you, and if it doesn't then make your own dialog or perhaps extend the toolkit
you use and send patches back to the developers. You can't expect every
platform and display system to be identical. They are different because
developers made different decisions with different design goals and priorities.

Stand back a bit. Imagine I were to take your position. Imagine i went to Apple
and said "hey apply- you don't allow the wm/compositor to be replaced on iOS
devices. This makes cross-platform development do hard for me. I can't easily
port my wm/compositor to iOS. please go change iOS so it's nicer for me.". Just
imagine what they would say? :)

> And of course, software development is all about corner cases - that's where
> most of the bugs are. ;-)
> 
> >
> > > > > 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.
> 
> OK.
> But I am able to get the monitor size and its DPI, right?

That is pretty much the intent of getting the screen in formation - so you can
render appropriately e.g. with the right RGB sub-pixel layout etc. Mind you I
actually may debate that this is the best design. As per my VR world example -
this will not be applicable in that world, so don't rely on the compositor
always telling you something sensible for screens and their layout... it may
not be applicable.

> That's all I might need.
> 
> >
> > 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.
> 
> Not related to my software, but...
> 
> If I run KDE and create a tray icon application with the hidden window
> what will happen?
> If I want to create a modal dialog for settings or ask the user about
> something?
> But I guess this should be directed to the developers of KDE...

Correct. :) But please read the above and think. Think much more abstractly.
It'll help make your life easier.

> Thank you.
> 
> >
> >
> > Thanks,
> > pq
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com