Wayland and window position/size

[Igor Korot]

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.

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.
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? ;-)

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

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.

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

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.

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

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

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

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

>
> 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.
All they will have is some generic dialog API based on which user can
create one generic
dialogs.

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

Thank you.

>
>
> Thanks,
> pq