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 deal
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 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
Multihead with wayland, similar to
Dear devs, (not being an expert in Wayland at all) I have been trying in vain to find a solution to use another device as an additional monitor for my desktop. Other people seem to have tried, too¹ (trying to port to Wayland different approaches which could be used with Xorg), and at least at first glance, it doesn't seem like the found a solution. Is there one? Thank you - for your answers, and for this great piece of software. Pietro Battiston ¹ https://superuser.com/questions/1434779/using-a-tablet-as-a-second-monitor-with-wayland https://www.reddit.com/r/wayland/comments/623los/distributed_multi_head_like_using_wayland_similar/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Multihead with wayland, similar to
Hi, Many of Sway (and any wlroots-based compositor) users have set up an headless output plus wayvnc [1] for this use-case. In Sway, a headless output can be created via `swaymsg create_output`, and configured just like any other output. Simon [1]: https://github.com/any1/wayvnc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Multihead with wayland, similar to
On Thu, May 27, 2021 at 08:01:39AM +0200, Pietro Battiston wrote: > Dear devs, > > (not being an expert in Wayland at all) I have been trying in vain to > find a solution to use another device as an additional monitor for my > desktop. > > Other people seem to have tried, too¹ (trying to port to Wayland > different approaches which could be used with Xorg), and at least at > first glance, it doesn't seem like the found a solution. > > Is there one? I don't know of any ready (portable) solutions for this, but with a bit of plumbing work, it could be possible. The building blocks I'm thinking of is Miracast and screen casting with a virtual monitor. A rough summary what would be needed is: * Introduce "virtual" monitor screen recording to org.freedestop.portal.ScreenCast (https://github.com/flatpak/xdg-desktop-portal) and the portal backend relevant to you. * Teach e.g. GNOME Network Displays (https://gitlab.gnome.org/GNOME/gnome-network-displays) how to use virtual monitor recording. * Install a "Miracast sink" app on your device (TVs often have it built in) You could probably replace the second two steps with some VNC/RDP thing, but that will not work for many types of devices where Miracast do. Jonas > > Thank you - for your answers, and for this great piece of software. > > Pietro Battiston > > > ¹ > https://superuser.com/questions/1434779/using-a-tablet-as-a-second-monitor-with-wayland > https://www.reddit.com/r/wayland/comments/623los/distributed_multi_head_like_using_wayland_similar/ > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
