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

@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@mastodon.social @azonenberg@ioc.exchange @dalias@hachyderm.io @mcc@mastodon.social @becomethewaifu@tech.lgbt mfw my window system won't fix anything

@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

@dalias @azonenberg @mcc @becomethewaifu if you think x11 doesn't need replacing try making a window fullscreen. i dare you

@whitequark @dalias @mcc @becomethewaifu try launching a file browser from a fullscreen window if you want hell

@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 @azonenberg @dalias @becomethewaifu in certain types of VR, window coordinates may be non-cartesian

@mcc @whitequark @dalias @becomethewaifu which is why i said this should be a standard extension for the desktop profile where it's reasonable to assume one or more 2d rectangular displays

@mcc @whitequark @dalias @becomethewaifu and apps that care about absolute window coordinates are free to disable some features or not work at all in vr

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

@azonenberg @dalias @mcc @becomethewaifu like, right now on my x11 session ngscopeclient cannot, by design, position windows wherever it wants. what breaks?

@whitequark @azonenberg @dalias @mcc @becomethewaifu dear imgui's docking breaks.

@azonenberg @dalias @mcc @becomethewaifu that (except) is actually pretty important, plenty of applications break if your monitor configuration changes. as an end user this sucks and making you go through slightly more work to avoid that is probably justified

@whitequark @dalias @mcc @becomethewaifu yeah but in general if I can't restore saved windows it's a very minor impact compared to dragging between top level windows or tearing off a dock becoming impossible.

It basically means you cannot effectively use ngscopeclient on a multi monitor wayland system with different sets of windows on each monitor etc

@azonenberg @dalias @mcc @becomethewaifu yeah so this problem will go away for gnome/kde users when someone implements xdg-toplevel-drag protocol for imgui, at which point you're at the exact same place as with x11, where sway doesn't support it just like i3 doesn't support it

this is an annoyance for you, sure, but neither an architecture nor a governance problem

@whitequark @azonenberg @dalias @mcc @becomethewaifu

I was at Sun (but not in the Windows group) during the first Windows wars, NeWS was Sun's attempt to 'start from scratch'. When Canonical jumped on the Wayland bandwagon I had hoped we could see a better outcome but too many of its developers looked up to the Win32 API. A small minority of programmers today understand *why* X11 is the way it is. I believe that contributes to them breaking things when they try to reinvent it.

@ChuckMcManis Yeah, I definitely see "oh, you fools…" decisions of the type you describe in Wayland, but it seems too late to usefully address those foundational issues :(

I am hoping the pit fight around the Wayland extensions ("protocols?") ends with good results.

@mcc Agreed on the lateness. I sometimes have these philosophical debates about whether truly foundational software infrastructure can be developed without architecture. I started an essay once "There are no Cathedrals to visit at the Bazaar." (because I like puns). But the observation is that the more foundational something is, the more it benefits from a focused gaze.

@ChuckMcManis @mcc

I think I wrote that essay for you

https://queue.acm.org/detail.cfm?id=2349257

@erincandescent @dalias @mcc @whitequark @becomethewaifu I'm talking about dragging *windows*.

As in, you have a toolbar or something that's within an application, not a WM-managed-window, and you want to drag it out and make it a free floating window, or drag it into another window and make it part of the app window again.

This involves knowing relative positions of all of your app windows, the dragged window, the cursor, etc.

@erincandescent @dalias @mcc @whitequark @becomethewaifu yes, you just need to completely rewrite all of your window management code in a way that is different from how every other OS implements it. Which is a huge headache.

More fundamentally though... wayland released without xdg-toplevel-drag, this is a fairly recent addition.

My biggest problem is that it's being rolled out prematurely, there's still things it can't do that X11 can, and distros should not have been making it default until much further in the future when things were stable and generally at feature parity.

@azonenberg @erincandescent @dalias @mcc @becomethewaifu on one hand, i agree

on the other, making something the default is ... _a_ way of ensuring it achieves feature parity in a reasonable timespan

@whitequark @azonenberg @erincandescent @mcc @becomethewaifu Making users your guinea pigs so you can get your thing made faster is user-hostile behaviour.

@dalias @whitequark @erincandescent @mcc @becomethewaifu yeah that's big-tech-company "move fast and break things" mentality

@azonenberg @dalias @whitequark @erincandescent @becomethewaifu A thing I'd ask is whether Linux distros, in general, have the resources to maintain both X11 and Wayland at a high level of quality. There was probably *some* point where they would have to make an unpleasant decision like this.

However, if this had to happen, I do wish they'd bent over backward to ensure screen reader users weren't in the "oh, it just won't work for you for a while" group. It doesn't sound like they really did.

@mcc @dalias @whitequark @erincandescent @becomethewaifu Yeeeah.

On that note, I would love better screen reader support in imgui since I like the library and would like to use it in other applications.

For ngscopeclient in particular it's a low priority since it's inherently a hyper-graphical application that would be extremely challenging to make useful for people with limited or no vision.

But I can easily see wanting to use imgui for other tools that are more broadly useful, and those might well benefit from better a11y.

But that's orthogonal to the wayland issues.

@dalias @azonenberg @erincandescent @mcc @becomethewaifu the ethos of Linux is "we build shitty software and publish it so that other people who get annoyed at how bad it is spend their time making it less bad". that's how we got where we are, i think. which makes it clearer why we're in this particular situation right now

@whitequark @dalias @azonenberg @erincandescent @becomethewaifu by the way on that note does BSD support wayland at all

@dalias @azonenberg @erincandescent @mcc @becomethewaifu nobody is _forced_ to use Wayland either. I am not using it right now despite being on the latest Plasma version that ships!

@dotstdy @azonenberg @dalias @mcc @becomethewaifu mostly i don't trust applications to be able to do it properly: it requires a lot of knowledge about the state of the desktop that the application might not even have, and it's incredibly difficult to do correctly (saying from experience of doing that)

so to me, trying to avoid this issue structurally makes sense

@whitequark @azonenberg @dalias @mcc @becomethewaifu I wouldn't disagree in theory, but given how much pain and suffering it took to get here (and the decade or so of time) I'm not sure I'd really call it a win. Also some users still want programmatic control, which I don't think is unreasonable.

@dotstdy @azonenberg @dalias @mcc @becomethewaifu I think this is basically reasonable yeah

@whitequark @dotstdy @azonenberg @dalias @mcc @becomethewaifu some applications absolutely require this functionality (accessibility inspectors, RPA, HUD applications, games) and wayland does not actually remove the functionality, they just make you implement it 5 different times in terms of 5 different window managers, which means that for these sorts of apps the correct solution is “just make a Windows version and hope Wine works it out”

@glyph @dotstdy @azonenberg @dalias @mcc @becomethewaifu "Wine is broken*" is like the #1 reason i don't switch to Wayland

* except for fullscreen games

@mcc @glyph @whitequark @dotstdy @azonenberg @becomethewaifu My correct solution is "use the compositor that just translates to X11 protocol and pretends to be the KDE compositor".

@dalias @mcc @whitequark @dotstdy @azonenberg @becomethewaifu is this a real thing?

@glyph @mcc @whitequark @dotstdy @azonenberg @becomethewaifu Kinda already. There are rootful Wayland compositors that display on X, but I don't think there are rootless ones that seamlessly integrate with X window management yet. It definitely can be done and probably will.

@dalias @mcc @whitequark @dotstdy @azonenberg @becomethewaifu oh, you are talking about continuing to run X. that’s a non-starter for me because I am running exclusively in VMs to address a linux *audience*, not to serve my own computing needs. But if I were using it personally, I would need to see a (non-fascist) committed group of maintainers for Xorg going forward first

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

@whitequark @dalias @mcc @becomethewaifu see for example https://github.com/ocornut/imgui/issues/8587

As an app dev basically it means wayland renders core parts of our application ux nonfunctional in a way i can't easily fix or work around

@technobaboo @azonenberg @dalias @mcc @becomethewaifu yeah, i want to write a proxy that lets you share a window with someone remotely so that both of you have input, and features like clipboard just work

wayland makes this very easy, wl_seat's enable it on the protocol level

x11 does not

@whitequark @azonenberg @dalias @mcc @becomethewaifu wait what how?? i had a bug in gtk where it couldn't handle any combo of seats other than the first seat that must be present at the time of binding the global or input wouldn't work? does that work for you? if so i can overhaul my input code to make it work