Microsoft Makes Open-Source Windows Forms, WinUI, WPF

[ssokolow]

One of the key objectives of wayland is to be able to render perfectly every single time. Having pop ups appear in the wrong places does not meet that requirement.

Daniel Stone actually phrased that as "Every Frame is Perfect" in his 2013 linux.conf.au talk, which prompted a Monty Python reference from an audience member.

[Weasel]

No this is because you are a idiot not all changes with wayland are because of security.

Wayland developer got rid of the root window idea and attempt to force usage of relative addressing purely because of the following.
1) due to X11 issues relative addressing between your own windows works on X11 where using the global relative addressing can be unpredictable so majority of X11 programs are coded to use relative addressing this is why GTK setting returned address value to 0,0 under wayland effects less than 10 percent of GTK applications. Basically no need to duplicate something that is already broken.
2) it fixes a graphical problem.

It doesn't fix anything since YOU said you can workaround it with an invisible root window.

You are using global relative addressing(x11 root window) the following problem happens.

Your program is attempting to draw a pop up window while user is moving window and is using the global relative addressing. The pop up fails to appear above the window and fails to stay in the right location as window moves.

That's exactly how a popup is supposed to behave, not automatically track a window.

Must be autistic developer to want to change an established thing.

Weasel you have not read what the key objectives of Wayland were or you might have worked out that there was another reason why particular features are not gone but now just hard to use. Global relative address to current screen under wayland has just been made harder to use because you should be avoiding using this due to the graphical problems it can cause.

Those aren't problems. Those are intended behavior.

Programming basic concepts against Wayland is like pissing against the wind.

[oiaohm]

It doesn't fix anything since YOU said you can workaround it with an invisible root window.

GTK, Qt your major toolkits don't work around it because majority of cases you don't need the positioning information other than relative to own window.

That's exactly how a popup is supposed to behave, not automatically track a window.

That is not in fact the case. motif including auto window tracking popups for menus.

Those aren't problems. Those are intended behavior.

History of X11 its not intended behaviour at all. Its broken behaviour due to broken protocol.

Programming basic concepts against Wayland is like pissing against the wind.

Who programming basic concepts. Windows ones right. Wayland is build from X11 toolkit basic concepts include how a pop up should behave. When you are rewriting a protocol you might as well modify so toolkits are not working around limitations over and over again wasting tones of cpu time in the server and client.

Global relative address is a limit usage case with X11 applications. Majority are running on relative addressing to own windows. So when wayland was designed that is the way it designed.

[Weasel]

GTK, Qt your major toolkits don't work around it because majority of cases you don't need the positioning information other than relative to own window.

That's the lamest argument I've ever heard because they could (or already do?) the same thing on X11 (i.e. not allowing to access root window unless you go out of your way to do it). Frankly nobody gives a shit about the toolkits, it's probably why Wayland is so piss poor since it assumes apps use those garbage.

That is not in fact the case.

Nobody cares about the opinion of Wayland morons.

History of X11 its not intended behaviour at all. Its broken behaviour due to broken protocol.

...what? I'm talking about the fact you can use root-window-relative coordinates, which are absolute coordinates, in other words.

Who programming basic concepts. Windows ones right. Wayland is build from X11 toolkit basic concepts include how a pop up should behave. When you are rewriting a protocol you might as well modify so toolkits are not working around limitations over and over again wasting tones of cpu time in the server and client.

Global relative address is a limit usage case with X11 applications. Majority are running on relative addressing to own windows. So when wayland was designed that is the way it designed.

Yes, Windows is sane. Its "root window" is the "screen" which obviously makes total sense.

Child windows have relative coordinates. That's normal, and applies not just to Windows, but also X11. A top level window is the CHILD OF THE SCREEN or "root window". Hence its coordinates are ABSOLUTE (or relative to the screen/root window, which is the exact same thing). This is called simple logic.

[oiaohm]

That's the lamest argument I've ever heard because they could (or already do?) the same thing on X11 (i.e. not allowing to access root window unless you go out of your way to do it). Frankly nobody gives a shit about the toolkits, it's probably why Wayland is so piss poor since it assumes apps use those garbage..

90 percent of the applications under Linux are using toolkits. Also the application not using toolkits if you track there X11 usage majority of those don't use root window position information.

Yes, Windows is sane. Its "root window" is the "screen" which obviously makes total sense.

This is what a ghost window with Wayland can in fact give you if you go after a full screen hidden form.

Child windows have relative coordinates. That's normal, and applies not just to Windows, but also X11.

This is not right for X11. Tiling and scaling windows managers ruin that as well. Window might have relative coordinates under X11 or you might have that scaling windows manager has decide that 2x equals 1x and 1Y equals 10Y. This is legal to be done to you under X11 giving you totally messed up relative coordinates.

This surprises by different X11 windows managers is why wine requires its own virtual desktop that is renders and places everything inside it. Yes so wine can work no matter the WM the user decide to use..

A top level window is the CHILD OF THE SCREEN or "root window". Hence its coordinates are ABSOLUTE (or relative to the screen/root window, which is the exact same thing). This is called simple logic.

Go read the X11 protocol. Root window is not child of screen under X11. Its the child of the X11 root window.

https://www.x.org/archive/X11R7.0/doc/html/DESIGN2.html

Read down here note the word Absolute next screen. You are not required under X11 to have you screen positioned at 0.0. Screens under X11 are positioned in the X11 root window where ever the configuration told them to be. With DPI differences between screens this turns into a migraine and a half to display right. Yes it legal to overlap screens as in X11 like half down the middle.

Its in fact possible and legal on X11 server to position you screen with a negative address. Wayland you get full screen top displayed corner on screen will be 0.0.

Weasel stop presuming X11 has the same rules as windows. X11 rules are way into insanity.

Root Window is not a child of screen under X11. Screen is a Child of the X11 Server Root Window under X11. Root window under X11 is created before any screen is registered.

Wayland all surfaces/window are in fact a child of a screen/output and you get informed if your window has been moved between them.

Wayland a ghost window is in fact a child of a display/screen. So doing a wayland ghost window method in fact gets you closer to windows way of doing things. You get rid of the X11 protocol surprises.

[oiaohm]

https://www.bountysource.com/issues/...out-x-on-linux
"It is very unlikely that Wine is going to support Wayland in the same way as X. I worked on a Wayland driver for Wine some time ago, but discontinued the idea because Wayland lacks many features that are expected by Windows programs.
"

Lets skip the most important context part of that sentence. Some time ago in fact means many years. Before xdg_shell was officially part of wayland protocol. Without xdg_shell you cannot create a effective ghost window.

One problem is for example that a program can not specify the location of a newly created window. This doesn't sound very problematic at first, until you notice that drop-down / popup menus are also just normal windows on Windows. The solution that Wayland provides for this is not really compatible with the Win32 API. I therefore talked with some Wayland developers and there is no chance of fixing this in the future. It is part of their concept that applications should not have control over the window position and similar settings.

This ceases to be true once you get wayland with xdg_shell. Once you have xdg_shell you can create a ghost window is truly the full size of the display area to specify location from that. So his no chance of fixing this in future turns out to be as true as you Nvidia quote for end users that I disprove latter.

Also you don't want the wayland backend for wine done exactly like the X11 one.

https://wayland.freedesktop.org/docs/html/apa.html

Search the apa for scale. Notice wayland allows you to specify that the output will be scaled. Wayland version could gain the means to scale old application graphics up for newer HDPI screens and beyond.

Here is the fatal problem with both Weasel and debianxfce is Michael Müller the current Wine Wayland developer?

https://wiki.winehq.org/WineConf2017#Wayland_demo

The answer is no he is not Alexandre Julliard is the current Wayland developer who is also working on the Android port. Alexandre picks up the Wayland work after Michael gave up on it. Michael Müller had quit on wayland support well before jan 2017. Alexandre is working on wayland support in Wine November 2017.

" We currently have no plans to support Xwayland.
Aaron Plattner
NVIDIA Linux Graphics
"

That 2017 quote deceptive.
https://www.phoronix.com/scan.php?pa...L-NVIDIA-Patch
Current XWayland does support Nvidia drivers. Did it require any work from Nvidia no it did not. Just required someone to make Xwayland a little smarter.

[Weasel]

This is not right for X11. Tiling and scaling windows managers ruin that as well. Window might have relative coordinates under X11 or you might have that scaling windows manager has decide that 2x equals 1x and 1Y equals 10Y. This is legal to be done to you under X11 giving you totally messed up relative coordinates.

I'm not sure what your problem is. That's perfectly fine since a WM (and the user) should decide if he wants it stretched. This is why X11 is sane.

When I mean absolute positions I mean by comparing yourself to other windows on the screen or root window. Basically you need to be able to compare your app's window with another app's window in absolute terms (relative to the root window).

Go read the X11 protocol. Root window is not child of screen under X11. Its the child of the X11 root window.

What? You basically just said "Root window is the child of the X11 root window". And water is wet. Thanks for the info.

I don't care if the root window is the screen or not (that's a Windows thing). Obviously X11 is not tied to a screen, and it doesn't matter. The point is that you can't go outside of the root window -- but you can query positions absolutely within that root window. It's like a Virtual Machine. A VM can query absolute positions within itself. That's sane.

https://www.x.org/archive/X11R7.0/doc/html/DESIGN2.html
Read down here note the word Absolute next screen. You are not required under X11 to have you screen positioned at 0.0. Screens under X11 are positioned in the X11 root window where ever the configuration told them to be. With DPI differences between screens this turns into a migraine and a half to display right. Yes it legal to overlap screens as in X11 like half down the middle.

Its in fact possible and legal on X11 server to position you screen with a negative address. Wayland you get full screen top displayed corner on screen will be 0.0.

Weasel stop presuming X11 has the same rules as windows. X11 rules are way into insanity.

Huh? That's perfectly normal and logical. You can have negative coordinates in Windows as well, sounds to me like yet another failure of Wayland implementation trying to be the retarded kid in the block.

You don't have to imagine complex situations for where this is perfectly logical, just think of multi-screen displays. The main screen has 0.0 and the screen to the left is obviously negative territory. Perfectly sane, logical, and elegant.

A "screen" is a virtual term. It's not necessarily the display screen itself. In X11 it's the root window. In Windows it's a virtual screen encompassing all the monitors, or even less if it's a VM, etc.

[oiaohm]

I'm not sure what your problem is. That's perfectly fine since a WM (and the user) should decide if he wants it stretched. This is why X11 is sane..

With X11 you get get stretched values back one time and if the WM has stretched or stopped being stretched you get no notification of the change and your X/Y are now completely wrong. Yes it one thing for the WM decide he wants it stretched/non stretched but no requirement to tell client in protocol about state change or hide it perfectly from client not good.

When I mean absolute positions I mean by comparing yourself to other windows on the screen or root window. Basically you need to be able to compare your app's window with another app's window in absolute terms (relative to the root window).

Wayland compositors are stack-able.

What? You basically just said "Root window is the child of the X11 root window". And water is wet. Thanks for the info..

I was meaning screen is a child of the X11 root window inside X11 is around the other way. This creates a interesting nasty legal event under X11 where it legal for half a screen output to be on another screen at the same time now what vsync should the application get is the monitor A or monitor B vsync or both.

This explains why wayland strictly tells you output. Including telling you that a surface is on 2 different outputs at times and this includes giving you the two different vsyncs if required.

I don't care if the root window is the screen or not (that's a Windows thing). Obviously X11 is not tied to a screen, and it doesn't matter. The point is that you can't go outside of the root window -- but you can query positions absolutely within that root window. It's like a Virtual Machine. A VM can query absolute positions within itself. That's sane.

No X11 when you add a screen to the root window you place something outside the root window and the root window magically has to be big enough.

Wine has to be like a VM. X11/Wayland input has to be translated to windows style input so windows programs behave correctly.

You can have wayland subsurfaces on a ghost window you can have like wineserver tracking all the locations of those surfaces and the wineserver responsible for creating all the subsurface wine application use. Just like the existing wine virtual desktop window movement performed by wine it self so taking window placement out of the control of the compositor and putting it in wineserver control.

Yes the wine X11 virtual desktop creates a single allocated texture and renders everything itself and moves everything itself. But unlike the Wine virtual desktop under X11 the one on wayland can use the fact wayland allows sub surfaces to be normal drawing ordering stack. So the back of the virtual desktop can be 100 percent transparent to input and appearance on wayland. Back of the virtual desktop on X11 cannot be transparent.

Yes the wayland subsurface system means wayland version of a wine virtual desktop does not have to be one single surface.

Wayland does not make it impossible to query absolute positions from application point of view. Just makes you jump though hoops to have it.

Huh? That's perfectly normal and logical. You can have negative coordinates in Windows as well, sounds to me like yet another failure of Wayland implementation trying to be the retarded kid in the block.

You don't have to imagine complex situations for where this is perfectly logical, just think of multi-screen displays. The main screen has 0.0 and the screen to the left is obviously negative territory. Perfectly sane, logical, and elegant.

That ceases to be logical when you have screens of different dpi. So half the window is double the correct size because its on a low DPI screen?

It in fact comes important to build output to screen it being displayed on so you get the correct drawing results.

You in fact want your output surface on a monitor to have nothing around it. So that X surface a X dpi placed half off the side of the screen 1 is correct and X surface at Y dpi with the other half on screen 2 is also right.

Gluing everything into 1 large thing makes sense when everything was around the same DPI. But does not make any sense any more, Gluing everything into 1 large thing makes it really easy to lose what is output on X mentor and what is output on Y monitor.

So what you called elegant fails to function correctly on multi screens of different DPI or results in horrible work around. Windows has some quite complex work around to attempt to keep screens of multi dpi looking right.

Wayland protocol fixes a stack of problems. It creates one you have to work around.

[oiaohm]

The wayland project is not smart at all. They are inventing the wheel again with poorer results and using wrappers like Xwayland is stupid when you have the original X working fine. The gnome3 project can not have even the gnome tweak tool as default. Using ubuntu 18.05 live with a 4K screen was a horrible experience, no built in tools to use with hdpi screens. You have hdpi themes and a font size edit box in Xfce Settings.

The original X is not working fine this was covered in the 2013 video where they had in fact tried to find one thing that X11 server and protocol was doing right There is not a single thing X11 protocol is in fact doing 100 percent right. Lot of things correct 90 percent of time but wrong 10 percent of time.

That is why Wayland was started. Wayland has started off with a very bare bone protocol intentionally hopefully to lay down a clean framework.

Some of the problems with X11 come from conflicting protocol defines. The worst rule is the fact the server and wm by X11 protocol is free to change, create, delete anything at any time without telling the application about it. This was important for a network protocol when connection could be lost. So WM moves you window from 0, 0 to 1000,0 and tells you it still at 0,0 and your place a pop up in the wrong place that is legal under X11 protocol.

Wayland protocol might be bar bones but its not a lieing pain that X11 protocol allows. X11 protocol need to be rewritten from the ground up without conflicts and without worst allowances. If the server tells your application something it better remain true.

Try doing absolute position and be true and have the window moving. You will soon work out you want absolute position that is always true to your application. Your application should be moving it windows itself.

Wayland stuff missing starts making sense once you start working out how would you avoid information race conditions. Some things should be processed application side that were processed server/wm side.

[Weasel]

With X11 you get get stretched values back one time and if the WM has stretched or stopped being stretched you get no notification of the change and your X/Y are now completely wrong. Yes it one thing for the WM decide he wants it stretched/non stretched but no requirement to tell client in protocol about state change or hide it perfectly from client not good.

...lol

WM can do anything it wants. It can erase all your files if it wants to. That doesn't mean the protocol is at fault, it means you should stop using malware or crap you don't want to. It's a software implementation thing, not protocol. I mean, the Linux kernel can do anything it wants too, including delete your entire filesystem if it wants when you call an innocent-looking module, even if it respects the interface and protocol.

Wayland compositors are stack-able.

?!??? Are you suggesting to use one compositor per application? Wow. Talk about retarded.

Wayland does not make it impossible to query absolute positions from application point of view. Just makes you jump though hoops to have it.

This isn't going anywhere. Show some code (not necessarily yours) that shows how to do it.

Note that by querying absolute positions I don't mean position just of YOUR app, but of another app as well. Imagine one app docking onto another.