On Tue, 25 May 2021 22:10:38 -0500 Igor Korot <ikoro...@gmail.com> wrote:
> Hi, Carsten, > > On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler <ras...@rasterman.com> wrote: > > > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot <ikoro...@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. 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 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. 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. > > > 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. 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. Thanks, pq
pgpwYFmAN_zwy.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
