3 ms·
>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
by 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> No there is an issue, there's a good reason a lot of apps now are using things like sqlite to store data. Yes but a ton of others - and in fact i'm betting that they are by far the majority - store their settings, state, etc in files. > 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. Sorry but right now you just decided to throw the ball at some vague unspecified "target user" which is completely unhelpful for any discussion. Also no end user ever made a decision in the place of a developer about if a program will use X resources or not. Also... > 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. No, sorry but you are the wrong one, you are trying to tie two unrelated issues together. If something is done for free or not is completely irrelevant to if someone is decided to be a good idea or not. A bad idea doesn't become good because someone was paid for implementing it. But it looks like... > 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. ...you want that to be the case so you can claim i am wrong. However something being technically possible and someone having the time, budget and/or knowledge to do it are two completely independent things - someone (or some team) being unable to do something doesn't make it technically impossible, it only makes it impossible for that someone (or that team). > This is a totally different issue and has nothing to do with the availability of said toolkit. In my original reply i referred to being able to use something out of the box, this is why i brought up binaries. > 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. GTK1 is not available in every Xorg installation, in fact the only Linux distribution i am aware of that still distributes it is Slackware. Other distros and AFAIK pretty much all of the BSDs do not ship GTK1. I know this first hand because recently i decided to fix Lazarus[0] GTK1 backend and had to make my own builds[1] for it. Again, i brought up binaries as an example for that. > Remember that Win16 still technically works in most windows installations. Only 32bit builds of Windows, which are by far the minority (you can use OTVDM to run Win16 apps in Win64 but it is both buggy and you can't rely it on it being there since it is a 3rd party app). > 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. If you think that i did that, i really think you have no idea what i was referring to or why i brought up Xaw in the first place and i'd recommend paying closer attention to what i write. [0] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ [1] http://runtimeterror.com/pages/badsector/gtk12/ http://runtimeterror.com/pages/badsector/gtk12/