Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boden cross-platform framework: Native C++11, native widgets, no JavaScript

github.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#61

Post by dragonwriter »

hak8or wrote: post #60
tom_ wrote: post #40

Earlier quoted context omitted.

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

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.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#62

Post by cheez »

travisgriggs wrote: post #5

“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. :/

Check out a tour of C++.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#63

Post by mwcampbell »

zapzupnz wrote: post #48
tom_ wrote: post #31

Earlier quoted context omitted.

The takeaway here is that each OS trains you in its own way to look down at all those morons using one of the other ones.

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,…

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?

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#64

Post by zapzupnz »

mwcampbell wrote: post #63
zapzupnz wrote: post #48

Earlier quoted context omitted.

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,…

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.

Proper Cocoa apps always win.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#65

Post by Teknoman117 »

O_H_E wrote: post #59
Teknoman117 wrote: post #12

GPL means its pretty much unusable...

Shouldn't LGPL be used here?

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.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#66

Post by nitwit005 »

Signez wrote: post #2

> 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 (Tw…

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.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#67

Post by gmueckl »

hak8or wrote: post #60
tom_ wrote: post #40

Earlier quoted context omitted.

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.

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.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#68

Post by gmueckl »

rhodysurf wrote: post #36
YetAnotherNick wrote: post #32

Earlier quoted context omitted.

Is there any reason why you don't want to publish your changes to the library?

Maybe I mis-understand... If I make an app with this, with no modifications don't I have to mark my code as GPL as well?

Yes. This is the core of the copyleft idea.

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#69

Post by zzo38computer »

fermienrico wrote: post #56
jnbiche wrote: post #54

Earlier quoted context omitted.

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 w…

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 t…

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.)

[1] http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMone... [2] http://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomain...

Re: Boden cross-platform framework: Native C++11, native widgets, no JavaScript

#70

Post by tokyodude »

zapzupnz wrote: post #49
saagarjha wrote: post #30

Earlier quoted context omitted.

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 notice this most when playing games and I can't get context menus to show up with long presses.

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.
Post reply on HN