CppCast - Boden Cross-Platform Framework

Episode Date: April 4, 2019

Rob and Jason are joined by Marcus Tillmanns and Tobias Lensing to talk about the Boden Cross-Platform Framework. Marcus is currently the main software developer of Boden. He has a strong background in C++ graphics and UI development. He worked with Qt for more than 10 years on audio software and embedded projects. Tobias is currently working as a software developer and product manager on Boden. He’s passionate about start-ups and entrepreneurship. Tobias also has a background as CTO in audio software, cloud technology, and web development. News Visual Studio 2019 goes live C++23 fullptr to replace nullptr Conan 1.14 Release Marcus Tillmanns @Maddimax3 Tobias Lensing @tobiaslensing Links Boden @bodenhq Sponsors Backtrace Announcing Visual Studio Extension - Integrated Crash Reporting in 5 Minutes Hosts @robwirving @lefticus

Thank you. Windows, mobile, and gaming platforms. Check out their new Visual Studio extension for C++ and claim your free trial at backtrace.io. In this episode, we discuss some April Fool's jokes. Then we'll talk to Marcus Tillmans and Tobias Lensing. Marcus and Toby talk to us about the Bowdoin cross-platform framework. Welcome to episode 193 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm all right. How are you doing, Rob? I've had better days. We're getting hit by some pollen here, and I'm adjusting to it.

Yeah. Yeah. Yeah. Yeah, and also, I mean, spring is springing, I guess. Yeah, we went from low 50s yesterday to upper 60s today. I think it's finally going to stay this way, though. Yeah, we've gone back and forth between blizzard, sunny, snow, sunny. Today's going to be cool. Tomorrow's going to be hot again. Well, hot by the standards of the time, right?

Like 68 or something. Yeah, I think that's what we're at today. But hopefully, we'll start maintaining it here in North Carolina. Right. Okay, at the top of our episode, I'd like to read a piece of feedback. This week we got a tweet from Aditya Srikumar.

Hopefully I'm pronouncing that right. Probably not. Probably not. And they're saying, why do so few IDEs have easy support for building and debugging within a docker container vs code was the best option so far uh and considering c line and eclipse as alternatives and they're saying cpp cast would be great to get other perspectives um i had heard about vs code being good for docker debugging because I saw this blog on the Visual C++ blog a couple weeks ago

where I think it was Mark Goodner went through how to set it up to debug onto a Docker container. But I don't know about any other IDs and good support for Docker. Do you, Jason? No, I've never even considered it. The thought of needing to debug in docker has literally never crossed my mind okay well if you're listening to this and you have uh you know had a good setup with docker and any you know c++ ide feel free to tweet at us or send us a message so we can get those

listeners some help yeah i mean it gives me flashbacks of having to do debugging on remote embedded devices. It's probably the same set of problems, really. Yeah, I don't think so. Okay, well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or emails at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Marcus Tillmans and Tobias Lensing. Marcus is currently the main software developer of Bowden. He has a strong background in C++ graphics and UI development.

He worked with Qt for more than 10 years on audio software and embedded projects. And Tobias is currently working as a software developer and product manager on Bowden. He's passionate about startups and entrepreneurship. Tobias has a background as CTO in audio software, cloud technology, and web development. Guys, welcome to the show. Thanks for having us. Yeah, thanks. Wow.

So you spent 10 years working with Qt, not working on Qt. Is that correct? That's correct, yes. I am definitely going to ask more questions about that later when we're talking about Bowden. Yeah. Please feel free and uh just so we our listeners know who's speaking uh can you both like say your own names you know

i'm toby and i'm marcus okay great uh yeah so we have a couple news articles to discuss uh feel free to comment on any of these and then we'll start talking more about Bowden. Okay? Great. Okay, so first, obviously I talked a lot about this two episodes ago when I was out in Redmond talking to the Visual C++ team, but Visual Studio 2019 officially went live yesterday on April 2nd. You can now go and download it and check out all the new features, and there are several new things for c++ developers which is great i find this interesting that the ars article says you know with this world of rolling releases why do they even bother giving it a new version number it does

make you wonder like is there going to be a day where they just have it like be you know visual studio x or something like that and it just becomes the Visual Studio for the rest of time that they just continually update. Yeah. I get it because I do a lot of training at companies, right? And companies, they look for a number, right? Well, we need to spend the effort to upgrade to this new thing now. Yeah.

And I don't know. I feel like that could swing either way. My gut would be that most companies, if from here on out, Microsoft never gave a new version number, they just patched it, they'd be like, well, we can't move past 2017 because 2019 is just too unstable for us. Or something like that. Right, and I guess it's worth mentioning,

Microsoft has done that model themselves with Windows 10. I mean, they're saying Windows 10 is going to be it forever, and they're just going to keep updating it. Yeah. The one thing worth pointing out is they did this with Visual Studio 2017, where if you wanted to upgrade, but for some reason couldn't update your compiler,

then you could switch to 2017 and still use the 2015 C++ compiler so they did that again so if you're using want to upgrade to 2019 but still need either the 15 or 17 compiler you can do so um i don't know how long they'll keep that going before they introduce a breaking change and need you know someone to actually upgrade and use the new compiler in order to use the new IDE. I don't know. No idea. Yeah. Are you guys Visual Studio users? Well, we have to sometimes, but not really.

I used Visual Studio a lot, but that's a long time ago. And I guess for Bowden, yes, we use it. But at the moment, we are only focusing on Android and iOS, so that's not really a visual studio job so um no currently not really in you um me neither um in my previous work um we had people working with visual studio we already did cross platform back then on mac and windows and embedded stuff um but we've like I would say most of our people switched away from Visual Studio at some point. Yeah, and I remember

in the beginning of Bowden, we tried a lot and had a lot of issues with different compiler bugs. And moving from Visual C++ 2015 to 2017 was rework.

We had to change a lot of things. I guess at the moment we are quite enjoying that we can work with Clang across platforms because we don't have to take care of so many different details. Right. But I guess that's the reason why they are supporting the old compiler in the new version. Yeah. Yeah.

Okay, so earlier this week it was April Fool's Day. I wasn't paying too much attention to April Fool's, but we do have one article here that was an April Fool's joke. C++23 full pointer to replace null pointer. Yeah. I did not fall for this one, but it sounds like some of the people in the comments did, though. Yeah. I must admit I fell for it like halfway through the article,

and then I was like, no, this cannot be true. I liked the Reddit comment saying that some guy was saying that he was missing a std half pointer for 16 bits use cases. I didn't fall for it because I didn't expect anything to be true on April 1st, basically. So everything I read, I assumed, was a made-up story, even the serious stuff going on. But there's actually, I'm reading this, I'm looking at it, and I think there is almost an argument for this. And that is the embedded users who complain that

zero is a valid memory address on some devices. Oh, okay. But on the other hand, actually using this would be impossible. How would you ever check for null, really right or check for an invalid pointer i like all the uh fake quotes from everyone about how great full pointer is going to be yeah so i assume this was intentional but the first one is quoting bjarne struestrup that is not bjarne that's not an older picture of bjarne oh no confused about that okay that is definitely not i i looked i actually looked at the file name to see who it was that's james gosling okay uh gosling that is that this is the creator who's

he was involved in what java am i getting that right oh that's pretty fun i'm gonna get in trouble real bad aren't i james gosling who Who is that? Who is James Gosling? Come on, someone. I basically don't know. Designer behind Java programming language. Beyond Java. Okay, good. I don't lose my geek card on that one. So that part was not an April Fool, probably.

I don't, yeah. Were there any other particularly good April Fool's jokes that either of you saw the other day? I wasn't paying too much attention to anything. I did see that Microsoft made some decision to not allow any company-level April Fool's jokes. I wonder if other tech companies might follow suit in future years. My favorite April Fool's joke was actually a tech video where they showed how to liquid cool your PC with cement. They made it look like it actually worked, but of course it wasn't.

Pretty funny. That's kind of awesome. And then I'm like, well, I mean, concrete is, I don't know, what would that actually do? It seems like it would run for a few minutes, right? Supposedly it has very good heat capacity and stuff like that. Right, yeah. That's what I'm thinking. Hmm. I'll have to try that. I'll dump some concrete in my case after this. Sure.

My brand new Ryzen build. Okay, and then the last article we have is uh update to conan and this also actually came out on april fools but as far as i can tell there's no april fools jokes uh within this uh release notes article um it looks like the big change they made with conan 114 is revisions you can now uh set set revisions when you're uploading a new recipe. Yeah, that could be handy. Yeah. Are you still using Conan a lot, Jason? I spent a lot of time with it in the last couple of weeks, actually, for a client.

Some of these things I find, like the CMakeFindPackageMulti, I have read it a couple times now, and I still don't see how it really differs from what we are already doing with multi-generators for Visual Studio, but I'm going to have to spend some time with that and figure that out. That might be helpful to us, and I'm definitely interested in some of these things, but I'm totally

a newbie at actually creating and deploying my own packages. Right, okay. Are you deploying KaiScript using Conan or anything like that? No, no, okay. Are you deploying, like, ChaiScript using Conan or anything like that? No, no, no, this is all, well, I guess there's no harm in saying it's for custom Ruby builds

that are needed for an embedded Ruby in the project that I'm working on that's open source. Interesting, okay. Which, for everyone listening, never embed Ruby in your C++ project. This has been like 10 years of pain on this project, and I'm not exaggerating.

It's never straightforward, and particularly if you need to support multiple platforms and multiple compilers. Okay, that's good to know. It's not designed for it. Use Sol2. Talk to the phd something yeah all right uh so marcus and tobias you want to tell us about the boden cross-platform framework we talked about it i guess late last year in a news article when we we saw something about it but

uh you know once you uh tell listeners more about it? Yeah, so Boden is our framework project. We've been developing on it for quite some time now, and it's aiming to be an application framework, and right now it's specifically for mobile applications on iOS and Android to allow you to write C++ applications and compile them both for iOS and Android. Is it a project that you are working on full-time? Yes.

Yeah. Okay. It's a full-time project and it's funded by a company we work for. Oh, okay. So the company you work for, are you already making production-level iOS and Android apps using Vodun, or are you just working on the framework? Not yet. The framework is not advanced enough right now

to really get a production-ready iOS and Android app out there, but I guess we are pretty near it's not we will definitely be uh be there in in 2019 so um it's it's quite advanced but it's not uh it's not readily usable to um all the deployment stuff basically is missing and we are working on a lot of details still. But one of the first projects internally is to get one of the apps that the company needs built with Bohn, yes. Okay, so I guess, I mean, you've kind of already said this, but let's just clarify,

what platforms are supported at the moment? Currently, Android and iOS only. Okay. Do you have minimum versions required for those platforms? Yeah, with iOS, we're right now just targeting 12.x. Okay. And with

Android, it's the last one that they released. I can't remember the name. Version 28 was it? Okay, so Android and iOS, and are you restricted to developing on a Mac? Because I believe that's a requirement when making an iOS application. Is that right?

For iOS, you are restricted to Mac right now, and for Android, you can use Mac, Linux, or Windows. Yeah, but at the moment, it's basically just for debugging and testing. It's perfectly fine and possible to just develop on Windows or Linux using Android Studio or even Qt Creator, and then just do the compile, test, debug step on a Mac. Okay. Okay.

I'm still waiting for the day when I can compile and deploy my iOS app on Windows or Linux.. Okay. Okay. I'm still waiting for the day when I can compile and deploy my iOS app on windows or Linux. I don't care. That would be nice. Just not Mac OS. Yeah. And I guess that's one of the biggest challenges we are facing because it

would actually be pretty nice to make it as easy as possible for developers to just do that because it's a constant hassle. You have to have all those devices, you have to have the time to build it, and it's really annoying. Yeah. Right. So maybe we should talk a little bit about

what is different about Bowden compared to some of the other cross-platform frameworks. So my understanding is this isn't necessarily aimed at a game developer. It's aimed at someone making apps. Not games, but apps where you would have buttons and text boxes and lists and that sort of thing. And you're using the actual platform user controls as opposed to making your own the way Qt does.

Is that right? Yeah, that's correct. Our goal is to give you the native look and feel of an iOS or Android app cross-platform, so to speak, so that if you write an app once on iOS, it behaves like

an iOS app is supposed to behave, and on Android, it behaves as it's supposed to be on an Android device. Yeah, so it's kind of like React Native without the JavaScript part. That is... I think that's a good comparison.

Or like Xamarin Forms, which is a C Sharp, right? Yeah, Xamarin probably draws its own stuff. I guess it can do native widgets. I guess it can do native widgets. Okay. I'm not sure. Yeah.

I think it can do native widgets. It doesn't do it everywhere, but it can do it. Yeah. And, I mean, compared to all other frameworks out there, basically, that are in use these days, except for Qt, of course, would be the focus on C++. Right. I find your decision to use the native widgets fascinating since you have 10 years of experience with Qt,

and that's one of the distinct things that they don't do is use native widgets. Yeah, and I mean, you see it all the time. A new version of macOS comes out, and you have to wait and hope for a new version of Qt until their rendering methods have caught up with whatever theme changes Mac OS has implemented. And that's the awesome thing with Bowden. You don't have to wait. And especially there are cases in Mujavid, for instance, where they switched to having the dark mode,

where you had to recompile your application for it to be able to do dark mode. But that was all you had to do. You just recompile it once and you get all the new features of the operating system. And you don't have to wait for us, so to speak, to reimplement them. And that gives us a tremendous edge when it comes to being native. Yeah, and also I think most of the frameworks trying to render their own stuff, they always fail at some level of detail. It's just a question of how far into the detail you need to go. So, for example, especially on mobile devices, the feel of gestures and how it behaves and how it animates, that's quite hard to match with a non-native renderer.

And a lot of work goes into that. So that is also a reason why we decided to do that, because it's just a shorter time to life. I guess it's just easier for us to get a broad range of controls and everything finished in the framework before we have to even consider writing a renderer and writing input protocols and everything that's needed i mean it gets it gets quite nasty if you go into text input and the details of that, and you quite quickly reach that point. Right. So we basically don't have to care about that.

Yes. Yeah, you have to. I mean, it's not only rendering. It's also getting user input into the application, and that requires that you have all the details ready for typing stuff on a virtual keyboard and so on and that's quite nasty to implement if you don't use the native controls of the platform So

does that limit you in some way because you're stuck to the intersection of all the features between the Qt and Android and iOS Sure, we have to the flip side is that we have to make features between the Qt and sorry, not Qt, Android and iOS? Sure, we have to, the flip side is that we have to make

more sure that everything works the same on both platforms. I wouldn't necessarily say limit. I think so far we haven't found an edge case that was only possible on Android or only possible on iOS, but it's definitely a little bit more work

and there has to be more care taken to make it work the same on both platforms. Yeah, there was one case where we weren't sure about implementing lists and table views, basically, because that is something that, I guess, React Native, for example, there it just stops being native it it as far as i know they just draw the um the virtualization of the list and the handling of the list items and everything that's just basically custom code because that's easier to translate between between. And we decided that we didn't want to do that.

And actually, we succeeded with it. So we were able to tweak the layout system that we use in a way that we can support native list controls on the platform. So on Android, it's really list view. And on iOS, it's really the native UI table view that's being used to render list items, which are then, again, layouted by our custom layout system. So that was one of the major challenges. And that is, I think, a good example for your question, to answer your question, because that's pretty much the trouble you run into with that. So I'm curious how this ultimately looks.

Like, are you having to call? I don't really know what the APIs look like, but, I mean, are you having to talk to Objective-C++ on one side and Java on the other side, basically? Yeah, exactly. Correct, yeah. Okay. Do you have anything that...

I'm sorry, go ahead. Yeah, we have technology. We build technology to make it easy for us to rep, especially the Java side. Objective-C isn't that hard because you can just call it from C++. But we have a nice library to get the translation between JNI and C++ done.

Okay. Is it one you've custom written? Well, it's basically a thin C++ template layer on top of JNI. That just makes it easy to say, let's say you want to call the function that takes a string, a Java string, and then we can just write an object that takes a std string, and internally it automatically converts it into a JNI string and these kinds of things. Yeah, we are pretty much working on automating most of that stuff because it's just repeating work, which is pretty much the same always.

But it's basically wrapping the Android API in C++, in a thin C++ wrapper, yes. All right. Okay. Are you creating the user interface at runtime or during the compilation process, Are you creating the user interface at runtime, or during the compilation process, does it create the Java or iOS user interface?

No, it's completely runtime. So you just write the C++ code, and everything else happens at runtime? I was wondering if you're planning to support any other devices outside of iOS and Android, any desktop or anything like that? We definitely want to at some point, but right now we are limiting ourselves to mobile to get that right. But if you look into the sources, there is an unofficial Mac port already that I like to use for development because it's a little bit easier. You don't have to have the simulator running

and these kinds of things. And so we kind of, it's not, it's nowhere near as polished as the iOS and Android ports though. Yeah, I guess one of the next logical steps is to support Mac as we already have it more or less

and Windows Universal Platform. That would be the next. No, I'm sorry. Go ahead. I was basically... Oh, you're done. Okay. we already have it more or less and Windows Universal platform. No, I'm sorry, go ahead. I was basically first. I was going to say you could support Qt as your backend and then get all of the other operating systems. That's not the first time we've heard about this. Yeah, you could basically do that.

Technically that's true, yes. That would be a nice April Fool's joke. That would have been a nice April Fool's joke. I want to interrupt the discussion for just a moment to bring you a word from our sponsors. Backtrace is the only cross-platform crash and exception reporting solution that automates all the manual work needed to capture, symbolicate, dedupe, classify, prioritize, and investigate crashes in one interface. Backtrace customers reduce engineering team

time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace jumps into action, capturing detailed dumps of app environmental state. It then analyzes process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. Whether you work on Linux, Windows, mobile, or gaming platforms, Backtrace can take pain out of crash handling. Check out their new Visual Studio extension for C++ developers. Companies like Fastly, Amazon, and Comcast use Backtrace to improve software stability. It's free to try, minutes to set up, with no commitment necessary.

Check them out at backtrace.io.cppcast. How complete is the API? I mean, I know there's a lot besides just user interface controls, like being able to get to the GPS or networking or things like that. Do you have that all mapped out into a cross-platform C++ API? We have mapped it out in our planning. So we have a very simple XML HTTP request style network access already, but the whole sensors and cameras and so on and so forth, that's all planned for this year.

Yeah, we will basically wrap all of the important stuff and make it available. But also we are trying to kind of come up with a good idea and it's a work in progress, how we can enable developers to get a good path from working in android natively having already having an app maybe or in ios and then transitioning to bowden because that that would basically eliminate most of the stuff that we don't provide at the moment that then you wouldn't need it you could just use java natively or objective c or swift or whatever you like

and could just integrate boden into that app and then move step by step towards um making an app basically cross-platform and and that's a that's a good point one one thing that's very important for us to us is um to keep all the technology that we develop also accessible for the user in the end. Be that the build tools that we wrote for ourselves, we want to be able to just have those. If you don't like Bowden, but you like the build tools, we want you to be able to use that. Or if you're missing something,

it should be super easy for you to be able to use that. Or if you just, if you, if you're missing something, it should be super easy for you to, um, to interface, um, the, the native platform yourself as well. So I, I'm,

I'm thinking about this like native layout on devices and stuff. And I know like today application development in general, you have to be super flexible, right? Like trying to do a rigid layout as a bad plan, because you don't know if the phone's going to be what resolution, what orientation, all that kind of thing. Could be an iPad or tablet.

Yeah. Does Bowden either help with those things or does it cause a different set of problems for the developers? Like how does that layout come into play working with it? So on the ground, on the base layer, our widgets only have a position and a size. And we have a completely free layout system, which means you can give any control, any view,

you can give whatever layout engine that you want. So, for instance, if you have some crazy idea how layout should work, you could just plug it in and all views could work with it. And we totally agree that the flexibility is extremely important. And what we've done for now is to use the Flex layout that you know from the web technologies. So basically, what you can do on an HTML page with a Flex layout, you can do in Borden as well. We're using the Yoga library from Facebook for that. Yeah, so basically, it's very, very similar to writing flex layouts in css yep so um that that is i think

also helping a lot with uh making it as flexible as possible because that allows you basically to just write one layout style sheet and then um have it work with an ipadstyle app or a phone app, be it a big phone or a small phone or whatever. It basically allows you to write kind of responsive layouts. And that was a quick way for us to solve this. But I think it's important to stress that we allow to extend that in a very modularized way. So you can just plug another layout engine into it if you like.

And you can even mix them inside the same window. Nobody says that all views need to follow the same layout engine. If you want, you can mix and match them to your heart's content. Oh, and the same is actually true for the UI itself. So what draws the UI and whether it's a really native widget coming from the platform framework is actually also modularized and replaceable. So you could just go and put a renderer into it at any level you can draw parts of the uh ui natively and then have a view that's just rendered by a custom renderer and all of those things wow um so a while ago

i talked about how i would like to make a cpp cast mobile app um and i was thinking maybe i'll look into q mobile i don't think i ever really got around to it. Do you think I could make this with Bowden? Not right now, but very soon, I think so. Yeah, right now, probably it's possible. But it depends on how much effort you will put into it. Because at the moment, there's just some parts missing in Bowden. For example, I guess it would be pretty hard with the API that we provide at the moment to play back a podcast audio clip. Okay.

That's just things that are missing because we just prioritize them down. There are specific use cases. We just, at the moment, we are quite focused at getting the most popular features out there. So, for example, video and images and all of this stuff. But once that support is in, I think it would be pretty simple. And another big thing that's probably preventing you from writing an app at the moment, which you would like to get out to the people, is that we don't have a working solution for theming and styling so um that that is also um maybe i wouldn't call

it a disadvantage of the native of the native widget approach but but it is definitely uh a thing we need to solve um you just have the native widget as it appears um as defined by the platform, basically. So we have to come up with some way to make it customizable and to make, I don't know, like a button background color, a font that you want to set, and all those things. That is what's basically preventing you to write that CppCast app right now. So if you're like Facebook and you want to have a certain theme to your apps that they look kind of similar on both the Android and iOS, then you wouldn't be able to do that yet, you're saying?

Correct. Not yet, yes. But it's definitely a pretty big item on the list and it will come pretty soon because we think it's basically a necessity. Without it, you probably won't be able to write apps that conform to the state of the art. Yeah, a project that I've been involved in uses Qt, but by the time it reached a certain point of development, basically all of the widgets were just custom anyhow to get the exact look and feel

that they wanted everywhere. Yeah, and we definitely recognize the two different use cases where you have a simple app that's actually better if it's just a native theme, but then there's the opposite side of the spectrum where you want to completely theme it, and we want to support both in the end. Yeah, finally, probably both solutions will be supported, even a custom renderer, but that's far in the future. And I think for now, you can get, I think most of the apps that you would want to do today,

you can get done with the native APIs pretty much. That should be possible, even with fancy animations and stuff. So right now, I guess the project's in kind of a beta stage, and you can just go to GitHub and download it and go ahead and make your own application. What are the future plans for it? Is this going to be, is it going to remain open source, or is it going to be some type of enterprise licensing?

It will definitely remain open source. And we started off with the GPL, which was kind of a safe haven because we didn't want to risk anything with licensing. To be honest, Boden is a project which needs to be funded if it shall continue as it is being developed right now. So we need to find a solution to also monetize the project that's just how it is um but we will i think it's it's fair to say we will switch to the lgpl um license so it will be kind of the same open source model um as you can find with with qt right now. Right. And the biggest problem with the GPL was that people weren't basically able to write an app and deploy it to the iOS app store,

because then they would have to license their app under the GPL, and that would basically be rejected by Apple, because it doesn't conform to the app store in terms of service. Wait a minute. Yeah, that's a funny thing. You're not allowed to release a GPL application to the App Store. That's correct, yeah. How does that, what?

Why would Apple not allow that? Because it's basically, I'll try to to make it short and sweet it's really a complicated um legal thing um but but in the end it boils down to um apple has terms in its um app store ios app store terms of service which basically prevent you from um redeploying the app to anyone without using the iOS app store. And that is forbidden by the GPL. So some other developer could go pull your code and then build it themselves and put it on their phone. That is what is required by the GPL. And that is not possible without using the services provided by

apple so that is what what basically makes those two things completely incompatible okay that is not the case with the lgps so basically our interest was to be still be able um to monetize the code we have thought about many business models, but in the end, it boils down to we need to be able to sell the code kind of like the QT company does it. So you will have the option of licensing it under the LGPL in an open source project

that can be a commercial project in theory but it cannot be a proprietary project and if you want to license born in a proprietary project you basically have to um get into a commercial license agreement agreement with us with us which we don't have yet but we are working on it and this probably will be the model um it's not a hundred percent decided but i guess that will probably be the model for now okay okay so it will definitely stay open source in the sense that lgpl is open source and you will still be able to to license it under gpl but that is only for people i guess working later um on as soon as we have desktop support for example that wouldn't make sense again you could just create a gpl app based on boden on desktop but for mobile it doesn't make

any sense unfortunately so uh i mean this is backtracking a fair bit, I think, but we've mentioned Qt several times, but I was curious, besides Qt, if there's any other libraries that you looked at or compared to before deciding to start down what's ultimately going to be a fairly long road for you to get this fully completed. Yeah, definitely. We looked at all of them. All of them. Really looked at all of them. All of them.

Really, literally all of them. We had very long days where we looked at all the pros and cons of the different frameworks out there and seeing if there is a niche, a market for a C++ framework that primarily draws with the native operating system components? Yeah, we are aware that we are kind of competing with big companies. I mean, there's Google Flutter, there's Facebook React Native, there is Microsoft Xamarin, there is the Qt company so but basically it boils down to can we provide something that is worth paying for in a sense and I guess we still think we can because it's I mean Qt for example is pretty old year old it has a really big code base um just the the the simple act of installing qt on your system is really really uh not a good experience in my point of view and um the other frameworks

like flutter and react native they are basically we cannot compete with them they are mit licensed and they have a completely different business model. They don't need to make money. So what we are focusing on is basically mainly making something that is really usable and where you can, which you can use to save time and hassle at the moment if you are a C++ developer. We are also thinking about opening that up to other languages as well because I mean C++ is basically the foundation of everything and we are focusing completely

on C++ right now but I could imagine that in the future we are considering to support other languages as well so there's really a broad range of options I think we have to where we could also kind of pivot if something turns out to be not working all right we haven't gotten too technical um like what

versions of c++ are you able to support with boden are you using c++ 17 yes okay and then that's that's an important point is um we are looking to the future when it comes to technology. So as I said before, we are supporting Android 28 and we are not super concerned with the older versions. We're supporting iOS 12, not super concerned with the older versions, because we also have to realize that adoption will be a little ways out for most people for this framework. And we see it as absolutely necessary to use the new stuff, so to speak, especially when it comes to C++. C++ has grown so much in the last couple of years,

and it would be a shame to not take advantage of that. And there's basically no one really, at the moment, there's no one really taking care of that. That's at least what I feel. So for JavaScript, I mean, you have this big community coming up with new stuff every day, basically. And there are so many new frameworks and things you can use and try out. And for C++, we now have this development that there are new versions of C++ coming out with new features.

And basically, we are using frameworks that are 20 years old. So that is kind of the gap that we see and where we also see a niche which we could maybe fill. Yeah, it brings an interesting point that I've thought about a little bit lately. So right when C++11 was released in the 2010-2011 time frame, we saw a rash of libraries come out that were like something 11. And everyone tacked 11 onto the name as they supported C++11. And now all of a sudden those libraries sound eight years out of date. We're not calling it Borden 17. Right, yeah.

But sure. But also when we look to the future of C++, I think we talked a little bit about C++ modules and one thing that I personally very much look forward to is the whole

introspection stuff that's supposedly coming soon. Yeah, well, yeah. And, yeah, I think there's so much live and awesome stuff left in C++ that's still to come. And it's a shame that a lot of the good, the big frameworks are big frameworks are kind of stuck in the old ways just because that's where they came from. Is there anything particularly interesting you're doing with Bowden that you don't think you could have done with earlier versions of C++? I mean, std string view, for instance, std regex, even though it's not super performant at the moment.

But it's there and it works. And it works, exactly. I mean, maybe looking at it that way, the thing that you can do these days with C++ is you have a very good standard layer. So when I look, for instance, at a shared pointer or something like that, which isn't super new, but it's in the standard now, and it allows you to do away with, like, how many shared pointers have we written in our lifetimes as programmers, and we just don't need that anymore. It's all there in the standard and it makes

super sense to to use it because then when you come to the framework you exactly know what's going on when you see stood shared pointer you know how it works there's nothing that you have to to learn again i mean cute system for instance with with q objects that that have delete later and then you but you also have a q shared pointer and all these kinds of things that you all have to learn. And I think that's the awesome promise with the new C++ versions. You have it all in the standard, and you can rely on how it works. Yes, and also I think... Sorry? No, no, go ahead, finish.

Go ahead. I think a big part of the development in C++ is not really what you can technically do with it. But I see it as a kind of a usability thing because it's really much easier now to write certain constructs. For example, with 11, lamb ago, we would have had a hard time implementing something like BODEN without getting into the QT mock, for example. Yeah, absolutely. In that scenario where you have to come up with a meta code generator or something to

ease your life, to make it readable in a way. And especially UI code, my experience is that uh what you just said if we can get more introspection and um reflection into the language then it would be a big leap forward for for ui code because basically that's one of the biggest the biggest challenges is that c++ is so static uh at certain points that's really a problem for UI code because it gets ugly. And I guess that's a big part of what we are trying to do. We are trying to make it beautiful

in a way that it is maybe beautifully possible to a JavaScript developer right now to write a JSON dictionary. But for a C++ developer, it might still be a hassle or it would have been a hassle 10 years ago, basically. Yeah, and that introspection

would help you a lot probably with your JNI glue layer, I'm thinking. Absolutely, yeah. Yeah, and also properties. Properties are still a big topic. I think there is no good solution for C++ properties that can have bindings and are kind of dynamic. Like, for example, in Objective-C, you have KVO for doing observations on property values and stuff. It's just not possible in C++.

You run into quite funny problems. For example, then you write some property which allows you to do bindings and everything and everything looks nice and then you cannot copy the object holding the property anymore because some function pointer points

to the object that has gone missing or you even you even have uh null references and all of this stuff not references but bad references um we have gone through all of that and there are a lot of points in c++ which are still lacking in a way for ui frameworks yeah but when when we look at 10 years ago it's so much better these days so yeah yeah okay well it's been great having these days. Yeah. Okay. Well, it's been great having you on the show today, guys. Definitely keep us in the loop when Bowdoin is at kind of a later stage in his development and you think we might be able to go and make our own app with it, okay?

That would be great. Absolutely. Thanks for having us. Thanks for having us. Thanks for coming on. Yeah. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast.

Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Facebook and follow CppCast on Twitter. You can also follow me at Rob W Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do

so at patreon.com slash CppCast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.