4 ms·

> 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

> 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.
  - throwaway82652 5y ago
    >you do not access the root window property directly. 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.

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.
- throwaway82652 5y ago
  >you do not access the root window property directly. 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.