Boden – Native mobile cross-platform applications(boden.io)
boden.io
Boden – Native mobile cross-platform applications
https://www.boden.io/
133 comments
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.
From the FAQ:
> Finally, there will be a commercial licensing option for everyone who cannot or does not want to comply with the GPL.
> Finally, there will be a commercial licensing option for everyone who cannot or does not want to comply with the GPL.
Thanks for the insight. I hope they can make it happen easy and with a reasonable price I will get it.
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/questions/459833/which-open-source...
https://roadfiresoftware.com/2013/08/the-problem-with-using-...
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/questions/459833/which-open-source...
https://roadfiresoftware.com/2013/08/the-problem-with-using-...
Please take the following with a grain of salt. I am not a legal expert, but we have competent US lawyers assessing this for us right now.
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.
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.
I think LGPL is really more reasonable than the GPL as VLC case did.
Also you could follow the JUCE library model they got their free version and the pay version with a very attractive payment model.
I like JUCE but the components for mobile still not native l&f, Boden looks very promise with clean code using c++17.
But please keep a reasonable price for developers that make free apps and easy to pay.
Also if you could get a Rust version that it will change everything :)
Also you could follow the JUCE library model they got their free version and the pay version with a very attractive payment model.
I like JUCE but the components for mobile still not native l&f, Boden looks very promise with clean code using c++17.
But please keep a reasonable price for developers that make free apps and easy to pay.
Also if you could get a Rust version that it will change everything :)
Tell me, when your user has downloaded an app and wants to relink it with their custom version of Boden, how do they proceed?
LGPL 2.1 6c - on request, you provide the user with object code they can link against their custom version. Should be enough, if no other terms of the app store get in the way?
(VLC is an example of a well-known program that relicensed to LGPL and now is available in the app store, so clearly it is possible)
(VLC is an example of a well-known program that relicensed to LGPL and now is available in the app store, so clearly it is possible)
And how does the user then get their relinked app onto their phone?
(There are plenty of App Store apps with LGPL code in them. The question is, should they be there? And VLC is not a good example, since presumably, I don't know - but I think all of it is LGPL or in any case, open source. The user can rebuild all of VLC in that example. The situation with Boden is going to be that a an app, probably proprietary, has a Boden library in it.)
(There are plenty of App Store apps with LGPL code in them. The question is, should they be there? And VLC is not a good example, since presumably, I don't know - but I think all of it is LGPL or in any case, open source. The user can rebuild all of VLC in that example. The situation with Boden is going to be that a an app, probably proprietary, has a Boden library in it.)
Isn't the problem of "how do I get the app onto my phone" the same in both cases?
If the app is open source (or at least the source code is accessible), the user would proceed to the source repo, clone it, open the Xcode project and relink to the framework version of their choice.
Others have pointed out how it could work with closed source apps. It's a bit more complicated, but it certainly is possible.
Others have pointed out how it could work with closed source apps. It's a bit more complicated, but it certainly is possible.
It would be prudent to advertise this expectation of the app developer hoping to use the LGPL version. (Whereas with for instance the MPL and other licenses, no such need exists.)
It’s not unreasonable to expect people to buy a commercial licence if they’re releasing to a commercial app store
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.
Probably depends on the reasonable(?) license fee.
If it's a truly free app, why not release your source code?
The GPL is not compatible with Apple's App Store restrictions, so giving away your source code is not sufficient to comply with the GPL.
"The primary problem is that Apple imposes numerous legal restrictions on use and distribution...through the iTunes Store Terms of Service, which is forbidden by section 6 of GPLv2."
https://www.fsf.org/news/2010-05-app-store-compliance
See also https://apple.stackexchange.com/a/59495
There is also a significant difference between giving away free applications and giving away the source code. Both from an internal perspective (the company may want to charge for the product or related products or products on other platforms now or in the future) and an external perspective (the app may require other software for which the company does not have rights to release source code).
"Here's a free loaf of bread."
"Why don't you just give me the bread factory and the farms that supplied the ingredients?"
"The primary problem is that Apple imposes numerous legal restrictions on use and distribution...through the iTunes Store Terms of Service, which is forbidden by section 6 of GPLv2."
https://www.fsf.org/news/2010-05-app-store-compliance
See also https://apple.stackexchange.com/a/59495
There is also a significant difference between giving away free applications and giving away the source code. Both from an internal perspective (the company may want to charge for the product or related products or products on other platforms now or in the future) and an external perspective (the app may require other software for which the company does not have rights to release source code).
"Here's a free loaf of bread."
"Why don't you just give me the bread factory and the farms that supplied the ingredients?"
Maybe because some mega corp will figure out how to offer it as a service, and they'll get nothing for it. I support them defending themselves with a way to maybe make money on it. If they can't eat, they can't update the code.
Then it's not truly free, buy a license. You don't get to eat off the free labor of your framework developers.
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.
The original comment was that this would limit adoption due to licensing restrictions, and I'm not sure how this change helps.
So it's very conceivable that if your app is producing money for you, you don't want to open source the magic as it were - but if you're making money, you shouldn't expect a free ride.
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.
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.
Consider the Mozilla Public License (MPL) [1]. It is copyleft in the sense that modifications to the library must be MPL-licensed as well, but doesn't impose any restrictions on apps merely using the library. This avoids the LGPL’s complicated re-linking requirements which are very hard to fulfill for iOS apps (as mentioned elsewhere in this thread).
[1]: https://www.mozilla.org/en-US/MPL/
[1]: https://www.mozilla.org/en-US/MPL/
Even that makes this a complete nonstarter for almost every one of my clients.
Your clients are unwilling to pay for a commercial licence?
No, my clients are unwilling to build against LGPL software.
Then they can buy a commercial license and need not touch any LGPL software.
Hi! I vote for keep Boden licensed under GPL.
Lets keep Boden FLOSS forever!
Lets keep Boden FLOSS forever!
Why not MIT License?
We have put a lot of effort into investigating and assessing different licensing options. There are two different perspectives on this: the user perspective where MIT of course seems to be among the most attractive ones at first glance. Then, there's the company perspective: what is the business model and how is development going to be sustainable in the long run?
We have come to the conclusion that LGPL is currently the best option to align both of these perspectives and provide the best value in the long run.
If GPL/LGPL isn't sufficient for you, we'll be offering a commercial license with fair terms as an alternative.
We have come to the conclusion that LGPL is currently the best option to align both of these perspectives and provide the best value in the long run.
If GPL/LGPL isn't sufficient for you, we'll be offering a commercial license with fair terms as an alternative.
This seems available under GPL v2. v2 is okay with App Store.
Apple's App Store licensing agreement allows you to distribute GPL v2 software. However, the GPL v2 license does not allow distribution under Apple's licensing terms.
It's possible to have GPL v2-licensed software on the App Store, but it essentially requires relicensing or dual licensing by the copyright holder (which is what they do here with selling a commercial license to distribute).
It's possible to have GPL v2-licensed software on the App Store, but it essentially requires relicensing or dual licensing by the copyright holder (which is what they do here with selling a commercial license to distribute).
VLC was pulled from the App Store due to its license being GPLv2 at the time.
There's a recent episode of the CppCast where the developers of boden.io are interviewed: http://cppcast.com/2019/04/marcus-tobias/
This is awesome but man the licensing sucks.. Sounds like to release on the App Store you have to pay for a commercial license? Even a free app?
Author here. We are aware of the issues with the GPL. We are in the process of adding an LGPL licensing option.
The licensing is likely intended to ensure sustainability
Or even, gasp, profitability for the developers. That's a perfectly reasonable thing for a developer or company to expect.
It would be better, though, if they published pricing and had a self-service purchase process, rather than requiring users to contact them.
It would be better, though, if they published pricing and had a self-service purchase process, rather than requiring users to contact them.
It's a really new project, so they're probably still figuring out what model works best and might want to limit the kind of deal they do - e.g. make sure it fits the client and they can support them with development where necessary. Freely selling licenses and then have unhappy customers that didn't evaluate the current state properly would be problematic.
Perhaps, but it's a bit of a dilemma - a GPL license likely won't allow this to gain enough traction to become sustainable in the first place.
Yes. GPL apps can't go into the app store, because it's terms of use forbid activities that can't be forbidden according to GPL.
I don't quite understand this. The GPL gives the end user the rights to the source, to modify the source and to redistribute the software (modified or otherwise), as long as they make the source available. It doesn't say it has to be available through the exact same mechanism that you received the software in the first place, nor does it say that you have to release your changed software through the same mechanism. IANAL, so I definitely could be wrong, but as long as your GPL software links to the code, eg on Github or somewhere, and provides all of the source including your modifications there, any other restrictions the App Store enforces should be irrelevant to the GPL, right? (Unless the app store says you can't link to external source code, or something, of course)
What am I missing?
What am I missing?
The main difference between GPLv2 and v3 is the prevention of “TiVoization”. The background is that TiVo I believe was using the Linux kernel in their devices, and despite the fact that they were contributing their changes back to the community, they used code signing, or some other technical measure, to prevent end-users from running a custom version of the Linux kernel. So in reaction to this, GPLv3 was released that explicitly prohibits this behavior — that is, there must not be any technical measure preventing the user from using a modified version of the GPL’d software.
On iOS, Apple enforced code signing on all apps, so a user cannot download an app’s source, modify it, and use it on their device. Code signing prevents that, therefore would be a violation of GPL.
On iOS, Apple enforced code signing on all apps, so a user cannot download an app’s source, modify it, and use it on their device. Code signing prevents that, therefore would be a violation of GPL.
> a user cannot download an app’s source, modify it, and use it on their device
But I can do this for open source apps? More specifically (disclaimer: I am not a lawyer, and I don't know if this has been tested in court), I personally don't see the GPL requiring that I be able to modify the exact, signed binary that I was shipped if I can create an equivalent one myself.
But I can do this for open source apps? More specifically (disclaimer: I am not a lawyer, and I don't know if this has been tested in court), I personally don't see the GPL requiring that I be able to modify the exact, signed binary that I was shipped if I can create an equivalent one myself.
> and use it on their device
To use the modified software on your device you have to be a "App Developer" (or whatever Apple calls it), and in the process to becoming one accept the TOS imposed by Apple. So you are only as free to run the modified source as Apple wants you too be.
To use the modified software on your device you have to be a "App Developer" (or whatever Apple calls it), and in the process to becoming one accept the TOS imposed by Apple. So you are only as free to run the modified source as Apple wants you too be.
You don’t need to enroll in the developer program to run code on your own device anymore, only if you want to distribute through the App Store.
You have to refresh it every week or something though, right? At least last time I tried it (two years ago maybe?), the self signed apps needed to be re-signed after a short period of time. Fine for development and testing, not so great for actual real use.
Huh, TIL. Last time I tried was ~2 years ago.
I think the problem is that they need to provide a way for you to sign your own binary such that it will work on the hardware?
Which is entirely possible, no?
It's possible, but they have to actually do it.
But they do? Xcode does this.
I'm not sure if requiring you to buy a Mac meets the requirement. (I don't mean this sarcastically, I really don't know if it does).
You do not need Xcode or a Mac to sign applications.
Ok, so let's assume I was able to build the source and sign it without needing a Mac. Am I then able to run my newly signed program on my iPhone freely? Do I need to get it into the app store? Are there limitations to installing it directly to my phone?
Just trying to figure out where the incompatibility will the GPL is coming from.
Just trying to figure out where the incompatibility will the GPL is coming from.
So it's less about the common good and more about spiting companies (who are just never going to use this v3 code now so nothing was accomplished except wasting dev time on a global scale)
The GPL itself isn't about spiting companies or not, or even getting a particular piece of software more widely used by companies, it's about protecting the user freedoms whenever that software is used by anyone. v3 was developed because companies found an edge-case around one particular freedom with "Tivoization". The AGPL was developed because everyone found out about the edge-case of SaaS. The LGPL versions are there for when you want to compromise on the "infection" bit but not on the user freedoms of your bit.
No one forces people to use v3, and notably the linux kernel will be v2 forever. Market segments have settled against certain licenses, but others don't care. I'm glad developers have choices.
The choice to use a particular variant of the GPL may be an effort to spite companies. Personally I'm looking forward to the next iteration of MS's stewardship of GitHub in the hopes that they add a "buy a license" button so devs can make sure freedoms are protected in the general case but also make money by giving alternate licenses to companies that were never going to contribute anything back anyway but may benefit the common good in some other way.
For what it's worth I'm not entirely sure the grandparent's account on code signing is the issue with GPL on iOS, but I'm not a mobile developer so I'm relying on memory of reading other accounts. My prior belief was that it was simply that the end-to-end process of putting a release build of your app on the app store involves integrating Apple-copyrighted code which they don't want to become infected by the GPL and so they don't allow distributing apps under the GPL. Even though side-loading isn't as easy as Android you can still do it with a developer build, so it can't just be some issue of cloning a GPL repo that's 99.9% shared by an app store app and building and using your version locally...
No one forces people to use v3, and notably the linux kernel will be v2 forever. Market segments have settled against certain licenses, but others don't care. I'm glad developers have choices.
The choice to use a particular variant of the GPL may be an effort to spite companies. Personally I'm looking forward to the next iteration of MS's stewardship of GitHub in the hopes that they add a "buy a license" button so devs can make sure freedoms are protected in the general case but also make money by giving alternate licenses to companies that were never going to contribute anything back anyway but may benefit the common good in some other way.
For what it's worth I'm not entirely sure the grandparent's account on code signing is the issue with GPL on iOS, but I'm not a mobile developer so I'm relying on memory of reading other accounts. My prior belief was that it was simply that the end-to-end process of putting a release build of your app on the app store involves integrating Apple-copyrighted code which they don't want to become infected by the GPL and so they don't allow distributing apps under the GPL. Even though side-loading isn't as easy as Android you can still do it with a developer build, so it can't just be some issue of cloning a GPL repo that's 99.9% shared by an app store app and building and using your version locally...
It depends on what you think is "the common good".
Advocates for GPLv3 say that the common good includes ensuring that everyone has the ability to obtain and modify the source code to everything they run.
However, others say this actually infringes upon the common good, because it artificially prevents technology from developing and being used, by placing too much importance on the role of technology (and the Perfect Software ™) in the quest for human happiness.
I strongly agree with the second group.
Advocates for GPLv3 say that the common good includes ensuring that everyone has the ability to obtain and modify the source code to everything they run.
However, others say this actually infringes upon the common good, because it artificially prevents technology from developing and being used, by placing too much importance on the role of technology (and the Perfect Software ™) in the quest for human happiness.
I strongly agree with the second group.
Prisoner's dilemma imo. The second group only wins out here because other options exists. If everyone was forced to share all software ala GPLv3 with literally no other alternatives then we would see even more and better software everywhere (maybe).
1. That's a big "(maybe)".
2. The other option does already exist, and that can't be ignored or erased.
3. The second group wins out because most people clearly see that technology isn't the limiting factor in human happiness.
2. The other option does already exist, and that can't be ignored or erased.
3. The second group wins out because most people clearly see that technology isn't the limiting factor in human happiness.
[deleted]
You have good points and I guess you are not missing anything but Check the VLC case with the App store term of services, they pulled the app from the Store. It is really hard to deal with Apple. your app could be rejected and not accepted because it uses the GPL on it. Apple folks are scared of GPL.
Apple saying "you can't have GPL on the app store" is different from "you can't have GPL on app store because there are app store license things that conflict with GPL license things". Apple can restrict their store however they want, but I was wondering if the GPL itself is incompatible with the app store license (which is what the comment I replied to sounded like it was saying).
Author here. We didn't expect so much attention and are happy about the feedback! Ask us anything.
With regard to the GPL licensing issues brought up here: We are aware that the GPL is not sufficient and we are in the process of adding an LGPL option. This will allow you to publish apps based on Boden on the iOS app store.
With regard to the GPL licensing issues brought up here: We are aware that the GPL is not sufficient and we are in the process of adding an LGPL option. This will allow you to publish apps based on Boden on the iOS app store.
How will the license enforce that an app using an LGPL version of the library can't be sold? As such LGPL doesn't mean the consuming app has to be free.
Sorry, I should have written "apps conforming to the terms of the LGPL" instead of "free". Of course it's still possible to sell apps based on Boden licensed under LGPL as long as you comply with the license terms.
I fixed the parent comment.
I fixed the parent comment.
Is there then a business model in a commercial license for Boden if a company can use it as LGPL? In general are there many companies who pay for a commercial license to avoid LGPL?
The target audience seems very small. There’s lots of C# shops (Xamarin), and lots of JavaScript shops (React Native, Titanium), but few C++ shops that’d benefit from developing apps.
Maybe I’m wrong but the niche seems too small to be sustainable.
Maybe I’m wrong but the niche seems too small to be sustainable.
Soon there will be Dart shops (Flutter). :)
Altough i really like flutter, i absolitely dont understad why these guys propose dart for it... it's just sad...
Funny you mention that. I primarily work with native mobile development and have grown fond of Flutter. Interestingly, the situation is reversed; shops will adopt Dart because of Flutter.
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.
It looks pretty dead to me.
AdSense team rescued Dart from certain death.
They also used to be heavy GWT users before, a stack now mostly discarded by Google.
AdSense team rescued Dart from certain death.
They also used to be heavy GWT users before, a stack now mostly discarded by Google.
#KotlinFirst
This is different, Its not that c++ that people think from the 90's.
- Boden supports native components for iOS and Android and maybe other platforms in the future. - uses c++17 really clean with powerful abstractions, think all your app in just c++17, no xml or other craps, I want to make my app with just c++17. - no garbage collectors, slowness, pause the world etc - single binary - the fastest programming language in the market.
the list goes on and on.
- Boden supports native components for iOS and Android and maybe other platforms in the future. - uses c++17 really clean with powerful abstractions, think all your app in just c++17, no xml or other craps, I want to make my app with just c++17. - no garbage collectors, slowness, pause the world etc - single binary - the fastest programming language in the market.
the list goes on and on.
[deleted]
From reading the iOS code there is already a number of bugs that will have issue, including but not limited to the iOS handling of text inputs. You won't get events / onchange firing correctly for autocorrections or when Chinese chars compact themselves. Seems like a very cool project anyway, there is a lot you could learn from react-native's approach to native components.
Edit: not to mention no support for text areas, will be interested to see that abstraction :)
Edit: not to mention no support for text areas, will be interested to see that abstraction :)
I didn't look but I suspected such issues the moment they mentioned best practices and std::string in the same paragraph... It seems like it could be a fun project but I wonder who the target audience will be. Maybe they're working with a partner? I'm thinking for others it must be new startups just starting out, since every existing company I've seen that targets both platforms with native apps inevitably seems to split the codebases into iOS and Android sides because the platforms are sufficiently different. And of those companies a subset will have a shared C++ layer where it makes sense, probably with lots of cross platform issues already ironed out such that trying to drop in this would be too risky unless it matures into a really awesome project rather than its current preview release state... Best of luck to them.
It's cool to have options for x-platform development. I think we're at a solid 3 solutions: Boden (C++), Kotlin, and Xamarin (C#). Not to forget Unity and the JS solutions out there...
I am curious to know if this can also target a desktop toolkit such as gtk/qt/tk/wx and so on. I probably wouldn't want to use such an arrangement as a user, but I could see it being very useful as a developer for testing out app functionality without emulation or a separate device.
I also wonder if this will be able to target the puri.sm Librem 5 when that comes out?
I also wonder if this will be able to target the puri.sm Librem 5 when that comes out?
There is already an experimental macOSX port in boden. More desktop support is a future goal. The library is designed to support all types of operating systems.
I don't see anything on camera, GPS, maps, push, etc. Was this implemented?
From what I remember from a podcast with the creators (cppcast I think), it's planned but not yet implemented.
I did not see much, they just have a rudimentary wrapper for instantiating java classes, calling methods and retrieving objects in `bdn::java::wrapper::Class` which itself is a wrapper around JNI.
there is a lot more than that missing.
This is how I think it should be solved: https://github.com/chrismsimpson/Meta
A discussion from 6 months ago: https://news.ycombinator.com/item?id=18570423.
From that thread:
> Yes, I was also wondering why it's necessary to come up with yet another smart pointer, which you need to learn and which is probably not battle tested. - https://news.ycombinator.com/item?id=18586992
Even though on the main website they say:
> No custom containers, smart pointers, or reinvented basics. This allows you to reuse your existing knowledge and focus on what's most important: your app.
> Yes, I was also wondering why it's necessary to come up with yet another smart pointer, which you need to learn and which is probably not battle tested. - https://news.ycombinator.com/item?id=18586992
Even though on the main website they say:
> No custom containers, smart pointers, or reinvented basics. This allows you to reuse your existing knowledge and focus on what's most important: your app.
Author of boden here: We have since moved away from a self written smart pointer and replaced as much as possible with standard C++ classes ( shared_ptr, weak_ptr, std::string etc. )
I want to use C++ less than Java and Swift, especially Swift, I don't see this as catch on because C++ is lower level language.
I don't speak C, but as a long-time web developer, it smells to me to see "Center" capitalized in the flexbox snippet. Why is it different than CSS? How is a developer supposed to understand the capitalization rules?
https://www.boden.io/reference/ui/yoga/layout/
https://www.boden.io/reference/ui/yoga/layout/
In C/C++ a common style is to use camelcase with an initial lower case letter for variable like things and with an initial upper case letter for constant or enumeration like things.
>How is a developer supposed to understand the capitalization rules?
By relying on the compiler to check it?
By relying on the compiler to check it?
While I love C++, I can’t help but see this as the n-th iteration of the noble but impossible pursuit of a cross-platform GUI framework.
Cross-platform GUIs never work. They almost work to the point where managers latch onto the idea because they think it will let them fire half of the engineers, but the end result is always well in the uncanny valley.
Open Gimp on macOS and see what I’m talking about. Or Slack. Or Eclipse. Etc.
Cross-platform GUIs never work. They almost work to the point where managers latch onto the idea because they think it will let them fire half of the engineers, but the end result is always well in the uncanny valley.
Open Gimp on macOS and see what I’m talking about. Or Slack. Or Eclipse. Etc.
I was exciting about trying an C++ IDE again after a few years of working in other languages. I tried VisualStudio for some simple C++ stuff (learning OpenGL with GLFW) and I found compilers and IDEs are still a pretty sluggish experience, all these years later.
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.
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.
> Write your mobile apps in modern C++17 and compile 100% native Android and iOS apps from a single statically typed codebase.
Does this thing work in the same way as flutter? (ie. your own UI framework that looks and feels like the official one?)
Does this thing work in the same way as flutter? (ie. your own UI framework that looks and feels like the official one?)
Not at all, they bind to platform widgets and use a programming language that is one of the building blocks of our industry.
Forget Boden and forget messy C++... use Google backed Flutter framework with Dart.
https://flutter.dev Checkout youtube for presentations.
Build once for iOS, Android, ChromeOS, Web, All desktops.
https://flutter.dev Checkout youtube for presentations.
Build once for iOS, Android, ChromeOS, Web, All desktops.
As the intro page demonstrates, modern C++ isn't really all that messy. I think there's a solid argument that it's a more dependable option than Dart, which isn't really used by anyone other than Google.
Better languages have moved beyond C++. I've developed software for over 20 years. I've use C++ for many of those years. Software languages and tools have evolved past C++.
Imagine the "evolution of man" drawing. C++ is the middle guy not exactly standing upright.
Imagine the "evolution of man" drawing. C++ is the middle guy not exactly standing upright.
An "evolution of man" drawing wouldn't really be accurate because it implies each entry is static in terms of evolution. C++ is very obviously not, and modern C++ is barely recognizable compared to code written years ago.
While I really like Flutter, there should be alternatives for everyone, and that includes people who doesn't like Flutter.
I agree. All should choose their own languages and tools. The more competition in the marketplace the better. Hopefully the one you choose will have long term support, be accepted by industry and developers, deliver on the promised marketing, and have reasonable open source licenses. Anything else?
Any recommendations on good sources for tutorials? Just the flutter dev channel or are there any good 3rd parties?
Awesome! Does anyone know if there is any similar framework for RUST?
First Rust still requires some ergonomic improvements to handle GUI coding in a better way.
Like what? (earnest question)
Handling callbacks without piles of Rc<RefCell<>> 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<RefCell<>> 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 simulating graphs,
You mean adjacency lists? They're a canonical realization of a graph, and a fast one at that.
>having to deal with use-after-free indexes.
What do you mean by this?
>Handling callbacks without piles of Rc<RefCell<>> 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 simulating graphs,
You mean adjacency lists? They're a canonical realization of a graph, and a fast one at that.
>having to deal with use-after-free indexes.
What do you mean by this?
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.
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 don't think Rust has any one answer to a UI problem, since the UI story is basically the wild west right now. Everyone is doing something a little different.
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<RefCell<T>> 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.
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<RefCell<T>> 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.
Catherine is relatively known in the Rust community, hence why I didn't mention anything else.
Here is her keynote talk at Rust Conf 2018.
https://youtu.be/aKLntZcp27M
Here is her keynote talk at Rust Conf 2018.
https://youtu.be/aKLntZcp27M
Ah ok had to skim through the slides a bit, I think you meant to use the phrase "generational indexes" which is why googling didn't help me. This project was more helpful for my understanding:
https://github.com/fitzgen/generational-arena
I'm not sure what your ultimate point was though? You don't have to use anything like that in normal Rust code
https://github.com/fitzgen/generational-arena
I'm not sure what your ultimate point was though? You don't have to use anything like that in normal Rust code
Only if you understand by normal Rust code, CLI apps.
If we are talking about graphical applications, that would be a common usage.
If we are talking about graphical applications, that would be a common usage.
> 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 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.
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.
I'm definitely no GUI framework expert, but I didn't necessarily mean to imply an immediate mode architecture. Personally I've been writing a lot of code that way in retained mode frameworks. There's some duplication of data but it's not a huge deal when a widget's state is just single variant, which covers just about all I need.
>> 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.
That's how delphi does it. Connect widget to a data source and it will update reactively when data source changes. And data source is accessible without touching the widget. When doing a batch update on data, you can also disable widget updates in order to make rendering faster. It also works both ways, so when data is changed from within the widget, the bound data source will be updated accordingly.
That's how delphi does it. Connect widget to a data source and it will update reactively when data source changes. And data source is accessible without touching the widget. When doing a batch update on data, you can also disable widget updates in order to make rendering faster. It also works both ways, so when data is changed from within the widget, the bound data source will be updated accordingly.
Sadly no. Something like this for Rust would be a game changer. Rust is very nice language I love it. Also I love C++17.
There is not.
A cross-platform c++ framework... why not just use QT?
Qt isn't using native elements, and their mobile support is usable but not really great either (and doesn't appear to be a current priority, which makes a mobile-only project potentially more attractive). I'm not sure I'd use it if I didn't have existing Qt experience or even code to reuse.
Because Qt does not use the native UI toolkit
Native look and feel.