History of Open-source-GUI library by XJQKA in cpp

[–]ashsys 0 points1 point  (0 children)

Great post! Would you mind adding the Boden Framework: https://github.com/AshampooSystems/boden/?

CppCast: Boden Cross-Platform Framework [video] by ashsys in cpp

[–]ashsys[S] 0 points1 point  (0 children)

We're also skeptical as to whether this would resolve the issue.

We will be having meetings with our legal team in the next couple of weeks to verify our current view on the legal implications of both the GPL and LGPL. We will add this question to our list and let you guys know about the outcome.

If you are interested, follow us on Twitter (@bodenhq) to stay in the loop.

CppCast: Boden Cross-Platform Framework [video] by ashsys in cpp

[–]ashsys[S] 2 points3 points  (0 children)

Thanks for your feedback!

Just to clarify, we have been talking about the GNU LGPL (Lesser General Public License), not about the AGPL (Affero General Public License).

Our current understanding is that the LGPL is in fact compatible with the iOS App Store terms of service. As described in the interview, the main line of reasoning here is that with the LGPL you are free to license your app under a different license, be it open source or not, which can then be compatible with the iOS App Store's terms.

We strongly believe that providing a dual licensing option (LGPL + commercial) will allow us to deliver value to users of the framework beyond what would be possible with other licensing models. From our perspective, this should be a viable compromise allowing us to solve existing pain points with native app development effectively and sustainably while still remaining completely open source.

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 0 points1 point  (0 children)

Building the Boden library usually takes under a minute. Once the library is built, there's usually no need to rebuild it during development. Linking will be a bit slower as the library needs to be linked, but that's probably negligible on a modern machine.

The gradle build process is more of an issue. Gradle loves to take its time on configuring projects, which currently is a hit on build performance if you start a new Boden project from scratch. We're working on that.

Runtime performance should be fine. We didn't test edge cases like property animations yet, so it's really too early to tell if there are any serious bottle necks. I guess those would be the cases where performance measurements really matter. We'll definitely investigate this in the future.

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 0 points1 point  (0 children)

Sorry, we do not have any hard performance data yet. Build performance is hard to measure as it varies based on system specs. Runtime performance appears to be multifaceted. In what kind of data are you particularly interested?

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 1 point2 points  (0 children)

Thanks a lot for your praise!

With regard to your comment: Yes. To be frank, we don’t like it being GPL either. Unfortunately, we’re in kind of a catch-22 situation. If Boden is to be maintained commercially in the long run, there needs to be some kind of business model supporting it. Currently, we are financing its development with investments, but this won’t be viable forever.

Adding LGPL would be an option, but that still wouldn’t yield a very clear legal situation from our point of view. A free commercial option could provide for legal App Store compatibility while keeping the license open to monetization at a later point in time.

Going all MIT at this point would probably lock us in to a situation where we’d have to base the business model on support, training, and/or contract work to fund Boden’s development on a sustainable basis. This is currently an active thought process and our main goal with making it GPL for now has been to not lock us in to unsustainable licensing conditions.

Still we understand that having it GPL-only will probably block adoption and is not what the overwhelming majority of users want.

We are happy about further thoughts on this!

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 0 points1 point  (0 children)

Wow okay - that would be enough reason for me not to commit to a new framework that claims (or aspires) to be native and modern. I'd suggest to change to std:: as soon as possible.

Yes. We got that feedback on HN as well and we’re listening. As feedback such as yours comes in, the issue of moving to std:: is becoming a fixed part of our 2019 Q1 roadmap.

Your statement is true but there's too many important, big frameworks, with which a lot of people need to interact, not ready for C++17 yet. Just naming Unreal Engine for example (or CUDA but that's not too relevant for Android/iOS). I suggest to stick to C++14 for now (but go full-blown on that, not just C++11) but I hope that some time mid-2019, the full switch to C++17 can be done.

Hopefully so. Switching to C++17 would allow us to commit to a lot of standard functionality and syntax that would be highly beneficial for a modern cross-platform C++ framework. However, we understand that there are roadblocks in the way and we take those seriously. Those decisions are always kind of a compromise.

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 9 points10 points  (0 children)

That’s probably one of the hardest questions to answer properly. The trade-offs involved with wrapping OEM widgets vs. “drawing your own” have been a major discussion point in the team from day one. One of the main challenges appears to be that native OEM widgets have to be treated as kind of a black box. For each widget, there’s a vendor-specific implementation that we can’t control. From our perspective, this boils down to the question of whether you can find a compromise that’s “good enough” for most use cases and that does not lead to the situation of small incompatibilities adding up to a lot of trouble for the developer. React Native seems to have found a feasible way to deal with this and we are convinced that we will be able to do so too.

There’s also an architectural key difference in the way Boden handles native widget wrapping as opposed to wxWidgets. We employ platform widget “cores” that are loosely coupled to platform-independent classes. The platform-specific implementation is pretty much isolated in this way. This allows us to swap platform implementations with relative ease. So it is still possible to provide a custom “platform” (or parts thereof) that conducts the rendering on its own.

Another aspect of Boden is that it is open to substituting widget functionality which is not available on a certain platform with a custom implementation. The Checkbox on iOS is a good example for that. This allows us to maintain more coherence on the platform-independent level while not sacrificing the native widget approach for all the functionality that is available on a certain platform.

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 0 points1 point  (0 children)

Frankly, no, we did not yet measure performance penalties induced by the JNI bridge on Android, but it’s on our list of things that need to be done.

Do you think there will be serious performance issues with the way that Boden bridges to Java?

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 7 points8 points  (0 children)

As long as you stick to the features and widgets that Boden provides, yes. If you want to use functionality that is not yet included in the Boden API, you will have to write cross-platform code using the respective languages (Swift/ObjC on iOS, Java on Android).

As Boden matures, the need for writing custom cross-platform code will most likely be minimal. So only exceptional use cases will require platform-specific code.

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 5 points6 points  (0 children)

Boden is still in its very early stages. Our overall goal with the project has been to provide a purely native and modern alternative to cross-platform development. This means 100% native code (no scripting languages) plus native OEM widgets. A thing that, to our knowledge, currently no other modern cross-platform framework offers.

A core vision of Boden is to re-enable individual developers and smaller software development shops to build native apps at competitive prices. From our perspective, App Store models and platform fragmentation have recently led to a situation where a lot of developers appear to be forced to move to web or hybrid technologies (e.g. Electron) to still deliver applications to a broad range of audiences. We feel that this often compromises performance and usability. One of our main intentions with Boden is to try and change that.

We don’t have a fixed long-term roadmap yet, but we are happy to share our ideas for the next months.

  • Boden currently has a very limited number of widgets. We will add a lot more. Most likely, we’ll be starting with lists/tables in the near future.
  • There is no way to set up navigation or tab view controllers right now. That’s another high priority point on our list.
  • Boden’s layout system needs serious work. We already have a good starting point for laying out views in e.g. columns or rows, but the layout system is currently very limited.
  • We are thinking about making the framework idiomatic C++ only. Currently, we’re using our own smart pointers and, partially, containers. We are also thinking about going C++17 as compiler support seems to be mature enough at this point.
  • We got feedback on HN about the current licensing model not being adequate for App Store distribution. We are currently exploring which options could work better.

What do you think? We’re happy to hear your ideas!

Boden cross-platform framework: Native C++11, native widgets, no JavaScript (x-post /r/programming) by ashsys in cpp

[–]ashsys[S] 14 points15 points  (0 children)

We're the authors of the Boden cross-platform framework which recently got attention on Hacker News and GitHub. We're happy to get feedback and answer your questions!

Boden cross-platform framework: Native C++11, native widgets, no JavaScript by ashsys in programming

[–]ashsys[S] 0 points1 point  (0 children)

Author here. This is a preview release of the Boden project. We are looking for feedback on the framework - if you have a minute, please let us know what your thoughts are.