Re: Wayland and window position/size
Hi,
Carsten already replied well, so I'll just clarify a few little details
more.
On Thu, 27 May 2021 17:02:24 -0500
Igor Korot wrote:
> 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 ;-)
...
> > 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.
I am talking in Wayland terms, which are very low-level terms.
You cannot make a window visible at all (the action is called "map") if
it does not have any content. Content includes everything: toolbars,
status bars, filler areas, even window decorations and shadows when
using client-side decorations, and of course what you call "content".
In protocol terms, you cannot make a wl_surface visible without a
wl_buffer.
A counter-example on X11: if the window is made bigger than what the
application draws into it (also if the application didn't get to draw
yet but the window is already mapped), the (extra) window area will
contain garbage unless the application tells the X server to fill it
with something. That garbage is usually left-overs of what other windows
from other applications might have left there, or maybe uninitialized
memory, or black in the best case.
In Wayland, there is no such thing as the compositor filling your
window with, say, background color. You, the application, has to
explicitly provide every single pixel you expect to see.
> >
> > xdg-shell extension further defines what sizes you can choose from and
> > when.
>
> Now this contradicts what you wrote above ("Not about Wayland").
Yes, sorry. I was trying to give simple answers, when the reality is
complicated and has a lot of "ifs". Choosing a size is actually a
negotiation process between the compositor and the client. A compositor
sets the boundary conditions depending on the window state it is
willing to realize, and the client has to work within those boundaries.
If the compositor uses floating windows, then a normal window usually
doesn't have much restrictions on its size, so you are mostly free to
pick what you want.
All that depends on compositor policy and what kind of window state you
negotiate.
Your toolkit may add its own restrictions, e.g. based on what widgets
you have.
Like Carsten explained, it's actually not that different from X11. X11
has a size negotiation process as well, but the difference is that X11
also allows the client and the WM to fight each other, and you can even
see the fighting on screen if you're unlucky.
> > > > > 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
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
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
Re: Wayland and window position/size
On Tue, 25 May 2021 22:10:38 -0500 Igor Korot said: > 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. > > Understood. > > > > > > 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 and xwwidgets. wayland as such doesn't care and will allow you to create a buffer for a surface (window) of any size you like. the toolkit in a wayland world should then probably expand this to actually be bigger to contain the decorations (titlebars, resize handles, shadow regions etc.). > > > 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: that is normal for toolkits - the window size will at least have a minimum size that is determined by the layout and minimum size of widget content. e.g. Length of labels and font size and other factors. Toolkits will generally allow you to resize the window given appropriate widget packing flags/options etc. > 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. Maximized state is a special state for a window. This can work on Wayland. Compositors may choose to ignore this state as being special. E.g. if you have a tiling compositor like sway it may, by policy, ignore this and keep your window small because that is what the user wants/has configured. I would avoid maximizing windows from within application code. It's anti-social. If a user wants the window maximized - they will maximize it. If the compositor thinks it should remember states of a window between sessions, then it can immediately maximize the window the next time it is seen as a new window (surface) and tell your app about this. > Am I being wrong? For both points? > > > > > > 4. How can
Re: Wayland and window position/size
Hi, On Wed, 26 May 2021 at 10:30, Pekka Paalanen wrote: > On Tue, 25 May 2021 22:10:38 -0500 Igor Korot wrote: > > > 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. Pekka's answer is very thorough. As a much shorter version: just use the XDG extensions which already exist for popup/dialog windows. Your application is not the only one which needs to request credentials - so do browsers, mail clients, file managers, and just about everything else. The X11 model is that every application has its own semantics for doing this and decides exactly how to place the window. The client tells the server: place this window at these co-ordinates, at this z position, and give me all the input until I tell you otherwise. The Wayland model is that you tell the Wayland server that you would like to present a dialog or popup window, and which top-level window it should be attached to. It then handles those windows in a completely consistent and uniform way between all your applications, including positioning, stacking, and focus. So, just use that. It works. :) Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland and window position/size
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. 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
Re: Wayland and window position/size
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. Understood. > > > 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? > > > 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. Am I being wrong? For both points? > > > 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? > > > 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? > > > 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? Thank you. > > > Thank you. > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > -- > - Codito,
Re: Wayland and window position/size
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. > 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. > 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. > 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. > 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. > 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. > Thank you. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland and window position/size
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? 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? 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. 4. How can a developer write a program that should connect to the database? 5. I know there was a plan to respect a save/restore window positioning/size. Is it implemented? 6. How complete is Wayland API currently in terms of window positioning/sizing? Thank you. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
