8 ms·

The reason X resources "failed" - though i do not think they really failed because they do what they are supposed to do - is actually very simple: aside from ap

The reason X resources "failed" - though i do not think they really failed because they do what they are supposed to do - is actually very simple: aside from applications based on Xt and a few others using xlib,etc directly and decide to bother, pretty much no application uses them, often for the same reasons no application uses xlib or xt or even motif directly: partly fashion (IIRC back when they were fashionable and apps used them KDE1's themes would set up X resources for these applications to pick up the same colors as Qt and Gtk apps) and partly because they work only under X11 when many open source applications try to use cross platform solutions (and Qt and Gtk provide their own solutions for the same tasks that do pretty much the same thing but also work in Windows and Mac). 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

throwaway82652 5y ago
>i do not think they really failed because they do what they are supposed to do 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.
- badsectoracula 5y ago
  > If they were supposed to be a way to configure applications, they failed because they're actually bad for configuring applications 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 This updates a single resource, leaving everything else as-is, not even involving any files (but the exact same resource could have been inside a file too). > 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.
  - throwaway82652 5y ago
    >They are at most as bad as any other key-value storage. 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.
exfascist 5y ago
I wish there was a way to make Gnome respect the Xresources colors (even if it's by just generating a theme periodically.) All my Xlib/Xt/tk apps have a nice dark solarized color scheme but the moment I open a GTK app I'm blinded.
- smoldesu 5y ago
  What I've done is pin my app versions at the last release before GTK4, that seems to do the trick for now (especially since I have yet to encounter a GTK4 app that updated functionality over it's predecessor).
  - throwaway82652 5y ago
    Have a look at some of the recoloring support in the new gnome text editor: https://blogs.gnome.org/chergert/2021/12/03/text-editor-happenings/ https://blogs.gnome.org/chergert/2021/12/03/text-editor-happ... Those colorings simply wouldn't be possible without GTK4 and libadwaita. GTK3 has nothing like it.
    - smoldesu 5y ago
      It is/was possible. GTK3 let you edit the CSS of your program to facilitate it. People didn't do that though, because we had a functional theme interface that was much better supported. Well, we did have it at one point... Furthermore, if you consider "changing the way my app looks" to be functionality, then one could argue that GTK4/libadwaita was a functional regression.
      - throwaway82652 5y ago
        You can just look at the screenshots in that blog, GTK4/libadwaita also supports changing the way the app looks. >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.
kiwidrew 5y ago
Actually the cross-platform Tk widgets use an internal "option database" which is essentially just Tcl-flavoured X11 resources. The typical usage is to just set the various options in the application's code, but it's also possible to merge in the display's existing X resources. > 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.

throwaway82652 5y ago

>i do not think they really failed because they do what they are supposed to do 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.

badsectoracula 5y ago
> If they were supposed to be a way to configure applications, they failed because they're actually bad for configuring applications 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 This updates a single resource, leaving everything else as-is, not even involving any files (but the exact same resource could have been inside a file too). > 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.
- throwaway82652 5y ago
  >They are at most as bad as any other key-value storage. 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.

exfascist 5y ago

I wish there was a way to make Gnome respect the Xresources colors (even if it's by just generating a theme periodically.) All my Xlib/Xt/tk apps have a nice dark solarized color scheme but the moment I open a GTK app I'm blinded.

smoldesu 5y ago
What I've done is pin my app versions at the last release before GTK4, that seems to do the trick for now (especially since I have yet to encounter a GTK4 app that updated functionality over it's predecessor).
- throwaway82652 5y ago
  Have a look at some of the recoloring support in the new gnome text editor: https://blogs.gnome.org/chergert/2021/12/03/text-editor-happenings/ https://blogs.gnome.org/chergert/2021/12/03/text-editor-happ... Those colorings simply wouldn't be possible without GTK4 and libadwaita. GTK3 has nothing like it.
  - smoldesu 5y ago
    It is/was possible. GTK3 let you edit the CSS of your program to facilitate it. People didn't do that though, because we had a functional theme interface that was much better supported. Well, we did have it at one point... Furthermore, if you consider "changing the way my app looks" to be functionality, then one could argue that GTK4/libadwaita was a functional regression.
    - throwaway82652 5y ago
      You can just look at the screenshots in that blog, GTK4/libadwaita also supports changing the way the app looks. >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.

kiwidrew 5y ago

Actually the cross-platform Tk widgets use an internal "option database" which is essentially just Tcl-flavoured X11 resources. The typical usage is to just set the various options in the application's code, but it's also possible to merge in the display's existing X resources. > 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.