XLibre is trying to advance the existing implementation which Xorg abandoned, whereas Phoenix is writing a new, compatible server from scratch.
This is true, although entertainingly, the "server" part has always been easily confused.
In X11, the "server" runs on your local machine, and the "client" frequently runs on a remote system.
[1] https://www.donhopkins.com/home/catalog/unix-haters/x-window...
The server is usually a remote machine, especially back in the time when "client-server" architecture was emerging in mainstream (business) vernacular.
This has been true for decades.
Nevertheless, it has confused very smart and highly technical people. I have had the entertainment of explaining it dozens of times, though rarely recently.
However, still, a server is usually a remote machine in all common vernacular. When "the server's down", it is usually not your local machine. You're logicalling yourself out of humane language.
This is because of its mainframe style history and technically it does make sense, it's just that everybody else does things the other way around.
For the people who weren't around in the ancient mainframe times who end up messing with Linux for the first time, this is confusing for a while.
This project would satisfy people who really actually want Wayland, but were upset by transitional pains or interactions they had around it and want to stick with X11 just-cause while getting some similar benefits. This arguably does describe some people but not sure it's a whole lot in the long run.
But who knows, maybe this could also make an easier to maintain XWayland some day, or a nice basis for implementing more esoteric X11 bits down the road vs. the older Xorg codebase.
Not for the client, or if you want to write a wm and is forced to write a compositor.
And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.
>Applications will be isolated from each other by default and can only interact with other applications either through a GUI prompt asking for permission, such as with screen recorders, where it will only be allowed to record the window specified or by explicitly giving the application permission before launched (such as a window manager or external compositor).
An X11 rewrite with some security baked in is an awesome approach. Will be watching!
I’m all for an X12.
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
Also happy winter solstice.
If you took people who absolutely never tried any computing, and gave them macos, windows, and for example Plasma, they would NOT consider windows or macos to be ready for the desktop. If you go 15 years back, even way more so.
even in the early 2000s, windows was so hilariously crappy that you had to make floppy disks to even get to install the thing. If PCs didnt come preloaded with windows, regular users would never ever be able to install it, versus the relative ease a typical linux distribution was to install. This is also one of the large reasons that when their windows slowed down due to being a piece of shit with 1000000 toolbars, people threw it out and bought a new, despite the fact that a reinstall would have solved it.
Well they certainly manage them better than x11 and wayland. What a fucking nuts thing to say. Are you rms?
In X11 "screen" has a particular meaning, and only supporting a single screen doesn't preclude multi-monitor support or virtual desktops.
https://github.com/marler8997/zigx
https://www.youtube.com/watch?v=aPWFLkHRIAQ
Compared to libX11, it avoids dynamic dependencies, uses less memory, and provides better error messages.
As a user you can pass `--release` to `zig build` to request release mode. If the application doesn't want to pick for you, you'll get an error and then you can pick for yourself.
In this case, it looks like the author of Phoenix wants to choose ReleaseSafe as the official release mode of the application.
Phoenix is the name of my hometown, btw.
superb_dev•1h ago
This is interesting to me, why would vsync being enabled mean that the desktop compositor needs to stick around for a full screen app?
amiga-workbench•1h ago
superb_dev•46m ago