Wayland and window position/size

Wed May 26 11:20:09 UTC 2021

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

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

They absolutely should not. They should have nothing to do with the UI. If you
speak SQL to a large DB server over a socket, use sqlite as a smaller
local-file database or berkley db - these do not roll in a UI into the database
library. the vas majority of database access is done by applications on servers
that have no GUI and they absolutely do not want to pull in display systems
that are showing dialogs no one will ever see.

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

As above. It should just not be done. The db should require you pass in
authentication information on connect or set up callbacks to call your code
when this is needed etc. and then YOU provide (in your code) that auth dialog in
a way that is consistent with your application.

If a database library does this all on its own you either have a large hairy
api that has to expose every possible toolkit binding so yo u can do things
like say "the dialog for asking for auth information should be a modal dialog
centered on top of this parent window here" for example. this db has to then
support Qt, GTK, wx, EFL, and not to mention possibly raw wayland surfaces as a
fallback, then also x11 windows, then mac and win32 window handles etc.
etc. ... this db API begins to have an API larger than it's own just to provide
glue to do all the right things with possible UI toolkits and systems.

This makes some database library tied to some specific toolkit/widget set orhas
to pull in every possible toolkit/widget set and that is a horrible idea. I
would never do anything like this if developing a database access library.
Imagine your app uses wxwidgets but the db lib you sue needs Qt for the dialog.
now you pull in 2 different toolkits into your app and the Qt dialog works and
looks totally differently because well.. Qt does have its own look and style and
without serious effort won't match. I write a toolkit of my own too for my
projects and I'd run a thousand miles from any database lib that forces me to
pull in another toolkit that then not only makes my system look inconsistent
but for smaller systems possibly adds 10's or 100's of megabytes of extra
installed libraries and software just to pull in another toolkit for that one
dialog this database library insists on showing itself. I've worked on enough
products to know that this is an instant "no" for that database as bloating out
the install of the base OS on those products is an absolute no-no.

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

set app_id appropriately. Pekka pointed to the xdg shell specs. your toolkit
(wx) should be taking care of this for you.

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

It is discouraged by not making it possible. :) Pekka covered this pretty well.

> Thank you.
> 
> >
> > > Thank you.
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - raster at rasterman.com
> >
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

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