Earlier quoted context omitted.
The API compatibility is not being thrown away. Xwayland will be with us for a long time for backwards compatibility (that includes stuff that lots of users care about, e.g. most Steam games). X11 will continue to be around, reduced to a more manageable size as a compatibility layer, within Wayland.
Xwayland only provides backwards compatibility for a very small subset of the X11 ecosystem (E.g. window managers or xdotool are not supported). As such it is only useful for very limited X11 clients on the level of GNOME applications and in most cases completely useless.
Gnome developer proposes removing the X11 session
81–90 of 122 posts
Re: Gnome developer proposes removing the X11 session
#82Earlier quoted context omitted.
> If for some reason you want to run an untrusted application, use a container. But building your whole house around the "untrusted" premise sounds ridiculous. I guess we should do away with memory protection as well. Filesystem permissions? Bah, they can go too, after all, a computer is generally used by a single person right? The reality is that many users use untrusted applications that don't have access to home,…
> The reality is that many users use untrusted applications that don't have access to home, ergo Flatpak. I'd like to see this quantified. How many people using flatpack are afraid of their application reading their files, vs using flatpack simply because it's a convenient way to install programs? I don't mean "oh me me!" responses, are there any user surveys to support the premise that average users are afraid of th…
Re: Gnome developer proposes removing the X11 session
#83Earlier quoted context omitted.
> without any affiliation to the Python Foundation Sorry, no dice. The Python team said for years as the 2 to 3 rollout grew increasingly catastrophic "If you wan't to keep Python 2 all you have to do is maintain it" and then threatened to sue the guy who called their bluff. It was a real low point in free software.
This guy wasn't maintaining Python, he as creating a new version incompatible with either Python 2.7 or Python 3. Red Hat and other large companies have maintained Python for years after 2.7 died (EOL date was January 1st, 2020). IBM/Red Hat offer Python 2.7 including security fixes and bug fixes until 2024 ( https://access.redhat.com/solutions/4455511 ). Had he just provided patches to Python 2.7, nobody would've ba…
> Python 2.8 is a backwards-compatible Python interpreter that runs Python 2 code and C-extensions exactly as-is, while also allowing Python 2 programmers to use the most exciting new language features from Python 3.
Really sounds like Python 2.8 to me!
Re: Gnome developer proposes removing the X11 session
#84Earlier quoted context omitted.
xrandr is perfectly sufficient for this, although GTK for whatever reason chooses to break it (not just not implement it; proactively break it). Xcb picks it up just fine, as does Qt. I'm pretty sure Fltk does now too though I haven't tried it in a while.
No, xrandr isn't sufficient. It still doesn't have scaling information, only size information. Changing the reported physical size of the monitor is a bad idea as it can break other things.
Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
Re: Gnome developer proposes removing the X11 session
#85Earlier quoted context omitted.
Monty Python didn't register Python as a name for computer software was far as I know. Nobody was going to confuse the two. Releasing Python 2.8 would definitely confuse people.
What would be the confusion? It’s a continuation of a language interpreter compatible with the dialect known as Python2. Renaming it is more confusing!
Re: Gnome developer proposes removing the X11 session
#86Earlier quoted context omitted.
The best article I have found about mixed dpi on x11 is. http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
That article is horrible. What it describes is yet another hack where clients attempt to guess the DPI and then rescale themselves, and the server and compositor know nothing about DPI. That method only exacerbates the problems where clients that don't support scaling are going to be scaled wrong on every screen. Compare this to Wayland where the compositor itself knows the scale of every window and does all the scal…
The article reaches the conclusion that the best way to handle the situation is for the display server to provide the dpi primitives and let the client figure out how best to draw to that dpi. But acknowledges that there is a hack where you can make the server present a standard scaled dpi, but the drawing will then be bad. And there is this new-fangled thing called wayland where all it can do is the hack.
The irony is that wayland is infamous for usually making the clients do the work(I am thinking window managers) and X for providing a standard method. Nether of which is true, but it made me chuckle.
Re: Gnome developer proposes removing the X11 session
#87Earlier quoted context omitted.
No, xrandr isn't sufficient. It still doesn't have scaling information, only size information. Changing the reported physical size of the monitor is a bad idea as it can break other things.
OFFS this is the most ridiculous reaction ever. Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.
Re: Gnome developer proposes removing the X11 session
#88Earlier quoted context omitted.
> The reality is that many users use untrusted applications that don't have access to home, ergo Flatpak. I'd like to see this quantified. How many people using flatpack are afraid of their application reading their files, vs using flatpack simply because it's a convenient way to install programs? I don't mean "oh me me!" responses, are there any user surveys to support the premise that average users are afraid of th…
This is incorrect, apps installed through the macOS App Store have required sandboxing since 2012. Since 2018, Microsoft is also attempting to get developers to sandbox more apps, see more about that here: https://news.ycombinator.com/item?id=36059982
https://developer.apple.com/documentation/xcode/configuring-...
Show me where it says a program installed from the MacOS appstore will be unable to read the user's files unless the user explicitly authorizes it. Here's how it actually works as far as I can determine: The application developer grants their app the entitlements to read user files. The user may see that entitlement before installing the application, but thinks nothing of it because of course the program operates on their files. This does not protect the user against a malicious program being shipped with those entitlements and a plausible pretext to justify it. Example: The user downloads a program to read some kind of unusual file for work, the program grants itself access to ~/Downloads because of course it needs that, then the program instead reads ~/Downloads/your-tax-documents
This system only protects the user if the application was legitimate, refrained from granting itself the relevant entitlements, then got compromised by an attacker.
Re: Gnome developer proposes removing the X11 session
#89Earlier quoted context omitted.
OFFS this is the most ridiculous reaction ever. Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
No. Even the X.org developers disagree with you here. Messing with the DPI will cause lots of clients to break even further. See this merge request for more info on this: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests... X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that be…
Re: Gnome developer proposes removing the X11 session
#90Earlier quoted context omitted.
What would be the confusion? It’s a continuation of a language interpreter compatible with the dialect known as Python2. Renaming it is more confusing!
"Python 2.8" implies it's the One True Continuation of Python 2.7, as opposed to someone's random fork.
He literally took over an abandoned codebase, and got sued for calling it the codebase's name.