4 ms·

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

>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.
- throwaway82652 5y ago
  >This is the same as with files. And in either case in practice there isn't really that much of an issue. No there is an issue, there's a good reason a lot of apps now are using things like sqlite to store data. Yes it's still just files but it's got transactions and journaling and atomic updates and backups built into the API so the chance of accidental corruptions is very low. The Xrm functions never got that, maybe someone could add them (and break everything else in the process) but obviously that never happened. >These designs do not come from some god, they are decisions people (the developers) make. Who have to make them under constraints given by the target users. As a developer you don't get to decide on these constraints, and often the constraints can be conflicting depending on which users you talk to. >Nobody aside from you brought up anything about doing things for free or not, it is completely irrelevant to the discussion. No, wrong. It's completely relevant. This is open source, all work is going to happen for free by default unless you find somebody to pay for it. That's the way it always has been and nobody has wanted to pay for it thus far. You're not making a direct appeal to businesses here or putting up any of your own money up front, so you're effectively suggesting that random community members do it for free. If you know somebody, an "unturned stone" who does want to pay for it then I suggest you take their money for yourself since you seem to be a lot more invested in this than anyone else in this comment thread. >In other words if something is technically possible then it is not a technical issue. >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. And you're still wrong here because this is not technically possible. Being unable to accomplish something technical within the budget constraints means that it's not technically possible. It doesn't matter if they think it's worth it or not, the physical resources are still not there to actually complete the task. It's not that I dislike you saying this, I dislike how this blatant and intellectually-dismissive nonsense persists as a meme. It's incredibly rude and disrespectful to people who work on this. It's like you're framing it so that if only a couple people changed their mind then everything would be just peachy, when I suspect you know very well that it doesn't work that way. You're ignoring the very real technical reasons why the divergence happened to begin with and you're trivializing the work that needs to be done here. But then you go and say later that it would actually not be easy to do this. See where this cognitive dissonance is? Again if you think everyone else is confused and you're the only one who recognizes how much this is worth, then I encourage you to dedicate your time and money towards it. I'm really do hope I'm wrong and you end up successful, but you'd be trying where many others with a lot more resources have failed over the last 40 years. >especially when you take into consideration that both Gtk and Qt break their ABIs at every major version This is a totally different issue and has nothing to do with the availability of said toolkit. >that is in pretty much every Xorg/etc installation Yeah so is GTK1 and GTK2 at this point, those were widely ported to every Unix and also haven't seen updates in like 10-20 years. Remember that Win16 still technically works in most windows installations. There are still a huge number of reasons why nobody should build a Win16 app in 2022. Nobody is going to keep insisting that Win16 is currently the default Windows toolkit. I really have no idea why some Unix geeks try to flip it around and use the same logic to claim that Xaw is still somehow relevant. They're both (relatively) ancient APIs from the same time period.

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.

throwaway82652 5y ago
>This is the same as with files. And in either case in practice there isn't really that much of an issue. No there is an issue, there's a good reason a lot of apps now are using things like sqlite to store data. Yes it's still just files but it's got transactions and journaling and atomic updates and backups built into the API so the chance of accidental corruptions is very low. The Xrm functions never got that, maybe someone could add them (and break everything else in the process) but obviously that never happened. >These designs do not come from some god, they are decisions people (the developers) make. Who have to make them under constraints given by the target users. As a developer you don't get to decide on these constraints, and often the constraints can be conflicting depending on which users you talk to. >Nobody aside from you brought up anything about doing things for free or not, it is completely irrelevant to the discussion. No, wrong. It's completely relevant. This is open source, all work is going to happen for free by default unless you find somebody to pay for it. That's the way it always has been and nobody has wanted to pay for it thus far. You're not making a direct appeal to businesses here or putting up any of your own money up front, so you're effectively suggesting that random community members do it for free. If you know somebody, an "unturned stone" who does want to pay for it then I suggest you take their money for yourself since you seem to be a lot more invested in this than anyone else in this comment thread. >In other words if something is technically possible then it is not a technical issue. >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. And you're still wrong here because this is not technically possible. Being unable to accomplish something technical within the budget constraints means that it's not technically possible. It doesn't matter if they think it's worth it or not, the physical resources are still not there to actually complete the task. It's not that I dislike you saying this, I dislike how this blatant and intellectually-dismissive nonsense persists as a meme. It's incredibly rude and disrespectful to people who work on this. It's like you're framing it so that if only a couple people changed their mind then everything would be just peachy, when I suspect you know very well that it doesn't work that way. You're ignoring the very real technical reasons why the divergence happened to begin with and you're trivializing the work that needs to be done here. But then you go and say later that it would actually not be easy to do this. See where this cognitive dissonance is? Again if you think everyone else is confused and you're the only one who recognizes how much this is worth, then I encourage you to dedicate your time and money towards it. I'm really do hope I'm wrong and you end up successful, but you'd be trying where many others with a lot more resources have failed over the last 40 years. >especially when you take into consideration that both Gtk and Qt break their ABIs at every major version This is a totally different issue and has nothing to do with the availability of said toolkit. >that is in pretty much every Xorg/etc installation Yeah so is GTK1 and GTK2 at this point, those were widely ported to every Unix and also haven't seen updates in like 10-20 years. Remember that Win16 still technically works in most windows installations. There are still a huge number of reasons why nobody should build a Win16 app in 2022. Nobody is going to keep insisting that Win16 is currently the default Windows toolkit. I really have no idea why some Unix geeks try to flip it around and use the same logic to claim that Xaw is still somehow relevant. They're both (relatively) ancient APIs from the same time period.