4 ms·
But the author did mention that, albeit not with the level of detail you do... (X resources can sort of be used to provide different options for different invo
by smhenderson 4y ago
But the author did mention that, albeit not with the level of detail you do...
(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.)
- Epiphany21 4y agoApps that don't support that flag can be used with the -xrm flag instead. You can put a bunch of these into a wrapper script like this xterm -xrm "someresource: color"
- throwaway82652 4y agoThat doesn't change what the parent post said. Apps still have to explicitly support that xrm flag. Some apps just don't support it.
- Epiphany21 4y agoThis is a toolkit problem then. Apps that use an X11 native UI toolkit like Xaw or Motif will respond to the -xrm flag. It's not the fault of X11 if third party software refuses to follow existing specs.
- throwaway82652 4y agoNo it's not a toolkit problem, you have a misunderstanding of what specifications are supposed to be. If the existing spec doesn't work for them then you can't expect them to support it. The process of making a spec or standard is not about forcing other projects to follow suit, it's about finding mutual common ground that is agreed upon by everybody.
- Epiphany21 4y agoWhat you are describing is a toolkit problem. GTK and Qt are not built on top of the X toolkit intrinsics, which is why apps built with them often have poor or non-existent X resource support. Toolkits designed around Xt have this stuff baked in. https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics 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.
- throwaway82652 4y ago>GTK and Qt are not built on top of the X toolkit intrinsics 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.
- 4y ago