Re: Wayland and window position/size
Hi, Pekka,
On Wed, May 26, 2021 at 4:30 AM Pekka Paalanen wrote:
>
> On Tue, 25 May 2021 22:10:38 -0500
> Igor Korot wrote:
>
> > Hi, Carsten,
> >
> > On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler
> > wrote:
> > >
> > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot 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-platf
Re: Wayland and window position/size
On Thu, 27 May 2021 17:02:24 -0500 Igor Korot said: > Hi, Pekka, > > On Wed, May 26, 2021 at 4:30 AM Pekka Paalanen wrote: > > > > On Tue, 25 May 2021 22:10:38 -0500 > > Igor Korot wrote: > > > > > Hi, Carsten, > > > > > > On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler > > > wrote: > > > > > > > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot 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 i
