> 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.
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.
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.
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.
I find native apps frustrating that they won't let me select what I want, only what they want to allow me to select, where as in a web page I can generally select whatever I want.
This is true for web pages, but not necessarily true for native web apps (like Discord, VS Code, etc.) where certain UI elements are just as inaccessible as in native Cocoa apps; sometimes you can get to them by enabling a web inspector (if it's possible), but not always.
Depends on the app, I find, and how well it's made.
Interesting. Based on your description, it seems that NVDA on Windows fares better with Electron apps than does VoiceOver on Mac. NVDA's "browse mode" features work equally well whether it's Electron, Chrome, or Firefox (and to a lesser extent in IE and Edge).
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 had to install Java and Eclipse to give it a try just to reply to this comment.
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.
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.
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.
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.
“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. :/
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.
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.
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
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.
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...
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.
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.
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.
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.
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.
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?
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.
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).
97 comments
[ 4.2 ms ] story [ 188 ms ] threadWhile 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.
[0]: https://github.com/ashampoosystems/boden#1-install-xcode
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.
"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.
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.
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.
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
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.
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:
And furthermore, _window wouldn't have to be a pointer at all - it can just be a member of MainViewController.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!".
Does something like this exist in Crystal-lang or Nim? Using native widgets to do cross-platform is appealing, but C++ ...?
SWT project also does the same in Java Desktop World. But it never really became widely used.