NetBSD On The State & Future Of X.Org/X11

[Weasel]

I always wondered about that. Please tell more about what you want and you need.

I already told you several times but not like you read and just reply with cringe kid remarks.

[oiaohm]

I already told you several times but not like you read and just reply with cringe kid remarks.

No you have not. In have you have been writing what you want. There is a difference. 264 please do read and think carefully.

You have not been considering use able space when placing windows.

This is very common for people to get use to doing something X way that is to get Y need result and then wanting X. But X is no Y.

My needs for automation.
1) I need to be able to place windows inside usable space. 264 will get me this.
2) I need to be able to send multi mouse clicks/inputs into applications without any other inputs getting mixed in the middle. AT-SPI2 get me 90$ there. Limitation is that you cannot use AT-SPI2 with applications that don't have toolkit support because we don't have good support of AT-SPI2 in compositors for this case..

Really being able to place windows outside usable space then having the Windows manager/compositor having to tell window place resize/move before you will get displayed really is a waste of CPU time.

[Weasel]

No you have not. In have you have been writing what you want. There is a difference. 264 please do read and think carefully.

You have not been considering use able space when placing windows.

This is very common for people to get use to doing something X way that is to get Y need result and then wanting X. But X is no Y.

I literally don't care about useable space, I shouldn't have used that example since you're blowing it out of proportion. My taskbar is at the bottom and I don't even place anything near the bottom with the script.

And stop with 264. That's not merged.

I need screen-relative positioning or alignment, such as left, right, center, etc. Or simply absolute window positioning so I can do the simple math myself.

[oiaohm]

I need screen-relative positioning or alignment, such as left, right, center, etc. Or simply absolute window positioning so I can do the simple math myself.

Lets take this line apart.

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

App developers would be unhappy as it limits their application's design to what paradigms the compositor supports with regards to window placement (e.g. "top", "left" anchor semantics - what if the app wanted to place two windows centered at the top?)

As I wrote you need to read 264.

alignment, such as left, right, center, etc.

Bit of your line documented in 264 does not work with the bold above with the start of the problems.

So cut out the bit that does not work that leaves the following line.

I need screen-relative positioning Or simply absolute window positioning so I can do the simple math myself.

Simple math 1 +1 that equals 10 right. Yes just because the math is simple does not mean you will not get the wrong. Area-limited window positioning of 264 means you get your positioning math wrong you don't end up fighting with the window manager/compositor this fight between script and windows manager/compositor can in worse case lock your interface up and has done so historically.

This disregarding following for 264.

Clients have a better idea about the usable space available to them and might make much better placement decisions than on X11

Usable space and used space is important

My taskbar is at the bottom and I don't even place anything near the bottom with the script.

So you are 100 percent sure you will never have to use a low Resolution monitor. This is again you not thinking about what your future self could have to deal with.

And stop with 264. That's not merged.

264 is not merged but the 264 author as collated problem. Issue here is once the information is collated lot of what people are asking for is not their need but a want and want is defective. The want has downsides/defects that they are not seeing.

[Weasel]

Simple math 1 +1 that equals 10 right.

It does, in binary.

Anyway 264 isn't merged and I cba to see if it would work or not. As long as it's not available it's pointless.

[oiaohm]

Anyway 264 isn't merged and I cba to see if it would work or not. As long as it's not available it's pointless.

Like or not 264 has collected information that what you have been asking for is flawed.

The reality is lot of these slow develop areas of Wayland protocol are areas that we have not really thought about in detail to work out how it should be.

Weasel you still have not written what you clearly need you are still writing wants.

Collection of data on what the limitations really is happens not to be pointless.

The line you wrote as need I pulled apart so try again Weasel. Once you do get to writing what is need you find that the answer is not what you have been asking for. Then wake up everyone been doing the same thing. Asking for wants that happen to not work once you do more detail investigation.

Wayland process has all new protocol additions having a complete peer review. This also says when you get your need it going to be different to what you are use to because the method you have been using Weasel happens to be broken and you have been ignoring the flaws.

[ol3geezer]

I literally don't care about useable space, I shouldn't have used that example since you're blowing it out of proportion. My taskbar is at the bottom and I don't even place anything near the bottom with the script.

And stop with 264. That's not merged.

I need screen-relative positioning or alignment, such as left, right, center, etc. Or simply absolute window positioning so I can do the simple math myself.

why? just curious. the more info the better

[moonwalker]

But what makes you think that I disagree that having a good design is paramount? In fact, I think a good design with as much support and dev time as Wayland - which was designed while X11 was within one's '20/20 hindsight'... Should have much better outcomes as compared with X11 by now! How is that not the case? Again, no evidence that security holes in X11 cannot be closed with X11 or other software.

And it does, for the stated design goals. Unfortunately, it does mean certain features are no longer as easy to implement as with X11, e.g. keylogging, screengrabbing, clipboard snooping, reading arbitrary window contents... Sorry, I meant fortunately.

But yes, it does mean things like screencasting were virtually impossible until xdg-desktop-portal and PipeWire. And Nvidia was a pain in the rear with their insistence on doing things differently, which also didn't help with Wayland's adoption. A lot of pieces had to fall in place before Wayland became usable outside of enthusiast population, and some things are still wonky (like lack of windows shading in KWin that I want, or some apps not using portals and hence unable to request screen casting or whatnot). But I would argue that in terms of usability Wayland right now (depending on a DE/distro) is somewhere around where X11 used to be during transition from XFree86 to X.org. And considering it took X11 more than 18 years to get from protocol definition to a nicely usable X.org that doesn't feel like ugly hack compared to, say, Windows, I'd say Wayland is actually doing pretty well, being just a tad over 15 years old. Ugh, I still remember having to manually edit XF86Config just to get external monitor to show anything at all...

[oiaohm]

Nvidia was a pain in the rear with their insistence on doing things differently,

There is a difference between doing something differently and what Nvidia did. Yes Nvidia was pushing for something different that not even Nvidia developers themselves could in fact make a correctly working example. Nvidia had insistence that everyone should just use a broken design.

Yes there was a little too much faith that Nvidia was not pushing a totally failed design so wayland protocol extensions that could be been merged just for GBM/DMABUF/open source GPU drivers was not allow to be merged until Nvidia agreed to support GBM/DMABUF. Yes items like explicit sync wayland would have had way sooner without Nvidia pushing totally broken idea.

Nvidia was insisting for over a decade to stick to a broken design. Reason for the broken design is if the graphics drivers could be user-space Nvidia would not have to address the Linux Kernel GPL license issue for kernel modules. Integration with the Linux kernel scheduler means dealing with code that IBM and Microsoft so on hold patents and only license this code to be used with GPL items and have the funds to spend decades in court disputing.

Reality Nvidia/ATI vs Microsoft with Windows Vista is the basically the same thing that just happened with Wayland and Nvidia. Yes I do mean the same big change with Vista graphics drivers is that memory allocations had to be kernel tracked so GPU vendors could not keep on using their own unique coded memory management systems for GPU memory. Yes Nvidia and ATI was also asking Microsoft to keep the userspace driver bits alive that they removed from direct x with Vista.

Yes Vista round 2 was Wayland vs Nvidia.