21–30 of 131 posts
Projects like this really need to disclose how much ai was used. Otherwise my default assumption is it’s slop, which would be a bummer if someone carefully crafted this with some light ai assistance.
> dropping legacy baggage (multiple screens[...] Looked nice, but crossed it off as soon as I saw that, as I'm working on a project currently that uses many screens. Can't just call a thing legacy because you and the people you directly know aren't using it.
Earlier quoted context omitted.
They drop this use-case, but still use sockets for IPC, so I still have to pretend I'm doing network programming, serialize my messages over the "network" and "flush the stream" (insanity) but don't actually get any of the benefits of this model. I genuinely wonder if they stopped to think why X11 has sockets or just blindly copied it over. Or are they unaware other forms of IPC exist, that don't require you to go th…
What would you rather they use to communicate with the server? Message passing via shared memory? UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
Earlier quoted context omitted.
They drop this use-case, but still use sockets for IPC, so I still have to pretend I'm doing network programming, serialize my messages over the "network" and "flush the stream" (insanity) but don't actually get any of the benefits of this model. I genuinely wonder if they stopped to think why X11 has sockets or just blindly copied it over. Or are they unaware other forms of IPC exist, that don't require you to go th…
What would you rather they use to communicate with the server? Message passing via shared memory? UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway. And later I think this is what early revisions of Canonical's Mir did.
This is pretty cool - especially that it's at the point where it can be used with a real window manager. I'm curious why multiple screens is considered legacy baggage and thus out of scope, given how common multiple monitor setups are these days. I also have zero familiarity with X internals, so don't know if multiple monitor support is a horror show that'd be miserable to support.
I suspect(with out reading the source to find out) that screens are the traditional X11 screens as opposed to the modern xrandr combined screen. Traditionally each screen in an X11 setup was it's own separate thing with it's own separate frame buffer. While technically applications could move between screens, this depended on the application caring enough to do so. It had to maintain two(or more) mirrored windows(one…
This is pretty cool - especially that it's at the point where it can be used with a real window manager. I'm curious why multiple screens is considered legacy baggage and thus out of scope, given how common multiple monitor setups are these days. I also have zero familiarity with X internals, so don't know if multiple monitor support is a horror show that'd be miserable to support.
I suspect(with out reading the source to find out) that screens are the traditional X11 screens as opposed to the modern xrandr combined screen. Traditionally each screen in an X11 setup was it's own separate thing with it's own separate frame buffer. While technically applications could move between screens, this depended on the application caring enough to do so. It had to maintain two(or more) mirrored windows(one…
> dropping legacy baggage (multiple screens[...] Looked nice, but crossed it off as soon as I saw that, as I'm working on a project currently that uses many screens. Can't just call a thing legacy because you and the people you directly know aren't using it.
Nowadays, multiple monitors present one big virtual framebuffer and only one logical X11 screen.
Earlier quoted context omitted.
What would you rather they use to communicate with the server? Message passing via shared memory? UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
How about making the standard client library's API the interface, and have it hide whatever the system is actually using? A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway. And later I think this is what early revisions of Canonical's Mir did.