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.
They also seem to have wrapped the STL, which I think is a big no-no. No real reason to relearn something new if there is an established standard. A modern C++ library shouldn't do that.
I am a member of the Boden dev team. The smart pointer system is actually still a topic of discussion in the Boden team as well. It has a couple of nice properties, like the fine grained control bdn::P gives us over the time when an object is actually destructed. For example, these pointers provide an easy way to ensure that destruction of our View objects happens only on the main thread, no matter which thread released the last reference.
But on the other hand, not using the standard constructs definitely has a cost associated with it. We are happy for your feedback on this issue.
Note that we also think about the idea of transforming P and making it a specialization of std::shared_ptr for objects derived from bdn::Base. That would give us the best of both worlds. Feel free to let us know what you think.
Deferring destructors is a suspicious pattern in general - in C++, I generally expect them to not be async and unpredictable like that. What guarantees do you make wrt destruction order? I hope it's not as complicated as finalizers in Java and C#...
The more logical model, to me, would be to have child views owned by parent views, and to only allow ownership-changing calls (i.e. adding or removing a child) from the main thread. That way all you really need is unique_ptr (from parent to children) and raw pointers (from children to parent, and from any observers). Although it would probably still be better to use shared_ptr just so that observers can use weak_ptr, since untangling lifetimes in callbacks can be tricky, and often it's easier to just check if the object is still there.
To give a specific code example, with unique_ptr, the same snippet would be:
_window = std::make_unique<bdn::Window>();
_window->setTitle("AwesomeApp");
auto button = std::make_unique<bdn::Button>();
button->setLabel("Hello World");
// The following *moves* button, such that _window takes ownership over it.
// It can only be called from the main thread.
_window->setContentView(button);
_window->requestAutoSize();
_window->requestCenter();
_window->setVisible(true);
And furthermore, _window wouldn't have to be a pointer at all - it can just be a member of MainViewController.
If you want to go down this road, doing mobile cross-platform native, Xamarin seems much more compelling. It is supported by a very good IDE and has proper licensing for distribution on the app stores. https://visualstudio.microsoft.com/xamarin/
One question though for app developers who are experienced in this field- does anybody know the relative running time of native vs managed code on android? Does it matter at all for ux-heavy code? How does the startup time look?
Author here. We’re still in the process of figuring out what the right open-source licensing model for Boden should be. In the long run, development must be financed by a viable business model as Boden is not a hobby project. We’re considering adding a commercial option later, ending up with a dual GPL/commercial license similar to other projects. We’re happy to hear your thoughts about other licensing options!
I should have been a little clearer than my one line quip. I wasn't trying to say you should give it out for free :). It's just that GPL and LGPL (v3 specifically) are extremely hard or impossible to comply with in the mobile world.
Even if the software author complies with terms and provides full source or in the case of LGPL, enough to relink the app with a modified version of a LGPL'd component, you can't really swap the app for your modified one due to the "protections" in place on Android and iOS.
Personally, I'd suggest taking a look at how Qt does their commercial licensing.
Because you have to license your iOS App as GPL if you want to use this framework. GPL is not compatible with the AppStore terms. They say they plan to dual license with a (free) commercial license in the future...
If you create a program that links with a GPL library, the program as a whole must itself also be GPL - which is not always acceptable. See section 5 of the GPL: https://www.gnu.org/licenses/gpl.html
"You may convey a work based on the Program ... provided that you also meet all of these conditions: ... c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy"
Not always. I believe a common understanding is if it statically links with GPL code, then it spreads to your code. If it dynamically links then your program is not hit with GPL, as the user is able to change the dynamic library with their own. If what you dewxribed were the case, then the Tivoization lawsuit would have went differently instead of GPLv3 coming out.
> I believe a common understanding is if it statically links with GPL code, then it spreads to your code. If it dynamically links then your program is not hit with GPL
> If what you dewxribed were the case, then the Tivoization lawsuit would have went differently instead of GPLv3 coming out.
The anti-Tivoization clause of GPLv3 doesn't deal with a linking issue, it deals with the fact that even if the device maker releases code for modifications under GPLv2, that doesn't let the user modify and replace the code on the device if the device is locked down so as not to accept modified code, and the user hasn't been provided with the appropriate incantations to unlock it.
You are confusing the terms.of the GPL and LGPL. The GPL does require a program linked to a GPL library to be distributed under the GPL as well. This requirement is not in the LGPL. There, you only have to provide the user with the means to exchange the LGPL library with a different, possibly modified one.
Not even. With the anti-tivoization stuff in (L)GPLv3, you still can't comply even with LGPLv3. Even if you provide a way to relink the binary parts of the app, you can't really replace the app with the modified one because of the way apps are deployed to mobile devices.
It's GPL, not LGPL, so your code will also have to be licensed GPL.
Which means that:
1. you can't build proprietary apps with this framework, and;
2. it's almost certain to be rejected by the Apple App Store, since they typically reject GPL-licensed apps. A few might sneak through, but as a matter of policy, Apple rejects GPL apps since the GPL conflicts with Apple's App Store terms. (btw, this problem even exists with LGPL)
I like the spirit of open source but every time I see GPL, I feel like it is an evil license that tries to consume everything it touches - even the stuff it has absolutely no rights for. That is not the spirit of open source.
It has caused ages of headaches, law firms getting rich and unintentional business losses.
How about a license that says "You cannot use it for any commercial use or closed source projects" so then at least it doesn't claim rights to the rest of the source code. GPL goes a notch beyond and claims rights to proprietary code that so that community can enjoy the fruits of labor at the expense of a small set of people developed without anything to return.
Copy-left licenses are overarching evil in my view.
GPL is not meant to prevent commercial uses, as long as the commercial uses are still with GPL.
What I generally do is release source code of my program as public domain, even if it links with GPL libraries (it will be GPL if I am modifying an existing GPL program though), although require that the combination is GPL even though the files that are entirely my own writing will be public domain. To distribute the combination or binaries requires distributing according to GPL. Since public domain software with source code is compatible with GPL, this is probably allowed, as long as the combination with the GPL libraries are GPL. (Since I do not generally release binaries, and rather release them as public domain source code, therefore it is probably allowed.)
I would like to note that it is not possible to put works entirely into the public domain in some jurisdictions.
The only such legislation that I am familiar with, is the German "Urheberrecht". In particular you cannot renounce certain "moral rights" [1] you have to your works.
Since it is not possible to actually put the works into the public domain, this typically means that you retain all rights and license no rights to user. As such you should always include a fallback license, for example Apache or MIT or whatever you feel comfortable with for these jurisdictions.
Boden dev here. Boden currently supports linear layouts (horizontal and vertical). We know that more is needed for a proper UI. Feedback is appreciated - let us know what you would like to see regarding layout options.
Since all widgets are native, you can easily add your own child widgets to the containers. You can gain access to the native view objects via the "View::getCore" method. However, we do not have a good way yet to insert custom widgets into the Boden layout system. That is an area where more work is needed.
Regarding calling platform APIs: since the apps are written in C++ you can call any platform API you like. On Android you can also use the Boden helper classes (bdn::java::JClass, etc.) to make Java calls from C++. On iOS the easiest way is to create an Objective C++ file (.mm file extension). In there you can combine C++ and Objective C code freely.
I'm primarily an iOS developer (though, I've started looking into Android recently), so my point of view will be skewed towards that platform. If you're trying to write an iOS app, you probably want to expose AutoLayout, or at the very least the API provided by UIStackView. Plus, you will need to handle things like the navigation hierarchy, which on iOS does a lot of layout-related things for you.
It is an interesting thought to also use the native layout system on each platform. It might be challenging to provide an abstraction for the native layout that behaves consistently on all platforms, though.
Can you elaborate on why you feel AutoLayout support is needed? If Boden had a layout system of comparable power, would that solve this issue?
> Can you elaborate on why you feel AutoLayout support is needed?
That's simply how most apps are designed these days, since it makes it easy to support the ever-growing list of device sizes that iOS apps need to support.
> If Boden had a layout system of comparable power, would that solve this issue?
Sure, but you might need to keep in mind that iOS developers are used to using AutoLayout and need to learn how to do things in your new layout system.
Why is it that nowadays all kinds of libraries go down the framework path by forcing/encouraging the user to adapt their workflows to use some kind of custom tooling?
I mean look at the readme: Getting Started? Just call "python boden.py new -n AwesomeApp"
Just provide examples in source form with minimal and standard instrumentation (like project files) and leave the rest to the user
I rather like using the custom tooling. It means that if people are following the prescribed procedure, they will always be using the latest version of a project template or some such rather than duplicating a local copy of what might be a hideously out-of-date template.
With Swift, for example, using Swift Package Manager (SPM) to initialise templates means that the syntax in the newly-created project's files is up-to-date, the Package.swift file follows the appropriate naming conventions for whatever version of SPM it is, and it's much more convenient to do `swift init` than to go clone a github repo manually then rename this or that.
It's basically a command-line version of project templates in Visual Studio or whatever, and people generally like those. Sane defaults are nice, but sane defaults with validation are nicer.
Though I agree that it would be nice to just have a blank template available for those who don't want to use the tooling. There should always be a subsection in the Getting Started section that says "clone this repo, and you're good to go. Be sure to clone the repo again when you want to make another project; don't just copy your existing clone!".
Flutter, out of Google is a solution for iOS and Android cross-platform development that includes very fast UI primitives, a edit and continue workflow, intuitive and reactive UI framework, and a nicer high-level language to work with than C++ (Dart).
I think it's written for ReactNative as no javascript is a strange wording. I don't care as much for javascript as that for much less responsive webview.
This would be an unpopular opinion but no-javascript should be a thing everywhere excluding browsers. And hopefully with webasm, it can be a thing on web too
Yes exactly. If you look at the code, it basically is just using pure virtual provider classes to allow JNI on android and OBJC++ on iOS to provide the native system UI components. Its pretty elegant actually.
The only problem becomes that it is a lot of code to manually maintain or bootstrap. And possibly a decent amount of effort to add new platform widgets, but I didn't look very deeply into how exactly that would be done.
> Native widgets: Instead of drawing widgets that look nearly identical to the platform's design, Boden uses native OEM widgets ensuring that your app will always have a truly native look and feel.
While I fully understand the underlying concept, I don’t understand why so many people seems to be bothered by that anymore; I used to care about that as an Android user, but most of the apps I use everyday on my phone (Twitter, Inbox, Slack, Youtube, even Google Photos or Maps) do not seems to use the pure platform widgets anyway.
Native widgets don't just mean "look". They can also mean "feel". This is particularly true on macOS.
On macOS, I expect certain widgets in order to accomplish certain tasks. I expect that they will respond to mouseover and button presses in a certain way. I expect to be able to use certain key combinations to cause certain widgets to do certain things, I expect keyboard combinations to be able to be redefined in System Preferences.
On the accessibility front, I expect VoiceOver to be able to read what's on screen, I expect it to be able to tell me what a widget's behaviour will be, I expect to be able to get back to where I was using a standard key combo, I expect images to respect colour inversion settings, I expect text to scale according to the system's Dynamic Type settings.
When it comes to handling text; I expect fonts to have the system's native rendering; I expect that Unicode support is complete, I expect macOS' emoji picker to show up; I expect system-wide text replacements, smart quotes, and orthography checking to work as expected, I expect selectable text to show a list of system-wide Services in the context menu, I expect all text to be draggable and handled correctly by the receiver of the drag action.
There are plenty of other things that I can't think of, but this list could get quite long. Suffice to say, Apple put a lot of default behaviours into Cocoa, and apps that (A) don't use Cocoa, or (B) only use Cocoa for drawing but not inheriting behaviours, they don't just look a bit off, they feel _wrong_.
I think we may be immune to this to some extent on mobile, and Windows users haven't known anything other than complete inconsistency, even with Microsoft's own built-in interfaces. But for some of us, if the interface feels wrong, the app goes straight into the Trash.
Cocoa Touch, while being slightly simpler and less arcane than Cocoa, still has a lot of semi-hidden behaviors that are nonobvious to cross-platform UI framework implementers.
I'm trying to find an example of this "long press shows context menu". Tried long pressing a link in Safari Mac no context menu appears. Ctrl-Click brings up context menu. Tried long pressing a shortcut, no context menu but ctrl-click brings up context menu. Tried selecting and long clicking a file in Finder. No context menu appears but ctrl-click brings up context menu. Tried selecting some text in TextEdit and long pressing, No luck. Ctrl-Click brings up context menu. Tried long pressing a tab in the ruler, same issue. It seems like even for Apple this isn't much of a standard.
The person to whom I was replying was talking about Cocoa Touch, so this was about iOS, not macOS. If it interests anybody, the specific example was Pokémon Go's text fields which _do_ respond to Cmd-V, but I can't long press to get Copy|Paste to show up.
I don't see that at all. Rather, each OS has its benefits, and if the person who designs a toolkit doesn't account for them, you wind up with something middling and foreign that takes advantage of nothing.
For able users, that can come down to minor irritations. For users with special accessibility requirements, that's downright unacceptable.
If my listing of all the features of macOS might have come off as haughty, it's simply because I'm one of the ones who has special accessibility requirements, and the way macOS does things suits me well. Apps that don't use Cocoa, therefore, can really screw me over.
In your experience, how do web applications compare to native Mac apps? Of course, a web app can be accessible with both VoiceOver and magnification (based on all the features you listed, I'm guessing you're low-vision). But are even the most accessible web applications noticeably less efficient for you than native Cocoa apps?
You're correct, I have low vision. Enough to code and read relatively comfortably, but not for long; so I either make the text enormous or turn on VoiceOver. Below, I'm talking about macOS; I don't use VoiceOver on iOS.
I tend to find with web apps that they're pretty inaccessible with VoiceOver, depending on what they were made with. If it's Electron or React Native, unusable. I just make the text huge. No good for blind users who shouldn't be left out of the fun, but mightn't even be able to find the voice chat controls.
Even when I'm not using VoiceOver, web apps tend not to respect system accessibility settings like text size. When they have them built into the apps as a setting, that's nice but rarely the case. It would still be better to respect my accessibility preferences; I don't go to all the trouble of setting them up for nothing. It's also not like Apple's accessibility APIs have changed drastically over the years, they're pretty stable. I imagine this to be the same for Windows.
In websites, it's usually a different matter, sometimes a bit better. In general, the web version (that is, in a browser) version of a web app is usable to a greater extent, though that doesn't necessarily mean anything, because VoiceOver knows how to inspect the DOM — whereas it isn't expecting that at all with 'native' web apps.
Author here. The goal of Boden is very much that the applications should look and feel as if they were custom-coded for the specific platform. We also think that custom widgets often fall slightly short of the native feel, as other commenters have pointed out. While it is certainly possible to make them 100% consistent with other native apps on the platform, it is a lot of work to get all the details right. And not all frameworks manage to do that.
We wanted to try a different approach. Why not just use what the platform gives you and always get the right look & feel out of the box? That certainly creates its own challenges, like having to provide a good abstraction layer for the core application code. But you do not have to worry about look, feel, drawing performance, interactions with other OS features and the like. And when the OS changes something then the app is automatically up-to-date.
There are so many hidden behaviors in native widgets that once you get accustomed to, you can't go back any more. Here are a few of the ones:
* Right click the document icon on the title bar to reveal a menu bar for ancestor directories
* Drag the document icon into things like an email client as an attachment
* Support Emacs-style text editing shortcuts such as C-a C-e C-k everywhere, as well as user-defined ones (I added a bunch of other Emacs ones like M-f)
* Trackpad shortcuts such as three finger press on a word to show dictionary and thesaurus
* Drag and drop selected text to move it
* Hold option while selecting text for rectangular selection
There are many others. I get upset if something doesn't work when I know it should work if the app developer is using native controls.
I might be totally off base here, but I get the sense that native widgets have become a skeuomorph for following the common UX conventions of the platform you're running on, with the latter being what brings the real value. The equivalent conventions for web apps and their desktop derivatives are much looser and don't yield as much consistency on which to build effective user expectations and habits. People who experienced the shift can tell something is missing, and the most obvious correlate is the disappearance of native widgets.
I think he means "things tend to either with follow conventions and use native widgets, or they do neither". Users can internalize that dichotomy, and recognize that as soon as they don't see native widgets they probably aren't getting platform conventions either.
Especially when Google itself is promoting Flutter which in a way is a non-native UI framework. I think as long as a framework is performant and implements well the design guidelines of the OS this is what really matters
Except that Flutter is pretty bad on anything that isn’t Android. The “Cupertino” theme needs significant work; it’s significantly worse than even Ionic is.
I don't call that a defence when it's already out in the wild, and people are already talking about it like it's "good enough" when we are already able to use its version number as justification when it's clearly not.
It's often necessary to make all the native accessibility stuff work.
Sometimes new features come out which will immediately work well with native components, but which require a lot of reworking to work well with something custom. High DPI support is often an example of this.
You could make this exact same framework with rust as the backend instead of C++. I have made a proof of concept MVVM app in rust for iOS and Android.
Instead of binding view models and state you bind the entire platform with bindings for every widget and control. Its not too much work but it is a lot of boring code to write and maintain.
“Boden is written in modern C++11 to make development easy...”
They lost me there. I admit I haven’t done any true C++ in the last few years, bowing at the height of Boost. So I’m curious, did I miss something in the next chapter of “modern” or perhaps the “11” that suddenly made C++ development “easy”?? It was quite capable for sure, but easy, no. Honestly curious. Maybe I’m just not a good enough developer. :/
Yes, it's a way better language than it used to be.
* They added smart pointers that actually work. (std::unique_ptr and std::smart_ptr) Invoking delete is considered a code smell in C++11, and new is considered a code smell in C++14. (because of make_unique and make_shared, added in C++14)
* Dynamic polymorphism (via inheritance) has gone out of style. These days it's templates all the way down, which aren't terrible anymore for a wide variety of reasons that I don't have time to go into.
* Threads and safe locking mechanisms are now actually standardized, so you don't have to use boost::thread. std::async, lambdas, and std::future provide reasonable syntactic sugar around threading, as opposed to manually mucking around with your own thread pool.
* Stuff that used to require library writers to dig around in the bowels of template metaprogramming became a lot easier with `if constexpr` in C++17. Actually that's one of the reasons why templates aren't terrible anymore, sorry for going into it when I said I wouldn't.
Idiomatic C++17 code feels like a completely different language than C++03. Ye olden C++ felt like Java with spike traps and no garbage collector, but idiomatic C++17 feels like... I dunno, Rust without the borrow checker and everything is in an unsafe block. (I'm trying to think of a better example)
(as an aside, there are two different things called "modern c++". I'm pretty sure it's a joke, but it's a terrible one. There's Andrei Alexandrescu's 2001 book Modern C++, and there is are the coding practices that evolved out of the development of C++11/14/17.)
Source: I maintain a ye olden C++ codebase at work, and write modern C++17 in my personal projects. The degree to which they differ is profound. I'm not doing the difference justice.
C++11 is old now, C++17 is the latest version which is pretty awesome. It is a serious undertaking just getting packages linked on a platform like windows. I took a short detour into golang, that was a few months ago; C++20 promises package management via modules instead of the old include system, all the c++ compiler vendors are working on it right now. Until then, i'll stick with go.