The Ongoing Work For Native Wine Wayland Support

[oiaohm]

There's no good alternative because AutoHotkey is the best. That's the point. And Windows enables it..

At this point Weasel as lost argument. Claiming no good alternative does not mean anything.
Nothing you have said makes AutoHotkey the best.

Moving a window relative to another window means absolute positioning for YOUR SCRIPT because it's not relative to your script's window. In other words, it needs to know the absolute position of the target window so that it moves the other window relative to it. The script needs to know that window's absolute position to do this math.

Is this statement true. No it not Weasel. Simple thing as wine virtual desktop proves that are garbage logical positioning is not a new thing...

All this really need is a common anchor point. Exactly why cannot the target window be the anchor and offset to other windows provide in that math format.

Weasel look at how Wayland popup work with xdg_positioner

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249

Or take a good read of 249.

Question Weasel why is the script doing the maths using absolute position values in the first place. Remember between the time the script does the maths to work out where it should place window the absolute position data of the window can be out of date.

Relative position moves the final maths to the compositor. From top left conner of Z window place my Windows X/Y offset. This is how xdg_positioner is doing it for popup windows.

This is the problem Weasel absolute position information on an application windows be it X11 or Windows is always out of date. You have a race condition problem.

Doing relative position by having the compositor/output side process it means you avoid these screw ups.

Weasel think about what will know if a window has been moved.
Windows lacks relative positioning in any decent way.

What has the most current information of windows positioning?

Weasel answer the above question truthfully. Script using absolute position information does not have most current information of window positioning.

In Wayland the item is always the Wayland compositor with the most current information right.

There is a problem of course Weasel does not want to admit autohotkey has a flaw caused by OS it been operating on missing a feature.

The best pig ear is still a pigs ear Weasel. Best broken bit of software is still a broken bit of software.

[oiaohm]

Nah, usually it's not that.

More likely, this wayland-proxy thing that oiaohm is talking about is too laboring to implement. So, they are making excuses in order to avoid a hard job.

With that Wayland-proxy, you would effectively get absolute positioning, no matter how it is called.

In reality no wayland -proxy with current wayland protocol still does not end up with absolute positioning. But that does not mean you cannot do relative positioning or not get relative positioning data. Wayland wine used what the Wayland protocol offers currently.

Like it or not by the current wayland protocol design only the most direct to user Wayland compositor has absolute position. There is very big reason todo this.

Lets say you have a window rendered on screen user grabs hold of the window with mouse and moves it. Wayland model as this window is moved around and so on the application does not need to be told it moving because the application only has relative positions..

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249

drastic read merge 249 this is relative.

Wayland proxy compositor can do something like 249 using xdg_positioner, between the windows it is controlling. But this is relative you have picked A and B window and said A top left Conner is 0.0 now please place this B window at like x and Y offset relative to A. Of course you are not promised that the host Wayland compositor of a Wayland proxy exactly places the window where Wayland compositor asked it may have altered that X and Y because it was going to put window off side of screen that the notes with the positioner said not to put off side of screen yes the location of A in the A/B walk through is taken into account if B requested position is being altered by the compositor.

By the wayland design only thing that knows exactly where something is on screen in absolute terms is the Wayland compositor connected to the outputs. Direct to hardware Wayland compositor also doing the calculation to get absolute position as late as possible and is allowed to correct the position.

Relative positioning model of Wayland is different.

Big thing about a Relative position model like wayland has is that you don't use just X and Y instead you are using X Y and anchor item. Yes if the anchor item moves between the time application send window to be display and the time the window is displayed under the wayland relative system the appearance of the window to the user stay in the same relative position. Under Absolute position solutions like X11 and Windows this is a race condition were the objective was to display window relative to another window but due to the target windows absolute position moving and the application also using absolute position the result is the relative position was not maintained.

In fact absolute position system is what leads to a pop targeted to appear in the center of a window end up appearing on top of another application window where the program never intended for it to be..

Think about it absolute positioning as a program you have not provided anchor valve instead you are using a preset anchor value. This is something wine wayland is having todo heuristics for with Windows applications that this window should be anchored to this other window.

Wayland protocol design wants to be given more information than X11 or Windows asks for so incorrect placement is prevented where possible.

Yes this means automation scripts to work correctly under Wayland proxy compositor people like weasel would have to get use to doing stuff in relative term instead of absolute. Yes the provide X, Y offsets and anchor mindset(relative position) instead of the old just provide X and Y with no care about anchor because that absolute and is set outside my control mind set(absolute position).

[oiaohm]

Yes, I know.
The point is that the Wayland protocol could be upgraded such that a Wayland compositor (SUID) can recognize a Wayland proxy (SUID) and enable a "window position" extension which might or might not include an absolute positioning extension (but I don't see why not, if the user grants that permission).

I can see a reason why absolute position people from Windows and X11 will not be provided.

The virtual image based Absolute Position that people know of Windows/X11/Mac OS is not required to be used to render output. Each connected monitor output has it own individual 0.0.

Gets more interesting.

https://discuss.kde.org/t/custom-desktop-panel-placement-in-kwin-with-wayland/3064/9

https://wayland.app/protocols/wlr-layer-shell-unstable-v1

This gets you into what KDE and Sway and Wlroots are like internally. Everything is done with anchors. Each screen has 4 anchors that you window can be positioned from.

Here is the ultra fun point. Vulkan and Opengl the things GPU makers implement don't in fact use Windows or X11 style absolute positioning but instead this anchoring system/relative positioning system.

So the virtual absolute positioning Windows, X11 and Mac OS does is not information the GPU wants. Wayland compositor can have stored all the relative information the GPU wants then you attempt to ask them for absolute position that they have not calculated because they don't need it.

This part explains the big no way in hell respond merge request 247 from wlroots developer.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249

Remember Weasel said you had to have absolute position to do relative placement this is not true and has not been true since we started having GPU do 2d acceleration. Sorry GPU hardware relative placement of items to each other is how GPU work.

Fun point about layers shell you can take a single window and fully display it on many different screens as you have connected. Do note a surface using the layer shell item can be anchor almost unlimited number of times.

Welcome to world breaking. A application window can have more than valid 1 absolute position at the same time under Wayland. Yes the top left corner of window could have almost unlimited different absolute positions at the same time and this is allowed by Wayland design. Yes under layer shell extension when you can place the same window with the same sizes on every screen so giving the window multi absolute positions that are all valid at the same time.

Those coming from Windows and X11 are only use to the consent of a Window have a single absolute position based off a fixed anchor the reality Wayland is not that. Wayland using relative position information is about making application developer life way simpler than dealing with the absolute position system Wayland protocol itself supports. Dealing with mutli absolute positions for Windows what are allowed in Wayland in general application code would result in insanely complex programs this is why application instead are giving relative positioning as this can have forms of single values for applications to deal with.

Wayland Compositor can be kind of smart here a Window is fully displayed on 4 screens and application sends a popup the Wayland compositor can decide to display the popup above the window output closest to the mouse.

[oiaohm]

Let's simplify this discussion by considering only the case of initial window position.

Just at the end of this line you have a incorrect presume straight away with Wayland. The mistake is that is not window position but window positions. Yes positions being plural meaning more than one make a big difference.

I think that some capability to set initial window position should be provided, at least so that a newly launched application appears at the same position where it previously was.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

Yes this falls under Merge request 18.

Single top level window from application can be display more than once by a Wayland compositor. GPU has no problem displaying the same output buffer more than once on same or different displays.

Output position with Wayland Window does not have to be one position. Yes it possible for Wayland compositor to be displaying a single application window as the top middle and back window at the same time with all different offsets from different anchors on the same monitor.

Do note 18 has the compositor recording down the physical locations of windows that the application has told the compositor are important to be remembered to be restored back in the same location/s when application is restarted.

Wayland some old limitations are gone. Yes one of old limitation that a Window must be output to a single location is not part of Wayland.

Yes this is one of the problem I want to absolute position of X window under Wayland and the compositor can go here have 4000+ answers pick one and they are all correct. Now you want to set a the window to a absolute position ok there are 4000+ of them do you want all 4000+ stacked on top of each other.

Relocating window under wayland is not as straight forwards as it first seams. First you want to pick the output copy of the window you wish to alter the position of then what anchor you are moving to relative to.

Yes that wlr-layer-shell supports this multi copies of the same window being displayed at the same time. Yes when you have this it is odd seeing all the window title bars change to active window at the same time because they are all the same window just being displayed more than once.