91–100 of 134 posts
Earlier quoted context omitted.
Is it reasonable to expect people to buy a commercial license if releasing a free app to a commercial app store? Probably depends on the reasonable(?) license fee.
If it's a truly free app, why not release your source code?
The original comment was that this would limit adoption due to licensing restrictions, and I'm not sure how this change helps.
Earlier quoted context omitted.
Handling callbacks without piles of Rc > to access widget data, or having vectors simulating graphs, the most used data structure for UI widgets, having to deal with use-after-free indexes.
It sounds like you tried to write rust like it's OOP. You're gonna have a bad time if you do that. >Handling callbacks without piles of Rc > to access widget data That's why you don't let widgets hold program state, they should just propagate deltas and display current state. It's a different way of thinking about how UI can work, but imho it has a lot of benefits aside from just speed and safety. >having vectors sim…
My (limited) understanding is that you're describing an immediate mode GUI (as opposed to a retained GUI) and that one isn't strictly better than the other, but rather there are tradeoffs. In either case, I would be a little perturbed if implementing/using a retained mode GUI in Rust was prohibitively difficult even if immediate mode were strictly superior (the language probably shouldn't force such choices). Of course, I'm opining beyond my expertise, so I'm happy to be corrected.
Earlier quoted context omitted.
At least that is what Dart team hopes, after losing support from Chrome and Angular teams.
Except Angular Dart is alive and kicking, no? Powering AdSense at least which is a huge chunk of Google's business if I recall correctly from a Flutter talk by the PM who put some numbers on a slide.
AdSense team rescued Dart from certain death.
They also used to be heavy GWT users before, a stack now mostly discarded by Google.
I suspect Qt people developed QML for this reason: it is hard to beat the experience of instantly running something vs compiling C++ code on each run.
Earlier quoted context omitted.
If it's a truly free app, why not release your source code?
For any number of reasons that the author should be able to decide and not be forced into doing? The original comment was that this would limit adoption due to licensing restrictions, and I'm not sure how this change helps.
However, if you aren't making money, and are still using the work of others, then it's good to contribute back - even if that's just by open sourcing your work for others to learn from and study. It's not required, but neither is it required for this framework to have a free tier, much less a truly free one that helps protect the future of your app.
It looked very promising but GPL for mobile iOS and Android Apps It is impossible, even I release the Apps free it is very difficult to work with GPL on those ecosystems. It is sad because it really looks very cool code.
Boden author here, a bit overwhelmed by the feedback. We are in the process of releasing a new version that will change the license to LGPL / Commercial.
Earlier quoted context omitted.
It sounds like you tried to write rust like it's OOP. You're gonna have a bad time if you do that. >Handling callbacks without piles of Rc > to access widget data That's why you don't let widgets hold program state, they should just propagate deltas and display current state. It's a different way of thinking about how UI can work, but imho it has a lot of benefits aside from just speed and safety. >having vectors sim…
I have experience with plenty of languages, including doing UI programming in Haskell, just to make your point. If Rust answer to typical UI programming patterns is "you are holding it wrong" then don't expect too much uptake by mainstream UI developers. See Catherine's talk about their game engine implementation, regarding use-after-free indexes, and techniques to avoid it, by binding timestamps to indexes.
I didn't mean to imply that, just that when I see people complain about the ergonomics of the language and point to using a bunch of Rc> stuff usually smells funny, it implies to me that you're either trying to use OO or control flow architectures and patterns, where the type system is able to handle the edge cases that you'd need to think about anyway. There are nicer alternatives, especially in terms of data flow architectures.
And I don't know what you mean by "indexes" in this context or which talk you're referring to, do you have any more details or a link? Google isn't finding me anything.
Earlier quoted context omitted.
It sounds like you tried to write rust like it's OOP. You're gonna have a bad time if you do that. >Handling callbacks without piles of Rc > to access widget data That's why you don't let widgets hold program state, they should just propagate deltas and display current state. It's a different way of thinking about how UI can work, but imho it has a lot of benefits aside from just speed and safety. >having vectors sim…
> That's why you don't let widgets hold program state, they should just propagate deltas and display current state. It's a different way of thinking about how UI can work, but imho it has a lot of benefits aside from just speed and safety. My (limited) understanding is that you're describing an immediate mode GUI (as opposed to a retained GUI) and that one isn't strictly better than the other, but rather there are tr…
Earlier quoted context omitted.
Boden author here, a bit overwhelmed by the feedback. We are in the process of releasing a new version that will change the license to LGPL / Commercial.
LGPL has the same problem! Users must be able to relink an application with their own version of the LGPL library. This is impossible for almost all iOS scenarios and only very slightly easier on Android. This is often overlooked. If you want to keep LGPL you can investigate "linking exception", it's used by some GNU libraries if I recall correctly. This has been discussed for a decade: https://stackoverflow.com/ques…
The main issue we see with the GPL is that your app has to be effectively licensed under the GPL too, which makes your app's license incompatible with the iOS App Store's terms of service.
This is apparently not the case with the LGPL. Yes, you will have to provide a way for users to relink your application to another version of Boden. As far as I can see (I am not a lawyer), this can happen outside of the iOS App Store.
Our US lawyers are currently investigating this. As soon as we get a reliable assessment from the legal experts, we'll add an LGPL option to Boden.
It looked very promising but GPL for mobile iOS and Android Apps It is impossible, even I release the Apps free it is very difficult to work with GPL on those ecosystems. It is sad because it really looks very cool code.
Boden author here, a bit overwhelmed by the feedback. We are in the process of releasing a new version that will change the license to LGPL / Commercial.