The failure of the idea of X resources
utcc.utoronto.ca
utcc.utoronto.ca
At the end of the day X resources are just key-value pairs and the file allows for wildcards, includes, etc so if anything they can be more flexible than the adhoc configuration files many programs use. But there isn't anything special about them, you might as well say that GetPrivateProfileString failed because people write their own INI parsers :-P
No, this is wrong. If they were supposed to be a way to configure applications, they failed because they're actually bad for configuring applications. It's basically putting a giant global .ini file into the X server that can't be read or updated without reprocessing the whole thing. I bet you can think of a few reasons why it's a terrible idea to do that. It might make sense in a motif-only world if all you're trying to do is change some global settings, and you never want to have a GUI that can safely change those settings. But the utility of that disappears when you have more than one toolkit with its own settings.
They're not the same as GetPrivateProfileString, those manipulate individual files. Xrdb would be like if you you were only ever allowed to call GetPrivateProfileString on one file across the whole system. And yes I know apps can put in whatever logic they want to load their own resource files. If you do that then there is no point to using them over some other configuration mechanism stored outside the currently running X server.
They are at most as bad as any other key-value storage.
> It's basically putting a giant global .ini file into the X server that can't be read or updated without reprocessing the whole thing.
You can update X resources without reprocessing "the whole thing" - in fact there isn't even a single "whole thing" to process, you can have resources in separate files, import them at any point or even change individual resources. Example:
echo 'XTerm.vt100.background: gray10' | xrdb -merge
> the utility of that disappears when you have more than one toolkit with its own settings.
X resources are not locked to a single toolkit, they are locked to X11, but any application using any toolkit could use them.
> They're not the same as GetPrivateProfileString, those manipulate individual files.
This is irrelevant to the point i was making with referring to GetPrivateProfileString, which was about applications using their own (or their toolkit's) INI parser instead of using what is provided by Windows.
No, a lot of other key value storage systems allow you to update individual rows and get notifications when individual rows changed, kind of like you know, an actual database and not just an ini file.
>You can update X resources without reprocessing "the whole thing"
No, this is very wrong. What your example actually does is:
- Read the entire global database from the X server, by fetching a property on the root window, which is just a string containing the entire database
- Recreate the database in the client's memory
- Merge in the one resource into the client's copy
- Write the entire global database back to the X server again, by writing the root window property
I encourage you to look at the source code to xrdb to verify this. I don't think I need to explain why this has problems and is actually bad, as is any other mechanisms in X that require clients to write to properties on the root window.
>X resources are not locked to a single toolkit, they are locked to X11, but any application using any toolkit could use them.
Sure. The problem here is that other toolkits will naturally disagree on resource names and will support resources that other toolkits don't, or that even conflict with resources defined by other toolkits. I think we know by now you can't just dump every setting from every app and toolkit into a key-value store of strings and expect it to work.
>which was about applications using their own (or their toolkit's) INI parser instead of using what is provided by Windows.
No not really. Even Microsoft suggests you don't use that function and instead use the registry because, despite all it faults, at least it correctly functions as a storage database. That function is also just bad because it requires reparsing the whole file if you want to read multiple keys.
You refer to something different, not just some way to store configuration.
> What your example actually does is
That isn't really relevant though, that is an implementation detail, you do not access the root window property directly. It is a reason why it can be fragile but you'd have the same issue with some configuration library that read an entire file, made changes to key-value pairs and saved the file back - and then the same library was used at the same time by two different programs or instances of the same program.
> Sure. The problem here is that other toolkits will naturally disagree on resource names and will support resources that other toolkits don't, or that even conflict with resources defined by other toolkits.
Again, this isn't really an issue with X resources you cannot expect a resource meant for application A to apply to application B even if B could read it if it wanted. That different applications (and/or their toolkits) do not agree to common keys is a separate issue that isn't solved by using a different storage method. There isn't really a technical reason why applications can't agree to some shared keys (like, e.g. applications, toolkits and window managers agree to some common protocols to communicate with each other) regardless of their underlying toolkit. This is all a social aspect - the programmers who wrote those applications/toolkits decided to not support them.
> No not really. Even Microsoft suggests you don't use that function and instead use the registry because, despite all it faults, at least it correctly functions as a storage database.
Registry is something different, i explicitly mentioned this function in the context of parsing INI files.
I mean, i do not think X resources is a great way to do configuration, but a major issue IMO is that it being locked to X11 when all popular toolkits wanted to also support other systems meant that they had to come up with their own approaches and nobody bothered to address (and maintain) the issues it has - so those issues remain around to this day. Same reason basically why Xaw despite being the closest to a default toolkit Xorg has still comes with the same primitive monochromatic look with usability that doesn't match to any common GUI toolkit released in the last 35 years.
Yes you actually do. This is literally what the program does. Please just look at the source code, we will go around in circles if you just go off my word. It's not just an implementation detail if that detail causes issues everywhere else.
>but you'd have the same issue with some configuration library that read an entire file
Yes you would, that's why file-based systems are also bad for storing configuration that needs to be accessed by multiple programs concurrently. They work fine if you have a program that ensures only one instance of itself is running, and you never edit the file with a text editor.
>There isn't really a technical reason why applications can't agree to some shared keys (like, e.g. applications, toolkits and window managers agree to some common protocols to communicate with each other) regardless of their underlying toolkit. This is all a social aspect - the programmers who wrote those applications/toolkits decided to not support them.
But this is wrong, other toolkits won't support resources that conflict with their own keys, they also won't implement shared keys that cause them issues or that are too much work to maintain compared to the benefit of them. We've seen this over and over when people propose standards for X11 based programs. It's not just a social issue. There is actual work that needs to be put into supporting these things everywhere and if you can't find people to do it then it won't happen.
>Registry is something different, i explicitly mentioned this function in the context of parsing INI files.
No we're talking about the same thing. The issue here is how do apps store and access configuration. The Xresources aren't magic, apps access those in the same way: by copying the whole database from the X server. So it's either that or you use another approach, like a registry.
>that they had to come up with their own approaches and nobody bothered to address (and maintain) the issues it has
Well many people have tried but none of the solutions stuck. Xaw is only considered a "default toolkit" because it was the first one, not because it was actually good at anything.
I mean't you as a user using xrdb, not what xrdb does. Also applications are supposed to use Xrm functions, not messing with properties directly. That doesn't mean that an application can't do that, but unless it has a good reason to, it doesn't have to do that.
> other toolkits won't support [..] they also won't implement [...] or that are too much work to maintain. We've seen this over and over when people propose standards for X11 based programs. It's not just a social issue.
But that IS social issue - people agreeing that doing that is a good (or not) thing is a social issue, not a technical issue. There is nothing that technically prevents this, or even providing a more robust API to X resources with 100% fully backward compatibility (using, e.g. an X server extension that provides the configuration functionality with updates, etc, that then is exposed to root window in a serialized form). It is that historically nobody cared enough to do that, which is a social issue.
> The issue here is how do apps store and access configuration
The overall topic was but when i brought up that API in the comment above i was referring to INI parsing specifically.
> Well many people have tried but none of the solutions stuck.
There were tons of forks, mainly to change the looks, but none were adopted by XFree86 which is basically why they didn't stick. Some Linux distributions used them (e.g. i think Slackware to this day still comes with the Xaw3D) but by being ignored by the main X distribution, none of those went anywhere.
> Xaw is only considered a "default toolkit" because it was the first one
Well, it is also that because -in practice- it is the only one that is available in any Unix where there is Xorg (or a fork of it) running :-P.
As a user you have to be aware of this or you could mess up your settings. Applications that use Xrm functions make it even more complicated because those could merge the resource in strange ways or just write anything into the root property and clobber your whole setup. So now you have to be aware of each client's specific behavior in regards to this. If two clients try to merge the resources at once then there will inevitably be race conditions and lost data. It's just not realistic to ask users to know this much about what is being abused as a database. It should just work, and that's why nobody uses Xresources anymore.
>But that IS social issue - people agreeing that doing that is a good (or not) thing is a social issue, not a technical issue. There is nothing that technically prevents this,
No you're wrong. I'm sorry but I really can't stand when people say this. It is absolutely a technical issue because no two toolkits will support the exact same set of options. If they didn't want to do a different design with a different set of options then they wouldn't have made another toolkit. Once they do, then you're faced with the very real technical problem of how to reconcile two diverging designs. You're saying it's a social issue because people can't be bothered to do this work for free, and I'm sorry but that's not how anything works. If it were that easy then you would have done it by now.
Maybe you're trying to say that it would be better if we all used one toolkit, but the ship has long sailed on that, on every single operating system that exists. It also isn't possible to make the one toolkit that does everything everyone wants and works with every possible standard that somebody has ever published.
>Well, it is also that because -in practice- it is the only one that is available in any Unix where there is Xorg (or a fork of it) running :-P.
I don't think so, both GTK and Qt are pretty portable and have been available on other Unixes. Also it's not like Xaw has any HPUX or Solaris specific features to warrant using it.
This is the same as with files. And in either case in practice there isn't really that much of an issue.
> No you're wrong. I'm sorry but I really can't stand when people say this.
You disliking me saying this doesn't make me wrong you know.
> It is absolutely a technical issue because no two toolkits will support the exact same set of options.
The social issue is on the "why".
In other words if something is technically possible then it is not a technical issue.
> If they didn't want to do a different design with a different set of options then they wouldn't have made another toolkit. Once they do, then you're faced with the very real technical problem of how to reconcile two diverging designs.
These designs do not come from some god, they are decisions people (the developers) make.
> You're saying it's a social issue because people can't be bothered to do this work for free, and I'm sorry but that's not how anything works.
Nobody aside from you brought up anything about doing things for free or not, it is completely irrelevant to the discussion.
My claim is that it is a social issue because people decide to not do it not because it is technically impossible but because they do not think it is worth to do it.
> If it were that easy then you would have done it by now.
Also nobody claimed it'd be easy.
> Maybe you're trying to say that it would be better if we all used one toolkit, but the ship has long sailed on that, on every single operating system that exists. It also isn't possible to make the one toolkit that does everything everyone wants and works with every possible standard that somebody has ever published.
No i'm not trying to say that and while having one toolkit would help some things, as you write you cannot have one toolkit be the best for everyone.
> I don't think so, both GTK and Qt are pretty portable and have been available on other Unixes. Also it's not like Xaw has any HPUX or Solaris specific features to warrant using it.
They might be portable and available but that is not the same as available everywhere there is a X/Xorg/fork server running, especially when you take into consideration that both Gtk and Qt break their ABIs at every major version (e.g. nowadays many distributions do not carry Qt4 so any 2010 binary that was written against it would not work in current distributions, however any 2010 binary that was written against Xaw would still work - of course that is just an example of what i meant, any 2010 binary that was written against Gtk2 would still work though i'm not sure for how long that'd be the case).
In any case this is beside the point of that paragraph, my point was that Xaw despite being the closest thing to a default toolkit (regardless if strictly speaking it is one) that is in pretty much every Xorg/etc installation hasn't seen any changes since the early 90s. And that is because nobody cared to do that despite being technically possible to do so, since all effort went into other toolkits that weren't even locked into X11.
No there is an issue, there's a good reason a lot of apps now are using things like sqlite to store data. Yes it's still just files but it's got transactions and journaling and atomic updates and backups built into the API so the chance of accidental corruptions is very low. The Xrm functions never got that, maybe someone could add them (and break everything else in the process) but obviously that never happened.
>These designs do not come from some god, they are decisions people (the developers) make.
Who have to make them under constraints given by the target users. As a developer you don't get to decide on these constraints, and often the constraints can be conflicting depending on which users you talk to.
>Nobody aside from you brought up anything about doing things for free or not, it is completely irrelevant to the discussion.
No, wrong. It's completely relevant. This is open source, all work is going to happen for free by default unless you find somebody to pay for it. That's the way it always has been and nobody has wanted to pay for it thus far. You're not making a direct appeal to businesses here or putting up any of your own money up front, so you're effectively suggesting that random community members do it for free. If you know somebody, an "unturned stone" who does want to pay for it then I suggest you take their money for yourself since you seem to be a lot more invested in this than anyone else in this comment thread.
>In other words if something is technically possible then it is not a technical issue.
>My claim is that it is a social issue because people decide to not do it not because it is technically impossible but because they do not think it is worth to do it.
And you're still wrong here because this is not technically possible. Being unable to accomplish something technical within the budget constraints means that it's not technically possible. It doesn't matter if they think it's worth it or not, the physical resources are still not there to actually complete the task. It's not that I dislike you saying this, I dislike how this blatant and intellectually-dismissive nonsense persists as a meme. It's incredibly rude and disrespectful to people who work on this. It's like you're framing it so that if only a couple people changed their mind then everything would be just peachy, when I suspect you know very well that it doesn't work that way. You're ignoring the very real technical reasons why the divergence happened to begin with and you're trivializing the work that needs to be done here. But then you go and say later that it would actually not be easy to do this. See where this cognitive dissonance is? Again if you think everyone else is confused and you're the only one who recognizes how much this is worth, then I encourage you to dedicate your time and money towards it. I'm really do hope I'm wrong and you end up successful, but you'd be trying where many others with a lot more resources have failed over the last 40 years.
>especially when you take into consideration that both Gtk and Qt break their ABIs at every major version
This is a totally different issue and has nothing to do with the availability of said toolkit.
>that is in pretty much every Xorg/etc installation
Yeah so is GTK1 and GTK2 at this point, those were widely ported to every Unix and also haven't seen updates in like 10-20 years. Remember that Win16 still technically works in most windows installations. There are still a huge number of reasons why nobody should build a Win16 app in 2022. Nobody is going to keep insisting that Win16 is currently the default Windows toolkit. I really have no idea why some Unix geeks try to flip it around and use the same logic to claim that Xaw is still somehow relevant. They're both (relatively) ancient APIs from the same time period.
Yes but a ton of others - and in fact i'm betting that they are by far the majority - store their settings, state, etc in files.
> Who have to make them under constraints given by the target users. As a developer you don't get to decide on these constraints, and often the constraints can be conflicting depending on which users you talk to.
Sorry but right now you just decided to throw the ball at some vague unspecified "target user" which is completely unhelpful for any discussion.
Also no end user ever made a decision in the place of a developer about if a program will use X resources or not. Also...
> No, wrong. It's completely relevant. This is open source, all work is going to happen for free by default unless you find somebody to pay for it. That's the way it always has been and nobody has wanted to pay for it thus far.
No, sorry but you are the wrong one, you are trying to tie two unrelated issues together. If something is done for free or not is completely irrelevant to if someone is decided to be a good idea or not.
A bad idea doesn't become good because someone was paid for implementing it.
But it looks like...
> And you're still wrong here because this is not technically possible. Being unable to accomplish something technical within the budget constraints means that it's not technically possible.
...you want that to be the case so you can claim i am wrong. However something being technically possible and someone having the time, budget and/or knowledge to do it are two completely independent things - someone (or some team) being unable to do something doesn't make it technically impossible, it only makes it impossible for that someone (or that team).
> This is a totally different issue and has nothing to do with the availability of said toolkit.
In my original reply i referred to being able to use something out of the box, this is why i brought up binaries.
> Yeah so is GTK1 and GTK2 at this point, those were widely ported to every Unix and also haven't seen updates in like 10-20 years.
GTK1 is not available in every Xorg installation, in fact the only Linux distribution i am aware of that still distributes it is Slackware. Other distros and AFAIK pretty much all of the BSDs do not ship GTK1. I know this first hand because recently i decided to fix Lazarus[0] GTK1 backend and had to make my own builds[1] for it.
Again, i brought up binaries as an example for that.
> Remember that Win16 still technically works in most windows installations.
Only 32bit builds of Windows, which are by far the minority (you can use OTVDM to run Win16 apps in Win64 but it is both buggy and you can't rely it on it being there since it is a 3rd party app).
> I really have no idea why some Unix geeks try to flip it around and use the same logic to claim that Xaw is still somehow relevant.
If you think that i did that, i really think you have no idea what i was referring to or why i brought up Xaw in the first place and i'd recommend paying closer attention to what i write.
Those colorings simply wouldn't be possible without GTK4 and libadwaita. GTK3 has nothing like it.
Furthermore, if you consider "changing the way my app looks" to be functionality, then one could argue that GTK4/libadwaita was a functional regression.
>we had a functional theme interface that was much better supported. Well, we did have it at one point
This is revisionist history, GTK3 never had a real theme interface. The changes in libadwaita were directly because CSS is not a functional or reliable way to reskin apps and themes were known as a good way to break GTK3 apps. Using a global CSS has a lot of the same problems as X resources, it's sending a giant string into the app that may or may not override certain things based on random string matching. The CSS styles all cascade together and there is no way to know what app is going to get what styles or enforce that an app uses particular style classes.
In any case, I've ended up migrating away from GTK4 for the majority of my use cases anyways. Like I said, it has given us no functional changes in any of the apps I've used (or seen, for that matter), so I don't really feel bad dropping it from my systems. It also doesn't make me feel bad freezing all the apps I write at GTK3, since the developer experience is frankly so much better the further you go back in GTK history.
This is literally exactly what is happening in libadwaita. The stylesheets are still there but the apps are more robust by enforcing the use of particular styles. I don't know what else you would expect here. In this situation "more robust" is always going to mean restricting the theme options to a subset which we know works.
>Unfortunately, the lead GNOME maintainers never asked for the community opinion
This is a nonsensical statement and is a misunderstanding of how open source works. Decisions are not made based on "community opinions" they're made by those who show up and do the work. It would make no sense for any open source maintainer to ask for "community opinions". Of course if you ask random commenters on Hacker News and Slashdot if they want you to develop all kinds of impossible features and give it to them for free, they will always say yes.
>Like I said, it has given us no functional changes in any of the apps
Again please check those screenshots in the blog. The recoloring functionality there would not be possible in GTK3. It's not very fun to talk to you when you repeatedly ignore what I'm saying.
I'm not even going to argue this with you since there's nothing to argue about. The book is closed. GTK4 and Libadwaita are direct regressions from the functionality we had with GTK3 and libhandy. You can argue that these regressions exist for a purpose, and you can point to purported upcoming features and their purported upcoming functionality, but none of that changes what things look like right now. At the end of the day, as both a user and a developer, I need functionality. If you take that away from me, you can't also expect me to go along with whatever you're proposing for the future.
No we're not, you're ignoring what I'm saying. Nothing was obfuscated and developers and users didn't lose any flexibility. Take a look at those screenshots. Developers actually have more flexibility here because now they have recoloring in addition to the traditional stylesheets. I don't understand what this has to do with flatpak either, that's not really any different from the other package managers as far as themes go.
>GTK4 and Libadwaita are direct regressions from the functionality we had with GTK3 and libhandy.
No, this is absurdly and egregiously wrong and the book is not closed. The only thing that's really happened here is added functionality. Right now nothing has actually been removed. I'm completely 100% serious about this. You're wrong here. This is a big non-issue that you've blown out of proportion. The recoloring isn't even an upcoming feature. It's already usable in a limited form, you can see it in action in the text editor I posted. What is upcoming is having a nicer API around it. And this also isn't "purported" either, you can see the very real work happening on it right now: https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/3...
This isn't true though. https://github.com/Gnostiphage/adwaita-color-gen
>Yes, they added a new way to do a thing. That alone does not an upgrade make.
I'm confused as to what you think new features and upgrades are exactly, besides new ways to do things.
For GTK? Yes it is new and it is functionality, full recoloring of the theme was not previously supported. You can just look at the screenshots, the recoloring in the new text editor is an obvious improvement over the limited theme support that was in gedit. Maybe you don't want this functionality, and that's fine, but either of us can go open these apps up in a VM right now and compare them and note for a fact that the functionality has been added.
Actually it is. That generator is only changing the equivalent of accent color. The libadwaita recoloring is the whole app. You will run into issues if you try to recolor everything in GTK3 that way. Yes you could technically rewrite the whole GTK3 stylesheet and recolor it that way, and lots of theme authors have done that, but at that point it's no different from what libadwaita does.
So... we're just conceding that the feature you outlined isn't new, just a different way of getting an outcome that could already be achieved with older versions?
No, it could not be done in older versions unless you made all apps base their design around that stylesheet, which nobody actually did because it would break a lot of older apps. They didn't bother to do it until GTK4 because it requires changing the stylesheet anyway and apps have to actively migrate to it, so it's the perfect time to get this out of the way.
If you're referring to individual apps, yes they could always technically implement their own theming system, just like they could always implement their own toolkit from scratch if they really wanted to. The point now is it's built into the platform and will actually have a shot at being usable in every app using libadwaita, not just ones that decide to ship a third party stylesheet because they decided they want to support ubuntu or budgie or something.
Which again nobody actually relied on because it broke everything. I didn't make this up, this is exactly why things changed in GTK4. You can still do that in GTK4 by the way, and it's still just as bad an idea as it was before and it will stop the app from looking native. I have also built applications that way and I don't recommend it.
But I don't actually understand your aversion to having a platform theme if you care about having "native apps". That's the whole point of a native app, it's supposed to use the platform theme and follow the platform HIG, and that means no custom stylesheets. There's no other definition of a native app that I'm aware of. I see constant criticism on Hacker News towards web apps and Electron apps specifically because they don't use a native platform theme and instead every app has a custom stylesheet because that's what you do when you make web apps.
No, it really isn't. There are plenty of MacOS apps that follow the Mac HIG, but still suck completely because they rely on Electron for their backend. The "point" of a native app is that, well, it runs natively. There is no non-native runtime. You can't make this argument because we've had our cake and ate it too for the past 20 years on GTK, it just sounds to me like you didn't like the old way of doing things and now you're trying to defend the new way as if it's a fact or a law. Both are two opinionated ways of building native apps, each with their own ups and downs. This is why I say we're at an impasse: I value flexibility over conformity, and you value stability over accessibility. That's fine, but it's pointless for you to push these arguments when, as we've shown, the features you outline already existed in past versions. Yes they broke everything. You know what else breaks everything? GTK4's text rendering. Libadwaita on any system that isn't a GNOME one. Wayland on everything except highly specific hardware and software combinations.
You're welcome to your opinion. I just think it's wrong, and that's why I'm continuing to outline it here. You're also welcome to argue against my opinion, but unless you actually address my complaints you're not going to walk away "the winner" here.
You probably only saw the first few ones. In later ones you can see it changes more than just the accent color.
That script is also fairly ridiculous to me, it's a shell script that is literally copying the CSS wholesale and running sed on them. So again that's rewriting the whole CSS file and expecting the app to use that stylesheet, it's not the same as doing a dynamic recoloring at runtime.
But I'm more puzzled as to why you're using xlib and xt apps in 2022.
EDIT: I can't reply to your comment so I'll write the reply here. Yes, on paper GTK3+ sounds like it would be more touch device friendly. They make up for it with absolutely awful, huge, modal UIs with low information density (missing scroll gestures with Xinput2 don't matter if you're not having to scroll all the time.)
If you want to reply to deeper comments you can click the "X hours/minutes ago" title on the reply.
I think the fundamental disagreement here is on the definition of usability. Perhaps something like the product of ergonomics and discoverability? Cluttered UIs are visually distracting and harder to learn but the lack of modality is, IMO more ergonomic. That tradeoff always exists and I think the Gnome devs pretty consistently lean too far towards the easy to learn side which results in less usable UIs for everyone but people just learning the software for the first time.
Much better than plain XT.
> At the end of the day X resources are just key-value pairs and the file allows for wildcards, includes, etc
If you squint a little bit, X resources are proto-CSS for the desktop: the clients have a tree of widgets (each widget having a class and a name) and query the resource database for style properties that apply to this tree; the resource database is composed of patterns ("selectors") and values for the various style properties; and applications have a default set of resources baked in which the user's resource database may override. Resource values are also typed (e.g. font, colour, screen position) and there is a rich syntax for specifying things like colours. It's all very elegant, but depends critically upon the X client (or its toolkit) actually bothering to implement this scheme. Qt never bothered and Gtk let its support slowly rot away.
Take a walk around /etc and you’ll also see evidence of the diversity of contributions in the diversity of config styles.
It’s like a community center that has a completely weird set of chairs in the dining area, because every chair came from a different random donation. The design shambles is an awesome emergent property of the level of community engagement.
With apologies to ”Facebook is a chair”.
These days the scene is dominated by people who think "Everybody listens to boybands so we have to become a boyband too." And shame anyone who speaks up in disagreement.
This is one of the greatest comments I have ever seen.
Also 8/10 of these people have used this chair 3 times, grand total of 15 seconds maximum, at best. If you are lucky these occurrences were within the past 10 years. But again: don't you dare do it unless you want an essay on why that shitty chair is actually the most platonically ideal chair that ever graced Gods Earth. Until you fucked it up, that is.
I wouldn't knock the potty chairs either, when you get old and your health starts failing, you may just end up needing one again. That's something that could happen to everyone.
Or just let people use their chair.
> I wouldn't knock the potty chairs either, when you get old and your health starts failing, you may just end up needing one again.
Sure but old people wont fit in potty chairs for toddlers and when most people want to use a chair they do not have potty chairs in mind :-P
If someone really wants to use that chair they could very easily go and locate the broken chair in the junkyard again. But nobody actually wants to do that because when you press them, they admit they're just being nostalgic and actually it's got lots of protruding rusty nails and they'll get poked if they pick it up again.
Throwing out the chair does indeed stop people from using it.
This isn't true. Let's go with the example program provided. XTerm supports the -name flag, which will make it respond to existing resources using that name in the resource database.
.Xresources:
customxterm1*some*resource: colorhere
customxterm1*another*resource: fonthere
customxterm2*some*resource: colorhere
customxterm2*another*resource: fonthere
Then you can launch xterm with "xterm -name customxterm1" and it'll pick up the resources.
Edit: Formatting on this site is a pain.
(X resources can sort of be used to provide different options for different invocations of the same program, but how to do it isn't necessarily obvious, it requires additional command line options to the program, and even programs that use X resources don't always support it.)
xterm -xrm "someresource: color"
It's not the fault of X11 if third party software refuses to follow existing specs.
https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics
Also I'm not asking anyone to support anything. I'm asking you to know the facts first if you're going to bash a specific piece of technology for lacking functionality (which it doesn't, really).
X11/Xorg bashing is in vouge, for some odd reason, despite it working pretty well for most *nix users. If you want alternatives like Wayland and GTK to succeed, then contribute to those and make them into a desirable upgrade path for X11 server and toolkit users.
Frankly, you have not presented any good arguments that would change my mind on any issue so far.
That changes nothing, they have no reason to base themselves on Xt if that doesn't work well for them, which it doesn't for a number of other reasons. Also X was intentionally designed to support multiple toolkits using any underlying library they want, so the designers definitely didn't intend for everyone to use Xt.
>X11/Xorg bashing is in vouge, for some odd reason, despite it working pretty well for most *nix users.
There's no bashing here. These are just the facts. It was a fine thing for the time it was created, it's now obsolete and doesn't work that well anymore. Hindsight is 20/20 and all that. That's the way it goes with things.
>If you want alternatives like Wayland and GTK to succeed
This is a bad way to take the conversation. I don't really care what succeeds. There's no reason to get that invested in any particular solution aimed towards something so fleeting (and lacking in rewards) as the attention of a bunch of random Linux distributions.
But I would say those things have already been largely successful at what they set out to do.
>you have not presented any good arguments that would change my mind on any issue so far.
I don't really care about changing your mind either. If you want to change your mind, that's completely your decision to make. I can only point you towards facts that may illustrate other perspectives.
The better way is to just have an intentional global setting if that's what you're trying to do. On modern Linux those too can be remote forwarded over D-Bus or with any number of other mechanisms. A configuration system based on wildcard or regex matching is always going to be fragile and hard to use.
Under X Resources, no, I can't dynamically change the resolution or configuration of a running process. On the other hand, I can update resources and configure different applications independently. One of my frustrations with GNOME/KDE is that the configuration system seems to think that I want the same settings for every application presently running. This might very well not be the case: I could prefer larger and/or different fonts for specific applications or for specific processes or windows. The uncoupling of settings in some cases (e.g., text / font zoom in some apps) suggests that the FreeDesktop folk have become grudgingly aware of this.
Many old-school Xt / Motif utilities will also accept commandline options, either via flags or in some cases resources specifications. These can be tied together in scripts to launch, say, a range of values (fonts, sizes, colours) for specific tasks. I'd long done this to differentiate between terminals running (nominally) bash shells, vim, mutt, w3m, and a launcher which would open a set of terminal windows, each with different background colours and geometry specifications to be placed over a desktop workspace when working on multiple remote hosts (colours, prompts, and spatial cues to "this is not your local box").
And of course, since resources live in files, they can be documented, commented, and divided (separate files) for various tasks, as well as version controlled. Few if any of which the GNOME configuration database permits. The files can be readily copied between systems (as I've done for decades).
X Resources can be clunky in some regards, but they're also lightweight, powerful, configurable, and get out of the way rather than obstruct my goals.
Don't those systems have some of aforementioned issues? E.g. is it possible to have several setups of a program utilizing gsettings?