Back

@whitequark @mcc See systemd wantonly copy-pasting bits of glibc headers into their tree "because compile times"...

"If it's in /usr/include it's fair game" is apparently the attitude of at least one of the maintainers...

@becomethewaifu @mcc that's cursed. why not use precompiled headers?

@whitequark @becomethewaifu @mcc Because there's not actually a performance issue they're trying to solve. It's just ideological about not respecting interface contract boundaries. They did the header flattening for *their own* internal headers, and thereby they should also be allowed to do it for system header ones.

Because see, they're called "system" headers and that means they belong to systemd.

Obviously.

@dalias @whitequark @becomethewaifu To me if systemd were a good and useful system for whatever it is it does, then it would be nice if I could build systemd for platforms other than linux. by the way, does hardcoding glibc headers imply that building systemd with clang is not possible?

@mcc @whitequark @becomethewaifu I think you're mixing up glibc with gcc.

@dalias @whitequark @becomethewaifu yes, i do that a lot. but same question, does it imply you can't build systemd with musl libc? (it might be the case there is no good reason to do this.)

@mcc @whitequark @becomethewaifu Indeed you can't, without some patching out of lots of gratuitous glibcisms. Some of the systemd devs are helpful and cooperative with the folks who've done that work trying to get it upstream. Others block & try to reverse it.

@dalias @whitequark @becomethewaifu you know, i really want to defend systemd from the various extreme attacks on it because i don't think the init.d system it replaced was particularly good and i think some of VFS-y things it does sound useful. but systemd makes this continually hard.

@mcc @dalias @whitequark @becomethewaifu As with X11 vs Wayland, the old system was terrible but that doesn't mean the replacement isn't also awful in its own way.

@azonenberg @mcc @whitequark @becomethewaifu This is what always happens when you decide you get to replace contracts other ppl depend on rather than replacing bad implementations while maintaining contracts and offering new optional functionality on top.

@dalias @mcc @whitequark @becomethewaifu yeah personally i would much prefer a from scratch rust x server stack with rarely used legacy functionality removed or replaced by a compatibility layer.

But keeping the same feature set.

@azonenberg @dalias @mcc @becomethewaifu i would absolutely not want to maintain either the awful x11 stack, or the awful init.d stack. the contracts fucking suck. they should be replaced. it's just that they should be replaced by someone who cares more

@whitequark @dalias @mcc @becomethewaifu Fair.

But yes. Providing at least the features people rely on is kinda important.

@azonenberg @dalias @mcc @becomethewaifu tbf this is much less of a problem with wayland because at least you are free, as a DE vendor (KDE for example) to work around all the egregious missing parts

yes, it still sucks for everyone involved, but at least you don't have to do things like "try to patch or emulate a moving target" that nobody seems to be able to do over long timescales

@whitequark @dalias @mcc @becomethewaifu yeah the problem instead comes from app developer perspective where you have to special case all kinds of features that nay or may not be available on a given compositor that might be critical to your system functionality

@azonenberg @dalias @mcc @becomethewaifu as if x11 doesn't already have that problem

@whitequark @dalias @mcc @becomethewaifu i don't think I've ever written code that depended on specific x drivers or window manager features.

But with wayland it seems like a lot of core things like xdg-toplevel-drag are optional features that a compositor can just decide to not support

@azonenberg @dalias @mcc @becomethewaifu an x11 window manager can decide to not support things like "min/max window size", "fullscreen windows", and so on

in fact, my current window manager i3 does that! it does a bunch of stuff that applications which expect gnome or kde don't expect. it causes exactly the type of random breakage you'd expect

@whitequark @azonenberg @mcc @becomethewaifu But it's stuff some users use, want, and expect to keep working!

@dalias @azonenberg @mcc @becomethewaifu sure. my point is that nobody is in the wrong here: these features never made it into x11 proper (and don't get me started on ewmh), so i3 isn't wrong, but equally the applications can reasonably want to use some standard desktop features, so they aren't wrong either

@whitequark @dalias @mcc @becomethewaifu defining a standard set of features that a desktop oriented vs say vr oriented compositor is expected to support, and having many applications only support one of these profiles might be a good start.

(And having the desktop profile include support for things like absolute window layout)

@azonenberg @dalias @mcc @becomethewaifu i do have sympathy for not having absolute window coordinates in the core protocol because the concept of "window coordinates" isn't well-defined in the first place in presence of multiple monitors with possibly different DPI, and the main use case for getting them (saving window positioning) is _much_ better served in the compositor itself

@whitequark @dalias @mcc @becomethewaifu the correct solution imo is floating point coordinates in post dpi scaled space that are mapped to pixels by the compositor. The app only cares about visible rectangles on an infinite abstract plane

@azonenberg @dalias @mcc @becomethewaifu i don't see why ngscopeclient would care about absolute window positioning anyway

@whitequark @dalias @mcc @becomethewaifu the main problem is that it means imgui can't implement docking and dragging of or between windows without adding a lot of wayland specific code for xdg-toplevel-drag and adding fallback ux for compositors that don't support it.

Rather than simply assuming the entire display is a rectangle of pixels like every other platform (macos, windows, x11) where you can get global mouse and window coordinates and determine if a window has been dragged into another etc in a platform independent algorithm you write once.

@azonenberg @dalias @mcc @becomethewaifu ok tbh this seems fine to me