6 ms·

>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,

>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.
  - badsectoracula 5y ago
    > 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 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.

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.
- badsectoracula 5y ago
  > 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 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.