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
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 &
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 st
Re: Is there any example to write a wayland desktop app?
Hi, On Thu, Oct 21, 2021, 03:08 mx wrote: > Hey, >I want to write a GUI library like QT. And I want to directly use > wayland and cairo/opengl. I can't find any good wayland app with menu, > popup menu, and mdi. Can you give me some recommendation? > Why not use Qt? Its already been ported to Wayland AFAIK... Thank you.
Re: Is there any example to write a wayland desktop app?
Hi, On Thu, Oct 21, 2021, 19:53 mx wrote: > Hi, >I just want to write a library. Qt is good enough to be used to write > an excellent app, but that's not my purpose. I now study wayland at " > https://wayland-book.com/introduction.html";. And I need a good example to > get start. Even though the menu, popup and mdi are basic elements, they are > the foundation of almost every apps. > MDI concept is really outdated- it is windows'ism from XX century. Right now even ms is using TABbed interface where every tav can be floated/docked. Thank you. > > ------ Original -- > *From:* "Igor Korot" ; > *Date:* Thu, Oct 21, 2021 07:52 PM > *To:* "mx"; > *Cc:* "wayland-devel"; > *Subject:* Re: Is there any example to write a wayland desktop app? > > Hi, > > On Thu, Oct 21, 2021, 03:08 mx wrote: > >> Hey, >>I want to write a GUI library like QT. And I want to directly use >> wayland and cairo/opengl. I can't find any good wayland app with menu, >> popup menu, and mdi. Can you give me some recommendation? >> > > Why not use Qt? > Its already been ported to Wayland AFAIK... > > Thank you. > >
Re: Is there any example to write a wayland desktop app?
Hi, On Fri, Oct 22, 2021, 02:00 mx wrote: > Hi, >There's even better, do you have any good examples I can work on? > Do you really want to reinvent the wheel? Qt, GTK, wxWidgets- its all libraries you can use. Besides, there is nothing special about Wayland comparing to X. Thank you. > > -- Original ------ > *From:* "Igor Korot" ; > *Date:* Fri, Oct 22, 2021 11:07 AM > *To:* "mx"; > *Cc:* "wayland-devel"; > *Subject:* Re: Is there any example to write a wayland desktop app? > > Hi, > > > > On Thu, Oct 21, 2021, 19:53 mx wrote: > >> Hi, >>I just want to write a library. Qt is good enough to be used to write >> an excellent app, but that's not my purpose. I now study wayland at " >> https://wayland-book.com/introduction.html";. And I need a good example >> to get start. Even though the menu, popup and mdi are basic elements, they >> are the foundation of almost every apps. >> > > MDI concept is really outdated- it is windows'ism from XX century. > > Right now even ms is using TABbed interface where every tav can be > floated/docked. > > Thank you. > > >> >> -- Original -- >> *From:* "Igor Korot" ; >> *Date:* Thu, Oct 21, 2021 07:52 PM >> *To:* "mx"; >> *Cc:* "wayland-devel"; >> *Subject:* Re: Is there any example to write a wayland desktop app? >> >> Hi, >> >> On Thu, Oct 21, 2021, 03:08 mx wrote: >> >>> Hey, >>>I want to write a GUI library like QT. And I want to directly use >>> wayland and cairo/opengl. I can't find any good wayland app with menu, >>> popup menu, and mdi. Can you give me some recommendation? >>> >> >> Why not use Qt? >> Its already been ported to Wayland AFAIK... >> >> Thank you. >> >>
Re: Should I port my custom UI toolkit to Wayland or GTK/QT?
Hi, On Fri, Oct 29, 2021 at 6:59 PM Brad Robinson wrote: > > Hey All, > > I have a custom UI toolkit that I initially developed for my music > application over 15 years ago. Currently it runs on Windows and OSX, and I'd > like to port it to Linux. > > The main thing I'm trying to decide is whether to port directly to Wayland or > to a higher level UI toolkit like GTK or QT. Here's what I'm thinking about. There is no doubt that the UI should be ported to GTK/Qt/wxWidgets. Why do you even ask? Especially since those libraries are capable of being used under both X11 and Wayland. But that not even the main reason. Wayland/X11 is a low-level API where UI doesn't have any business accessing. There is a reason Qt/GTK/wxWidgets libraries exist - to make the cross-platform development nice and smooth. Remember the paradigm: design once - build/run everywhere. Everything else should be irrelevant. Thank you. P.S.: If you do port to wxWidgets you could disregard the Windows/Mac ports. You will have one codebase which will run on all platforms. P.S.S.: Same can be sad for Qt. > > Pros: > > * I really like the elegance of Wayland and think I'd enjoy coding against > it. It seems lightweight and the way of the future for Linux desktop apps. > * I've written a partial, proof of concept C# wrapper for Wayland which seems > to work fine. (my toolkit is written in C#) > * My toolkit already includes implementations of every control/widget I need > (including menus) so I don't need much of what GTK/QT provides. Wayland > seems like a nice fit in this regard. > * Regarding GTK/QT I'm not keen to learn yet another UI API unless I really > have to. I've dabbled with GTK and didn't really like it. I've never used QT > but it seems over the top for my needs and possibly difficult to call from > C#. Wayland seems simple in comparison. > * I use Skia for graphics rendering. So long as I can blit to the screen and > get user input it should port reasonably well. > > Cons: > > * Seems like I might need to implement window decorations myself as I > understand not all Wayland compositors provide this. > * System dialogs - in particular file and folder selection dialogs. I'd need > to either implement these myself or figure out how to invoke GTK/QT versions? > * IME support - I believe this is outside the scope of Wayland. > * Automation/Accessibility - again outside the scope of Wayland. > * OS theme consistency. > > I think all the cons are workable - either I'm happy to put in the work to > get it done (cons 1 and 2) or I can live without if I have to (cons 3 and 4), > or I'm not that fussed about (con 5) > > Other notes: > > * Porting my apps from my toolkit to GTK or QT is out of the question as that > would entail porting literally hundreds of screens, dialogs and widgets. > * I'm a long time Windows developer but I've never done Linux desktop > development. > * I'm not the only one in this boat. The AvaloniaUI project is very similar > to my toolkit and while I can't speak for them, they currently use X11 and I > believe will have similar issues when it comes to Wayland, Accessibility and > IME. > * I'd also really like support for OpenGL. Not a deal breaker but I presume > it's available through Wayland. > * My toolkit is closed source and only used by apps I develop - it's not > likely that it will suddenly have lots of additional requirements placed on > it besides what I'm currently considering. > * I don't have any particular distros that I need to support. If my app only > works on particular distros then so be it. > * It's not urgent and I'm willing to put in the time. > > So, with all that in mind, here's my questions: > > 1. Wayland, GTK or QT? > 2. Are there options for IME and Accessibility for pure Wayland apps? > 3. Assuming I go with Wayland, is there a Linux distro you would recommend > that includes a good, regularly updated, feature rich Wayland compositor. > (Unless there's a compelling reason to, I'd prefer not to have to compile a > compositor myself). > 4. Any other advice - am I neglecting to consider anything obvious? > > Sorry for the long post... much to think about and any advice greatly > appreciated. > > Brad >
Re: Should I port my custom UI toolkit to Wayland or GTK/QT?
Hi, On Sun, Oct 31, 2021, 20:16 Brad Robinson wrote: > Hi Igor, > > Thanks for taking the time to answer. > > It sounds like you're suggesting porting the application to a new toolkit > rather than updating the toolkit? > IIUC, you application does not use any cross-platform toolkit - i.e. it uses Win32/MFC on Windows and Carbon/Cocoa on OSX. Unfortunately both are not available on *nix. It would, of course be nice to use something cross-platform in the beginning, but... And yes - my suggestion is to use the cross-platform library and port your application to it. Using low level API for a high level tasl - it is not really feasible. Especially, since wayland API is still changing. And there too many systems on the market, which use X11 protocol. As mentioned, that's not really feasible as I have literally hundreds of > screens that would need to be ported. Porting my existing toolkit - either > directly to X11, Wayland or by leveraging an existing toolkit seems an > easier option. > This is the solution I'm talking about - use GTK, QT or wxWidgets and forget about wayland, x11 or any other low-level things. > Would you say the same about AvaloniaUI... that instead of porting > Avalonia, every app that uses it should move to a new toolkit? > I don't know anything about that. Thank you > Brad > > On Sat, Oct 30, 2021 at 3:07 PM Igor Korot wrote: > >> Hi, >> >> On Fri, Oct 29, 2021 at 6:59 PM Brad Robinson >> wrote: >> > >> > Hey All, >> > >> > I have a custom UI toolkit that I initially developed for my music >> application over 15 years ago. Currently it runs on Windows and OSX, and >> I'd like to port it to Linux. >> > >> > The main thing I'm trying to decide is whether to port directly to >> Wayland or to a higher level UI toolkit like GTK or QT. Here's what I'm >> thinking about. >> >> There is no doubt that the UI should be ported to GTK/Qt/wxWidgets. >> >> Why do you even ask? >> >> Especially since those libraries are capable of being used under both >> X11 and Wayland. >> >> But that not even the main reason. >> >> Wayland/X11 is a low-level API where UI doesn't have any business >> accessing. >> >> There is a reason Qt/GTK/wxWidgets libraries exist - to make the >> cross-platform development >> nice and smooth. Remember the paradigm: design once - build/run >> everywhere. >> >> Everything else should be irrelevant. >> >> Thank you. >> >> P.S.: If you do port to wxWidgets you could disregard the Windows/Mac >> ports. You will have one >> codebase which will run on all platforms. >> >> P.S.S.: Same can be sad for Qt. >> >> > >> > Pros: >> > >> > * I really like the elegance of Wayland and think I'd enjoy coding >> against it. It seems lightweight and the way of the future for Linux >> desktop apps. >> > * I've written a partial, proof of concept C# wrapper for Wayland which >> seems to work fine. (my toolkit is written in C#) >> > * My toolkit already includes implementations of every control/widget I >> need (including menus) so I don't need much of what GTK/QT provides. >> Wayland seems like a nice fit in this regard. >> > * Regarding GTK/QT I'm not keen to learn yet another UI API unless I >> really have to. I've dabbled with GTK and didn't really like it. I've >> never used QT but it seems over the top for my needs and possibly difficult >> to call from C#. Wayland seems simple in comparison. >> > * I use Skia for graphics rendering. So long as I can blit to the >> screen and get user input it should port reasonably well. >> > >> > Cons: >> > >> > * Seems like I might need to implement window decorations myself as I >> understand not all Wayland compositors provide this. >> > * System dialogs - in particular file and folder selection dialogs. >> I'd need to either implement these myself or figure out how to invoke >> GTK/QT versions? >> > * IME support - I believe this is outside the scope of Wayland. >> > * Automation/Accessibility - again outside the scope of Wayland. >> > * OS theme consistency. >> > >> > I think all the cons are workable - either I'm happy to put in the work >> to get it done (cons 1 and 2) or I can live without if I have to (cons 3 >> and 4), or I'm not that fussed about (con 5) >> > >> > Other notes: >> > >> > * Porting my apps from my toolkit to GTK or QT
Re: Window positions under wayland
On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: > > On Thursday, August 4th, 2022 at 19:00, samuel ammonius > wrote: > > > apps such as popups and dialogs are usually supposed to start either > > at the center of the screen or the center of their parent app You are barking at the wrong tree. Apparently this is the main feature of the Wayland - do not let the developers set up the position of the TLW. > > That's usually what compositors do: center apps by default. But it's to > the compositor and user preference. > > > apps often want to remember where they were when they closed so they > > can open there again > > This is what [1] addresses. > > [1]: > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 Finally!! ;-) Now if only Wayland can respect the calls such as CenterOnScreen()/CenterOnParent() for the dialog-like windows it would be great. Unfortunately it looks like this will never happen and the application developers will have to throw away their software, because apparently dialogs can be put anywhere on the screen. Something like a dialog asking for credentials to login to the DB that shows up in the top left corner, because some idiot user set it this way. Thank you.
Re: Window positions under wayland
Hi, On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius wrote: > > Compositors can prevent apps from doing this if they want to, but there needs > to be some built-in way for windows to set their positions. Not having this > isn't a feature. I am not a Wayland developer. But based on the multiple replies here and there - it is the main feature of the Wayland. It will never allow the application to set its position/size. It will however allow the end-user (a human) to configure Wayland (compositor) in any waythey want and however stupid they want. And Wayland developers consider it to be "BIG WAYLAND FEATURE". So forget about cross-platform applications behaving the same, forget about even writing sane application on Linux. Wayland (compositor) will be set up by the user (a human) in such a way so that the application could become completely unusable. Thank you. > > On Thu, Aug 4, 2022 at 2:57 PM Igor Korot wrote: >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: >> > >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius >> > wrote: >> > >> > > apps such as popups and dialogs are usually supposed to start either >> > > at the center of the screen or the center of their parent app >> >> You are barking at the wrong tree. >> >> Apparently this is the main feature of the Wayland - do not let the >> developers >> set up the position of the TLW. >> >> > >> > That's usually what compositors do: center apps by default. But it's to >> > the compositor and user preference. >> > >> > > apps often want to remember where they were when they closed so they >> > > can open there again >> > >> > This is what [1] addresses. >> > >> > [1]: >> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 >> >> Finally!! ;-) >> Now if only Wayland can respect the calls such as >> CenterOnScreen()/CenterOnParent() >> for the dialog-like windows it would be great. >> >> Unfortunately it looks like this will never happen and the application >> developers will >> have to throw away their software, because apparently dialogs can be >> put anywhere >> on the screen. >> >> Something like a dialog asking for credentials to login to the DB that >> shows up in the >> top left corner, because some idiot user set it this way. >> >> Thank you.
Re: Window positions under wayland
Hi, On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius wrote: > > Dude, I'm trying to persuade the wayland devs to change this, not have an > argument about how much wayland sucks. Thanks for explaining that this was > supposed to be a feature though. I hadn't known that before. You most welcome. And like I said - you are not the only one. Others tried and failed. They think its a feature and will tell you "Its by design". Thank you. > > On Thu, Aug 4, 2022 at 3:14 PM Igor Korot wrote: >> >> Hi, >> >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius wrote: >> > >> > Compositors can prevent apps from doing this if they want to, but there >> > needs to be some built-in way for windows to set their positions. Not >> > having this isn't a feature. >> >> I am not a Wayland developer. >> >> But based on the multiple replies here and there - it is the main >> feature of the Wayland. >> It will never allow the application to set its position/size. >> It will however allow the end-user (a human) to configure Wayland >> (compositor) in any waythey want >> and however stupid they want. >> >> And Wayland developers consider it to be "BIG WAYLAND FEATURE". >> >> So forget about cross-platform applications behaving the same, forget >> about even writing sane application on Linux. >> Wayland (compositor) will be set up by the user (a human) in such a >> way so that the application could become >> completely unusable. >> >> Thank you. >> >> > >> > On Thu, Aug 4, 2022 at 2:57 PM Igor Korot wrote: >> >> >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: >> >> > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius >> >> > wrote: >> >> > >> >> > > apps such as popups and dialogs are usually supposed to start either >> >> > > at the center of the screen or the center of their parent app >> >> >> >> You are barking at the wrong tree. >> >> >> >> Apparently this is the main feature of the Wayland - do not let the >> >> developers >> >> set up the position of the TLW. >> >> >> >> > >> >> > That's usually what compositors do: center apps by default. But it's to >> >> > the compositor and user preference. >> >> > >> >> > > apps often want to remember where they were when they closed so they >> >> > > can open there again >> >> > >> >> > This is what [1] addresses. >> >> > >> >> > [1]: >> >> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 >> >> >> >> Finally!! ;-) >> >> Now if only Wayland can respect the calls such as >> >> CenterOnScreen()/CenterOnParent() >> >> for the dialog-like windows it would be great. >> >> >> >> Unfortunately it looks like this will never happen and the application >> >> developers will >> >> have to throw away their software, because apparently dialogs can be >> >> put anywhere >> >> on the screen. >> >> >> >> Something like a dialog asking for credentials to login to the DB that >> >> shows up in the >> >> top left corner, because some idiot user set it this way. >> >> >> >> Thank you.
Re: Window positions under wayland
Hi, Carsten,
On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler wrote:
>
> On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said:
>
> > Hi,
> >
> > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius
> > wrote:
> > >
> > > Dude, I'm trying to persuade the wayland devs to change this, not have an
> > > argument about how much wayland sucks. Thanks for explaining that this was
> > > supposed to be a feature though. I hadn't known that before.
> >
> > You most welcome.
> > And like I said - you are not the only one. Others tried and failed.
> >
> > They think its a feature and will tell you "Its by design".
>
> It is by design. And it's right. From decades of apps being able to position
> in
> X11 and expecting to be able to and then screwing it up again and again and
> again... Wayland got it right.
I'm not sure what you mean.
Can you give an example of "screwing again and again and again...", please?
If my code expects the window to be placed at 1 monitor position (100, 100) -
what is wrong with that?
All I can do as a developer is to write:
[pseudo-code]
MyApp:MyApp()
{
myTLW = new Frame( NULL, ID, "My Beautiful Window", position(
100, 100 ), defaultsize, tlwstyles );
mytklw-> Show( true );
}
[/pseudo-code]
What is wrong with that?
Thank you.
>
> If you allow positioning then apps RELY on it. They act is totally broken ways
> when the compositor refuses to allow that. The right thing to do is to remove
> their expectation of such control.
>
> Apps can use subsurfaces which can position RELATIVE to a parent (e.g. used
> for
> menu popups etc. but could be used for dialogs). You could also just draw a
> dialog inline inside your main window and do whatever you want inside of that.
> This is up to your app (and whatever toolkit it may use if it uses one).
>
> It is the apps' job to indicate a dialog is a dialog for a parent surface. if
> they do then the compositor SHOULD place that dialog relative to that surface
> sensibly (e.g. centered). If it doesn't do something sensible OR do what the
> user has explicitly configured it to do because the user wants something
> broken (and the compositor allows it), then that compositor needs
> improving/fixing. It's easier to fix a few compositors than it is to fix the
> endless chain of 100's of broken applications.
>
> > Thank you.
> >
> > >
> > > On Thu, Aug 4, 2022 at 3:14 PM Igor Korot wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius
> > >> wrote:
> > >> >
> > >> > Compositors can prevent apps from doing this if they want to, but there
> > >> > needs to be some built-in way for windows to set their positions. Not
> > >> > having this isn't a feature.
> > >>
> > >> I am not a Wayland developer.
> > >>
> > >> But based on the multiple replies here and there - it is the main
> > >> feature of the Wayland.
> > >> It will never allow the application to set its position/size.
> > >> It will however allow the end-user (a human) to configure Wayland
> > >> (compositor) in any waythey want
> > >> and however stupid they want.
> > >>
> > >> And Wayland developers consider it to be "BIG WAYLAND FEATURE".
> > >>
> > >> So forget about cross-platform applications behaving the same, forget
> > >> about even writing sane application on Linux.
> > >> Wayland (compositor) will be set up by the user (a human) in such a
> > >> way so that the application could become
> > >> completely unusable.
> > >>
> > >> Thank you.
> > >>
> > >> >
> > >> > On Thu, Aug 4, 2022 at 2:57 PM Igor Korot wrote:
> > >> >>
> > >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote:
> > >> >> >
> > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius
> > >> >> > wrote:
> > >> >> >
> > >> >> > > apps such as popups and dialogs are usually supposed to start
> > >> >> > > either
> > >> >> > > at the center of the screen or the center of their parent app
> > >> >>
> > >> >> You are barking at the wrong tree.
> > >> >>
> > >> >> Apparently this is the main feature of the Wayland - do not let the
> > >&g
Re: Window positions under wayland
Hi, Carsten,
On Thu, Aug 4, 2022 at 6:02 PM Carsten Haitzler wrote:
>
> On Thu, 4 Aug 2022 14:46:40 -0500 Igor Korot said:
>
> > Hi, Carsten,
> >
> > On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler
> > wrote:
> > >
> > > On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said:
> > >
> > > > Hi,
> > > >
> > > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius
> > > > wrote:
> > > > >
> > > > > Dude, I'm trying to persuade the wayland devs to change this, not have
> > > > > an argument about how much wayland sucks. Thanks for explaining that
> > > > > this was supposed to be a feature though. I hadn't known that before.
> > > >
> > > > You most welcome.
> > > > And like I said - you are not the only one. Others tried and failed.
> > > >
> > > > They think its a feature and will tell you "Its by design".
> > >
> > > It is by design. And it's right. From decades of apps being able to
> > > position in X11 and expecting to be able to and then screwing it up again
> > > and again and again... Wayland got it right.
> >
> > I'm not sure what you mean.
> > Can you give an example of "screwing again and again and again...", please?
> >
> > If my code expects the window to be placed at 1 monitor position (100, 100)
> > -
> > what is wrong with that?
> >
> > All I can do as a developer is to write:
> >
> > [pseudo-code]
> > MyApp:MyApp()
> > {
> > myTLW = new Frame( NULL, ID, "My Beautiful Window", position(
> > 100, 100 ), defaultsize, tlwstyles );
> > mytklw-> Show( true );
> > }
> > [/pseudo-code]
> >
> > What is wrong with that?
> >
> > Thank you.
>
> let me begin with just a few examples:
>
> 1. window outer frame is decided by wm at runtime. not client (in x11 - you
> are
> asking about broken examples so they all come from x11). application has no
> idea
> what frame the wm may choose this time. user may have changed what frame they
> use by default. they may have changed theme which changes frame sizes. they
> may
> have changed fonts, other sizing factors in wm config which then result in the
> border being put off-screen or in a weird place. clients start to make
> assumptions that wm's will reparent windows in specific ways and add larger
> frames that are immediate children of root when a wm could do anything but
> they
> all decided to assume this which was a false assumption. they go figuring out
> their inner frame client window vs the immediate child of root to guess frame
> size. this has broken any wm that tries to create a frame that holds multiple
> client windows that are not basically stacked on top of each other. the whole
> idea of icccm and wm policies in theory allow this but invalid client
> assumptions have broken the ability to make experiences better for users.
I don't know what is "Window outer frame".
Are you talking about window decorations, such as borders and title bar?
On top of that - this example talks about sizing. I didn't see anything there
which said "window position". You even explicitly mention sizing there.
Now given my pseudo-code I believe it will be handled nicely in X11 - the window
will be placed at position (100, 100) and will be automatically sized
based on the content.
Not a good example here.
>
> 2. clients are almost all dumb when it comes to dynamic changes. they remember
> their position relative to 0,0 of root generally, but then many forget to
> remember it relative to an xrandr screen and adapt when that xrandr screen
> changes. there is no way to say "put my window at x,y relative to THIS screen"
> only to ask for specific global geometry relative to root, so if screen layout
> changed between invocations - the client gets all their remembered geometry
> wrong. i've seen this countless times and it is the norm for clients - they do
> not adapt to screen layout changes pretty much at all. change resolution,
> rotation, if your monitors are laid out left to right, top to bottom etc. ...
> they just dumbly decide they need to be at 100,213 and want to be there again
> regardless of what changed with screens in the mean time.
When you say "clients" - are you talking about software, TLW or developer?
Now I don't see a problem with that. If I'm an end-user of the software, I want
to open it each time at the same position. It is called "Persistency".
So lets go back to my example.
The very first time the application starts -
Re: Window positions under wayland
Hi, Thiago, On Thu, Aug 4, 2022 at 8:09 PM Thiago Macieira wrote: > > On Thursday, 4 August 2022 16:01:23 PDT Carsten Haitzler wrote: > > there might be bigger picture ideas BEHIND that like "i have a password > > dialog for my db app" - then great. make that dialog as such and make sure > > the compositor knows what window it is a dialog for and a good > > wm/compositor will just magically open it centered over the parent window > > (or over the top center or bottom-right corner or whatever the policy that > > wm has for dialogs is - but at least it's now consistent for all apps with > > dialogs - if that is what the wm does - enforce consistency). if the > > wm/compositor does stupid things with dialogs and places them at $RANDOM > > positions then feel free to yell at the compositor for being stupid. there > > are very many fewer wm and compositors out there to yell at than there are > > applications to yell at, so it's more scalable to have the fixes put in > > compositors not apps. if you absolutely MUST have fine control over this .. > > as i said - you can render in-line in your window, use subsurfaces etc. but > > then you are limited as i described. > > Indeed, this is mostly an X/Y problem. > > You have an X problem (unrelated to X11, just using the letter of the > alphabet) and you think you need Y to achieve it, as in the example above: in > order to properly place some dialog, the application needed to get the > absolute position of the window it's going to be relative to and then position > the new window at a specific absolute position. So we get people coming and > asking about how to do Y (this implementation). > > Instead, we need to know what the X problem was: properly positioning the sub- > window or sibling window, or application window reappearing close to where > you've last seen it. There are probably better ways of solving that problem > than the reintroducing all the legacy that Carsten is talking about. Please check my reply to Carsten. You will see 2 code snippets and the explanation of some stuff I'm looking for as well as a critique of Carsten's sample. I do think some samples are legitimate, but doing what Wayland is doing is not a solution for them. Thank you. > > This is why Wayland developers keep saying that absolute positions being > unavailable is a feature, not a bug. There may come a time when the number of > protocol extensions to support all the little things that one could do with > absolute positioning becomes a burden, but we're not there and have yet to see > a problem that can't be solved differently. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel DCAI Cloud Engineering > > >
Re: Window positions under wayland
Hi, Thiago, On Thu, Aug 4, 2022 at 9:20 PM Thiago Macieira wrote: > > On Thursday, 4 August 2022 18:01:34 PDT Igor Korot wrote: > > The very first time the application starts - it will be at position > > (100,100) Then user drags the window to a position (50, 50) and closes the > > application. When he tries to open it next time - (s)he expects the window > > to be placed at position (50, 50). > > Rephrasing in Wayland's world: the first time the window opens, it opens at a > position determined by the compositor. Why? Every system in *nix world is different and therefore uses different WM/compositor If the window position is defined by the WM/compositor, it means I, as a developer, can't write portable code. > The user drags the window, then closes. > The next time the window opens, if the compositor was configured to do so, it > will open where it was last seen. > > I don't see anything wrong with this. Wrong. The window position is defined by the compositor. So if my window position is (50, 50 ) before closing, but the compositor dictates the window to be placed in the center of the screen - it will be placed in the center of the screen. No matter what I, or the user of my application, will do. And yes - I do see a problem with that (see above - no portable code). > > > Resolution changes should affect the sizing - not position. > > No, they are about position too. 100,100 on a 1920x1080 resolution is about 5% > to the right of the left edge and 10% from the top. 100,100 on 3840x2160 is > 2.5% from the left and 5% from the top, on the same monitor. The user has a > right to expect the same finger-width position on the screen, relative to > where > their eyes are looking at. No, they are not. It should be up to the application to decide the coordinate system PPI/DPI/etc. A human being shuold expect the application to be open dependent on the documented way the application is opening. If the documentation says - "expect the window to open at (100, 100) in DPI coordinates" - this is where I will look. Everything else will be considered a bug of the UI. But with Wayland - opening a window at (100, 100 ) is not possible because a compositor in a vast majority of cases will override that. And the window might be opening at position ( 1000, 1000 ) for FWIW. Will you expect that? I certainly won't. > > > Again when you say "clients" - are you talking about software or developers. > > He's talking about applications. Terminology from X11 and Wayland: the X11 > server and the Wayland compositor are servers, the applications connect to > them and are thus clients. > > > However, please remember that HiDPI monitors for laptop is relatively > > new things > > They've existed for at least 10 years and have become ubiquitous in the last 5 > or 6. Regardless of whether you've got one or most people have one, we have to > design the future for them. Correct. > > > We are now talking about the OS and physically plug or unplug the monitor. > > Plugging in the new monitor shouldn't affect anything on the way the > > application starts. > > Yes, it should, if the primary monitor changes. Plugging in a new monitor shouldn't affect the primary monitor, as "primary != new". After doing so the user can go and choose his primary monitor, but that is completely different from plugging in the monitor. I hope you see my point.(9)% > Right now, I am writing to you > on a 4K monitor @ 3840x2160 resolution, located to the right of the laptop > screen (also 4K @ 3840x2400). My primary monitor is the one big one, on the > right, not the one that contains (0,0). That's the one I am looking at, and I > have positioned it so it's in front of me and my eyes are level with about 1/3 > from the top of the monitor. I expect application windows to show up in front > of me, not 30° to my left and 15° downward angle, which is where the laptop > is. Any application that remembers its absolute position has, by simple > construction, *buggy* UX. Absolutely agree with the above sentence. Applications should define what coordinate system they will use and store the coordinates appropriately. Moreover - they shouldn't save their size as it will be determined by the content of the window. I hope you agree with my last sentence. > And on X11, this happens a lot. The email compositor > window I'm sorry - what is "an E-mail compositor window"? Are you saying that every application in Wayland will have its own compositor? Or am I missing something? > *always* shows on the left monitor, regardless of where the mouse > pointer is or I last closed it. One of my browsers shows up on the last > monitor which I used it, which means about 50%
Re: Window positions under wayland
Hi, Daniel, On Fri, Aug 5, 2022 at 8:41 AM Daniel Stone wrote: > > On Fri, 5 Aug 2022 at 14:11, samuel ammonius wrote: > > Please don't close this discussion on account of something someone > > else said. Wouldn't it be better for users, compositors, and apps if there > > was a way to manage window positions, but the compositor could choose > > not to let them? The best apps typically have an option in the preferences > > for windows to remember their positions, and window managers are given > > the option to move/resize windows as they please. Window managers can > > then let users decide weather they want to let windows choose their own > > size/position or stay put (such as in tiling window managers). Why wouldn't > > Wayland benifit from a similar system? (I'm assuming that the reason you > > said "for better or for worse" was just so everyone could stop talking > > rather > > than because you actually wouldn't mind having a worse system in place) > > It's not inherently better or worse, just different. > > For things like remembering window positions, there has already been a > specific protocol written to handle that usecase linked in this > thread, which is more flexible and capable than having every client > save their last-seen position and forcibly restore it no matter what. What do you mean "forcibly restore, no matter what"? And why do we need a whole protocol just for saving/restoring window position? Isn't it simply overkill? Thank you. > > Cheers, > Daniel
Re: Window positions under wayland
Hi, Samuel, On Fri, Aug 5, 2022 at 3:21 PM samuel ammonius wrote: > > I don't understand what all the talk is about when discussing whether > it should be up to the compositor or app to set a window's position. Right now under Wayland ONLY the compositor decides the position where the window is created. Always!! No exceptions. Thank you. > > On Fri, Aug 5, 2022 at 2:30 PM Daniel Stone wrote: >> >> On Fri, 5 Aug 2022 at 17:21, Igor Korot wrote: >> > On Thu, Aug 4, 2022 at 9:20 PM Thiago Macieira wrote: >> > > No, they are about position too. 100,100 on a 1920x1080 resolution is >> > > about 5% >> > > to the right of the left edge and 10% from the top. 100,100 on 3840x2160 >> > > is >> > > 2.5% from the left and 5% from the top, on the same monitor. The user >> > > has a >> > > right to expect the same finger-width position on the screen, relative >> > > to where >> > > their eyes are looking at. >> > >> > No, they are not. >> > It should be up to the application to decide the coordinate system >> > PPI/DPI/etc. >> >> This is why there is no value in this discussion. You are making >> assertions like this as if they are axiomatic. >> >> It would be possible to redesign Wayland following the principles you >> have described. No-one is doing this, however. We have carefully >> considered the points you have raised over the past 14 years and >> reached different conclusions. I'm sorry that Wayland is not the >> perfect window system you envisage in your own head, but just >> repeating your same beliefs that the design is fundamentally flawed >> over and over, will not force us to change the design.
Re: Use-case when positioning a window is necessary
Hi, On Mon, Aug 8, 2022, 8:38 AM Benoît Gschwind wrote: > Hello, > > After a quick reading of your DevHelp case, I think the issue belong > devhelp and your app that using it. DevHelp have to provide an API to > be embeded in another application and Wayland protocol should not be > involved. Maybe d-bus can be used as pipe between DevHelp and others > applications. > Problem is - DevHelp is like a plug-in- it can be used with a thousands of applications, not just a specific one. And DevHelp don't have control over them. So you reading comprehension is too fast. :-) Thank you > Best Regards > > Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit : > > Hi, > > > > I've seen the discussion this month about positioning windows. > > > > The use-case is something concrete: the Devhelp [1] assistant window. > > > > For some background, Devhelp (and libdevhelp) is implemented > > flexibly: > > it can be used as a standalone app, it can be integrated into GTK > > IDEs, > > the standalone app can be called to search or open a symbol. > > > > And there is the Devhelp assistant window: it is typically used by a > > text editor, to ask Devhelp to show a small window with the > > documentation for the symbol under the cursor. > > > > And that is where positioning is necessary: to not occlude the line > > of > > text where the cursor is, and to show the documentation at a sensible > > place (near the cursor position). > > > > With Wayland, this should be implemented with a subsurface. I may be > > wrong, but in this case it's not possible, because it's not the same > > app (the same process). > > > > (For example you open a terminal, then open Vim, then you press a key > > and it opens the Devhelp assistant window). > > > > So, what would be your suggestion in such a use-case? To still retain > > the flexibility of Devhelp. > > > > Thanks, > > Sébastien > > > > [1] https://wiki.gnome.org/Apps/Devhelp (an API browser) > >
Re: Position set/get prototype template
Hi, Simon, On Mon, Aug 8, 2022, 9:37 AM Simon Ser wrote: > Hi, > > As we already tried to explain numerous times in the previous thread: > no, we are not adding requests and events to set/get the window position. > > If you are interested in fixing an app which doesn't work on Wayland > because of this omission, please explain your use-case, and we can > discuss solutions. > My app that I'm still building will "not" work on Wayland reliably. I tried at least 2 times to give very specific scenarios and was told to go away. No explanation, possible fixes or workarounds. Just plain "we are not doing because it's by design". I guess people (Software developers) will have to pray X11 will stay forever. Thank you. > If you are not interested in explaining the use-cases, and are just > interested in blindly adding new features: sorry, but this isn't how we > want to approach things. > > Thanks, > > Simon >
Re: Position set/get prototype template
Hi, On Mon, Aug 8, 2022, 9:27 AM samuel ammonius wrote: > Hi, > > I started a discussion a while ago about the possibility of adding > position set/get abilities to wayland, but since then I'd learned alot > about how wayland works. I had heard that wayland combines the WM and > server into one "compositor", but I thought wayland itself still managed > some things. Since then I've learned that the compositor manages every > event that a wayland client sends, and I think this makes the ability to > set/get a position even more necessary. > On top of that, the end user (a human sitting behind the monitor) can reconfigure everything, because "we all know better and computers are dumb". The reasons are: > >1. Apps can send both the position they want for a window and and the >type of window, and a compositor can choose which one to follow. (for >example, a client can send (width/2, height/2) and "popup" for a popup >surface, and compositors that prefer to follow the descriptive design will >follow "popup" and ones that prefer prescriptive design will follow the >coordinates). >2. Waylands asynchronous event system means that a compositor can ask >users if they would like to give an app permission to move itself and/or >other windows, similar to how android asks before giving apps camera/GPS >permissions. > > I've looked at existing wayland protocols and used them to create a simple > one for position set/get. > > -- > > > > Copyright © 2022 Samuel AmmoniusPermission is hereby > granted, free of charge, to any person obtaining acopy of this software > and associated documentation files (the "Software"),to deal in the > Software without restriction, including without limitationthe rights to > use, copy, modify, merge, publish, distribute, sublicense,and/or sell > copies of the Software, and to permit persons to whom theSoftware is > furnished to do so, subject to the following conditions:The above > copyright notice and this permission notice (including the nextparagraph) > shall be included in all copies or substantial portions of theSoftware. > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS IN THE SOFTWARE. > > Used to set/get the position of a surface. The > ability to set the monitor that a surface is on is not available yet. > > > Warning! The protocol described in this file is experimental and > backward incompatible changes may be made. Backward compatible changes > may be added together with the corresponding interface version bump. > Backward incompatible changes are done by bumping the version number in > the protocol and interface names and resetting the interface version. > Once the protocol is to be declared stable, the 'z' prefix and the > version number in the protocol and interface names are removed and the > interface version number is reset. > > > Set the position of a surface > >summary="target surface"/> > > > > > >Notification that a surface has been moved, either by > itself, another program, or the compositor. > > WARNING: Do not use this event to force a surface to a certain > position. If multiple apps want the surface in a different position, then the > computer may freeze or glitch. > > > > > > > > > > > > > > > > > > > > > > -- > > Should I just send it or is my reasoning (or XML syntax) wrong? > >
Re: Position set/get prototype template
Or even better - when one of you will need to quickly create a "proof-of-concept" application that will jump all over the places on every startup... Thank you. On Mon, Aug 8, 2022, 9:37 AM Simon Ser wrote: > Hi, > > As we already tried to explain numerous times in the previous thread: > no, we are not adding requests and events to set/get the window position. > > If you are interested in fixing an app which doesn't work on Wayland > because of this omission, please explain your use-case, and we can > discuss solutions. > > If you are not interested in explaining the use-cases, and are just > interested in blindly adding new features: sorry, but this isn't how we > want to approach things. > > Thanks, > > Simon >
Re: Need support to display application at (0, 0) position on Weston desktop
Hi, I believe with any Wayland stuff you will fail to use absolute positioning. you absolutely have to use X11 and forget about Wayland.. The Wayland devs are NOT CONVINCED enough to support absolute positioning and will just tell you to use X11. THank you. On Thu, Jul 13, 2023 at 9:55 AM huy nguyen wrote: > > Hi Pekka, > > Thank you for your helpful feedback. > I understand all your points and will take a look to provide a custom logic > to weston desktop to support my use-cases. > > Best regards, > Huy > > On Thu, Jul 13, 2023 at 5:07 PM Pekka Paalanen wrote: >> >> On Wed, 12 Jul 2023 21:38:06 +0700 >> huy nguyen wrote: >> >> > Hi all, >> > >> > I have a Linux system based on weston wayland. I run MPV player and expect >> > it displays a video window at (0,0) position on the screen (top left corner >> > of the display). I already use x11egl backend option to MPV to support a >> > fixed position to application but the video window of MPV is displayed at >> > an offset (X offset, Y offset) from (0,0) position as shown by the picture >> > below: >> > >> > [image: IMG_6944.jpg] >> > >> > Can we have a support from weston wayland to position (0,0) to application >> > running on Xwayland backend? >> >> Hi, >> >> I think the gap you see is the window decorations. Weston's X11 Window >> Manager (XWM) and demo clients have a fairly wide margin around window >> decorations. So the window actually is at (0, 0) already, and the gap >> is really just the decorations. >> >> Maybe you can tell mpv to tell XWM to not decorate the window at all, >> or maybe you can make the position slightly negative to close the gap. >> >> However, if this is a not general use desktop, and kiosk-shell does not >> fit, the I'm afraid the only reliable way to get exactly the window >> management behaviour you want overall is to fork and modify Weston's >> desktop-shell plugin. I mean, maybe you would also like the video >> window to stay on top regardless of where the user is touching/clicking. >> >> Composing an application from multiple independent programs like video >> players necessarily requires the window manager to be part of the >> application. As window managers are built into Wayland compositors, you >> have to change the compositor. In Weston case that happens by loading >> a different "shell" plugin. >> >> Usually if you want an application to embed a video player, you do that >> with video playing libraries inside the application, and not by adding >> an external video player which then requires careful window management. >> >> >> Thanks, >> pq
Questions about mmonitor
Hi, All, Have 2 questions: 1. I'm using GNOME with Wayland on Gentoo and I have a touch screen on this laptop There is a sporadic mouse movement and clicks (without me interacting with miuse) and a monitor picture is sporadically switching between workspaces. I was told that it is a touch screen + Wayland and I have to switch to X11 to make it work. Is there an anticipated time frame when it will be fixed? 2. Saving and restoring windows position- is it implemented all around? If not - what is the plan? Thank you.
Sizing of TLW
Hi, ALL, id like to ask - why people here decided not to allow SetPosition()/SetSize() for the TLW to be available? Imagine you work on the text editor. Initially the text editor window should come up empty. Does this mean that the size of the main window will be very small? Or consider working on graphic editor. Main window working area will either be empty or it will not contain any controls - just painting figures. Which means the size of the window cannot be determined. How do developers should handle all this across different compositor? Also - for both use-cases. Let's say i call CenterOnScreen() for the TLW. In this case as any normal/salesperson, I'd expect the program to be centered on the screen 0 on the first run. And then on any subsequent runs it will be retrieved from the user preferences. Again - that what normal, sane person would expect for both position and size. If I can get how people handle this under wayland (all 3 scenarios), I would be really grateful. Thank you.
