Boden cross-platform framework: Native C++11, native widgets, no JavaScript
github.com
github.com
bdn::P<bdn::Button> button = bdn::newObj<bdn::Button>();
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.
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.
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);
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?
the example app you get out of the box. it didn't run the dummy tests successfully on either ios or android side (forgot which one).
upgraded to the latest version other issues on the example app.
for me this was already a big no-no. if the tests are failing on the example app.
"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"
The FSF disagrees: https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDyna...
> 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.
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.
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)
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.
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.)
[1] http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMone... [2] http://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomain...
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.
[1] https://www.gesetze-im-internet.de/englisch_urhg/englisch_ur... (Subchapter 2)
* How is view positioning handled? Does Boden only allow for “list” layouts?
* Can I use my own native components?
* Can I call platform APIs?
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.
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?
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.
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
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!".
[0]: https://github.com/ashampoosystems/boden#1-install-xcode
SWT project also does the same in Java Desktop World. But it never really became widely used.
Does something like this exist in Crystal-lang or Nim? Using native widgets to do cross-platform is appealing, but C++ ...?
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.
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.
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.
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.
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.
Proper Cocoa apps always win.
Depends on the app, I find, and how well it's made.
In another thread, you wrote that Xcode is the best IDE you've found for Mac simply because it's native to the Mac. Have you tried Eclipse? Given that Eclipse's SWT widget toolkit is based largely on native widgets, it might be native enough. Then again, the editor is custom, so it may still fall short.
I ask you these questions because I'm interested in the perspective of a Mac user who has apparently learned to make very effective use of multiple Mac accessibility features.
I never liked Eclipse, it always felt extremely non-native to me. Nothing much seems to have changed.
Right from the start, the Eclipse Installer (by Oomph, apparently) is a web app that VoiceOver has difficulty with meaning I have to interact with it using web navigation controls which is a pain when I'm not expecting it.
The rest of the interface was a bit hit and miss. Either VO could read what was on screen, or it thought I was looking at a table that apparently had no elements in it.
Turning VO off and clicking around, still definitely not a native experience, though better than I remember it. Native-handling of text, access to macOS Services… but only in certain parts of the program!
After poking around a bit more, it turns out the only places I could get native handling of text were web views (of which there are many); most text presents non-native controls to deal with things like copying and pasting, precluding the ability to use built-in Services.
Besides that, the way the app is designed was just foreign. Non-native paradigms for presenting information like those tear-off palettes (that turn into weird, full windows when torn off, rather than inspector palette windows; if you click the internal (non-macOS) minimize button on one of these windows, the window itself stays the same size, but the UI inside gets smaller, leaving this huge empty window with nothing in it.
I was curious to see what VO would say about this window. It was just as confused as I was, thinking one of the two remaining on-screen buttons was a checkbox. That's probably how it was implemented internally, but it was certainly not a checkbox. Once I clicked on the internal restore button, the rest of the UI came back, but VO couldn't tell me what it was looking at. I had to Tab around blindly to get to a usable control, and even then, VO couldn't tell me where it was or in what context.
I couldn't actually create a new project because the "Finish" button, when creating a project, didn't seem to do anything, either through VO or using the mouse pointer directly. The button was lit up and coloured as though it were selectable, it just didn't do anything. So I couldn't actually play with the IDE itself, but I knew I was done with it.
The design looks and feels like Windows in the late 90s/early 00s, from the layout of various windows to those weird tear-off sidebar things. I especially despised the tiny icons that all practically looked the same, conceptually blurred together, and I couldn't find a clear way to make them bigger. VO saw each draggable toolbar as separate, making the toolbar at the top unnecessarily difficulty to navigate. Then those same icons infiltrated the global menus, making those a mess to wade through.
I'm a great believer that there is absolutely nothing stopping cross-platform desktop software being a first class citizen on, at the very least, the three main players: Windows, macOS, and Linux. Sadly, Eclipse, like most Java software, thinks it can get away with the last common denominator stuff and force it on other systems. It just makes for a rather unpleasant time, whether VO is on or not. Native widgets don't make up for non-native design patterns.
Sorry for the novel!
As to NVDA, I expect NVDA uses some heuristics to figure out how to read out all the myriad types of interfaces there are on Windows. I remember one app for vision impaired people, I can't remember it's name because I wound up passing on actually buying it, that basically constantly scanned what was on screen and made informed guesses. I'd say VoiceOver probably relies more on well-made apps conforming to system guidelines; if so, it's somewhere between naïve and brilliant, because I personally favour a system where accessibility is a first-class citizen, not an afterthought for which we need to call upon the powers of magic to figure things out.
* 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.
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.
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.
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.
Ignore the generator folder haha
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. :/
And decent date and time management
* 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.