ZDoom

Echoing Graf's frustration.

I love Linux and in order for other people to use Linux it has to be, well, usable. Right now though - this is what Linux users look like to everyone else:



And this isn't unearned.

ROFL!

This really hits home. I have a colleague who is a big Linux fan and he's the prototypical nerd you often want to yell after as well.

What I meant is that if the checksum of a library is different then it gets to exist and NOT be deduplicated.

That still violates the concept of 'private libraries'.
As soon as you start sharing files you have to be very careful that everybody working with them is folliowing the rules to the letter, and in that regard I would not trust any software developer in the world. Somewhere out there someone will try to outsmart the system and wreak havoc.

Graf Zahl wrote: ↑Wed Nov 30, 2022 1:07 am The worst thing about Wayland is not its technical issues, but that it's yet another thing that will cause fragmentation which keeps Linux numbers down.

The fragmentation isn't as bad as that. For one, Wayland has Xwayland for X compatibility, and the vast majority of X-based apps will continue to run just fine. The toolkits and abstraction layers (e.g. SDL) that support Wayland natively also support X natively. If you target an X-based system, and/or just use up-to-date toolkits and abstraction layers, you'll be just fine. I've been using Wayland for probably about a year now, only switching back to X for a short bit because of a peculiar bug I ran into with the monitor going into power saving mode in KWin when I upgraded my monitor (which was as simple as selecting to use an X session at the login screen). That bug got fixed, and I've been back on Wayland ever since. There was absolutely no hiccup in my workflow during that time, other than the expected quirks with Xorg and the lack of adaptive sync support when I was on it.

You haven't done anything for GZDoom to support Wayland, yet it works perfectly fine here with no change.

But make no mistake, X is legacy. The Xorg developers are only handling fixes and maintenance releases, so unless another group of developers want to take up the code base to keep it alive, it's only a matter of time before Wayland hits critical mass.

Graf Zahl wrote: ↑Wed Nov 30, 2022 1:07 am There was a recent discussion that we might migrate our GUI parts in GZDoom to FLTK but that drew heavy complaints from some Linux users because the library is not yet ready for Wayland.

Ready as in, FLTK's native Wayland backend isn't ready yet? Or that it's X backend has problems with Xwayland? If it's just the former, I wouldn't call that a blocker. As said, the vast majority of X stuff works just fine, so FLTK can use whatever it thinks is best given its current support level.

Ready as in "cannot be compiled for both at once" Last time we checked Wayland was a compile switch, not a runtime setting. Which makes it DOA for precompiled binaries if you want proper support.

I had to defer to the Linux users who claimed it was not viable this way.

Graf Zahl wrote: ↑Wed Nov 30, 2022 3:27 pm Ready as in "cannot be compiled for both at once" Last time we checked Wayland was a compile switch, not a runtime setting. Which makes it DOA for precompiled binaries if you want proper support.

I had to defer to the Linux users who claimed it was not viable this way.

Maybe there's details I'm unaware of with how GZDoom would use it, but as I said, you can generally just target an X-based system and Wayland will run it fine. You don't have to use Wayland natively if you don't gain much from it (Wine/Proton still only uses X, and it's fine to use on Wayland).

I disagree there. Suddenly requiring X11 after having proper Wayland support *just* to introduce a GUI toolkit to GZDoom does not go in the right direction, in my opinion.

As it stands, GZDoom can be run in Wayland without XWayland loaded at all. It shouldn't be a compile flag. GZDoom should be able to choose based on the environment that it is using.

Rachael wrote: ↑Wed Nov 30, 2022 5:10 pm As it stands, GZDoom can be run in Wayland without XWayland loaded at all. It shouldn't be a compile flag. GZDoom should be able to choose based on the environment that it is using.

Do the FLTK developers have any interest in having Wayland support be a runtime selection/switch, or are they insistent on it being compile time? If it's the former, then it seems to be an inevitability, which will hopefully be sooner rather than later.

They seem to be working on it. It is very obvious that a compile time switch is not the right way to go.

XWayland isn't perfect; Wine will work improperly on it if the virtual desktop option isn't enabled. It isn't 100% compatible with plain old Xorg either.

Graf Zahl wrote: ↑Wed Nov 30, 2022 12:28 pm That still violates the concept of 'private libraries'.
As soon as you start sharing files you have to be very careful that everybody working with them is folliowing the rules to the letter, and in that regard I would not trust any software developer in the world. Somewhere out there someone will try to outsmart the system and wreak havoc.

Well that's just PIBKAC (Problem In Between Keyboard And Chair), not the concept's fault. To add, an app should also be able to lock itself into a specific version of a library, i.e with a magic comment stating that it wants a specific version.

Implementing such a complex system just to limit some disk usage, at the cost of not being able to do whole program optimization on code in libraries, is a very poor trade off. But what is even worse is that it muddies the waters on who is responsible and who to blame when things don't work right.

By the way, when you link things in statically you only import the modules that is actually called by an application. That's why the memory and disk savings are actually quite small - you can't just assume that the size of a dynamic library gets added to every executable using it.

Cacodemon345 wrote: ↑Thu Dec 01, 2022 1:36 am XWayland isn't perfect; Wine will work improperly on it if the virtual desktop option isn't enabled. It isn't 100% compatible with plain old Xorg either.

That may well be - but that isn't the real problem here.

The problem is - if a Wayland server is detected, GZDoom should be using pure Wayland calls, and that's what it currently does without a GUI toolkit. If you suddenly throw a library into the mix which only compiles as a Wayland library or X11 library and not both, you then have the problem that GZDoom becomes a mixed application which ultimately requires X11 of some form to even run. I don't know about a lot of people but since Wayland is "the step forward from X11" - this actually feels like it is a step backward. We once were pure-Wayland capable - now we're not. Can you take XWayland for granted? Well the whole point of Wayland is - you shouldn't have to. It was designed from the ground up to be a low-resource low-cost display/desktop server which works a little bit more like Win32's GDI or Apple's Quartz - instead of having all the necessary components be separate programs (i.e. window manager, composition manager, wallpaper, theming, etc) it was supposed to all be compiled directly into the Wayland server itself. Throw XWayland into the mix and you do throw some of those resource savings away - XWayland was supposed to be a stopgap solution for porting apps over, not the ultimate end requirement of using Wayland. (Which unfortunately with the slow adoption of Wayland, is exactly what is ending up happening)

So - XWayland bugs be damned, they aren't the issue here. I do realize you are buttressing the point that we should not rely on it, and I appreciate that - but ultimately I think full Wayland compatibility should be the end-goal of GZDoom. If X11 is deprecated, then it should be in GZDoom as well. If push comes to shove we might just compile FLTK as Wayland-only on our end, but that would leave behind a lot of Linux users, especially those who are on the previous architecture of NVidias (GTX 1650 and older, since the recently open-sourced Linux drivers require a GTX 1660 and newer). Making the GUI toolkit optional in this case would probably be the best way to handle it, and the IWAD picker can be a separate Terminal or GTK2/3 or KDialog component as it was before - but then we won't be able to remove any of that code.

dpJudas wrote: ↑Thu Dec 01, 2022 6:29 am By the way, when you link things in statically you only import the modules that is actually called by an application. That's why the memory and disk savings are actually quite small - you can't just assume that the size of a dynamic library gets added to every executable using it.

I guess those who make these suggestions think of distributions like PrBoom, where all external dependencies are provided as DLLs on Windows. I'd do this for libraries which I do not want to compile myself or be able to quickly swap out (e.g. OpenAL, but in general I prefer static linking for such dependencies.

It is often very apparent when a project is developed by Linux people. They feature an endless list of dependencies which bloat binary size on Windows quite badly. Yes, when you take that approach it will be larger, but that should rather be the exception than the rule.