6 ms·

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

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

badsectoracula 5y ago
> Yes you actually do. This is literally what the program does. 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.
- throwaway82652 5y ago
  >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. 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.
  - badsectoracula 5y ago
    > As a user [...] there will inevitably be race conditions and lost data. 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.

badsectoracula 5y ago

> Yes you actually do. This is literally what the program does. 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.

throwaway82652 5y ago
>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. 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.
- badsectoracula 5y ago
  > As a user [...] there will inevitably be race conditions and lost data. 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.