Embedded - 354: Better Snowmen in Finland

Episode Date: December 4, 2020

Becky Worledge of the Qt Company (@qtproject) spoke with us about application frameworks, organizing large code bases, and automotive regulations. The best place to get started with Qt is the getting started page: doc.qt.io/qt-5/gettingstarted.html  Or skip that and head straight for the code: github.com/qt Maybe backtrack to see what is available: qt.io/product/features Hmm, was there talk of Qt and Python? PySide was it? qt.io/qt-for-python But wait, Qt for MCU? What platforms are supported? QtForMCUs/qtul-supported-platforms.html Finally, don’t get eaten by a Grue, sense when they are coming: doc.qt.io/qt-5/qtsensors-grue-example.html Qt6 is coming out Dec 2020. So maybe replace all the qt-5 in the links with qt-6 to see if it is ready yet! Oh, and Qt is hiring: qt.io/careers The quote at the end is not from Abraham Lincoln. (Quote Investigator). Still a good thought.

Welcome to Embedded. I'm Alicia White, alongside Christopher White. We get a lot of questions about good API design and code organization. This week we have Becky Woolridge to talk to us about how she does it. Hi, Becky. Thanks for joining us. Hi, Chris. Hi, Alicia. Could you tell us about yourself as if we met at a conference? Sure.

My name is Becky Woolwich. I work for the QT company. I'm in the consultancy team. My job is really to help our customers produce fantastic products with QT. We do all sorts of things. We do training. We do consultation. We do all sorts of things. We do training, we do consultation, we do bug fixing, and we do implementation of end products for customers as necessary.

And could you explain what Qt is? Oh, sure I can. Qt is a cross-platform framework and runtime. It's quite well known for user interface technologies, but it does a lot more than that. It allows you to create more or less any kind of software application, and it will then run across various supported platforms. So our mainstream Qt runs on Linux, Windows, Macintosh, Embedded Linux, QNX, VxWorks, and various other platforms. Okay. And that's largely what we're going to be talking about with respect to APIs and code organizations, because if you can organize that, organize anything. Before we do that, we want to do a lightning round,

and that's where we ask you short questions. We want short answers. And if we're behaving ourselves, we won't ask how and why. But since we already know we aren't behaving ourselves because we've invited a secret guest to help out with this part, I guess, Harrison, do you want to say hello? Hello. You also work for QT. What do you do there?

I do. So I am an engineer turned suit. So I'm a business development manager over at the Qt focused on our new microcontroller offering. So Qt for MCU. And I believe you're specially qualified for lightning round. I am definitely qualified for lightning round being a listener of the show. So excited to be a part of it. Okay. Are we just throwing this at both of them at once or what's the plan here? Yes.

Yes? Okay, have you seen the Aurora Borealis? Yes, I have. I have not. Does it sing? It does not, but it does move. How do you say thank you in Finnish? Gidos.

Or you could say Gidos Paljonjon to be a little bit politer Harrison is that correct sure we should ask Harrison this one first are reindeer cute you know it depends it's a lot in the antlers have you ever pet

a reindeer yes actually what about you Becky It's a lot in the antlers. Have you ever pet a reindeer? Yes, actually. What about you, Becky? I have never petted a reindeer. I've stood next to one, but I've never touched one. Preferred listening when programming? Oh, I generally listen to the radio, local news or something. Harrison?

Yeah, I prefer silence, actually. Harrison? Yeah, I prefer silence, actually. Silence? Yeah. You and Alicia. Like, noise cancelling. Totally dead silent. Do you have a favourite fictional robot, Harrison? Yeah, I'm going to have to go with

Baymax from Big Hero 6. I have a small child, go with Baymax from Big Hero 6. I have a small child, so he's my most recent favorite robot. Becky, what about you? I think my favorite robot would have to be Bender from Futurama. He's great. He's such an angry guy. He's kind of actual cross-platform.

That's true. Should we bring back the dinosaurs? Heck yes. Why not? I mean, they did a whole documentary about how that could be bad. Starring, what was that guy's name? Jurassic Park. Yes.

Harrison, do you concur with that? That's going to be a no from me. Yeah, growing up on Jurassic Park. Okay. I want to talk about QT. So we're going to say goodbye to Harrison for a while and talk to Becky about this. Thank you, Harrison. Thank you.

Okay. The first question. QT? Cute? Cutie, cute, cutie. What is, I mean, I prefer the last cutie how you want to so that goes even for the title of the product um but we find that native speakers don't like calling it cute native english speakers yes so in america and in uk and in australia it can and new zealand it tends to be cutie whereas in europe and other places it's cute i feel much better i've been calling it QT for years and I always felt bad. Happy to help. What was the original pronunciation? I think QT is actually from Norway, or Qt is actually from Norway, and I think they always called it Qt.

This is about 20 years ago. Since those days, QT has become a Finnish company via Nokia and Digi. And in Finland, at least, they call it Kute, because that's the way the Finnish pronounce the letters. So there's a third option out there. Kute. I like that. You can use that. And you described it as platform-independent UIs and frameworks.

Yeah, Qt has a very well-known graphics framework. There's the Qt Quick and there's the QGraphicsView framework, which is slightly older, and the QWidgets toolkit as well. But it's more than just a graphics framework. It also does uh general purpose programming it does network um support posix and other networking technologies are supported um sql databases and many many more things so it does more or less anything you need it to in a general programming kind of way and or at least it used to now that software and technology is kind of more or less everywhere it can be kind of way, or at least it used to now that software and technology

is kind of more or less everywhere. It can be kind of hard to keep up with everything, but the basics are certainly very well covered by Qt. And it even has its own application runtime, or event loop runtime, I should say, in there, so that it's a full-featured application framework. Being an embedded, I'm not always familiar with what the word framework means to people who are truly in software. Yeah.

So when I say framework, I mean we're a C++ programming language, or libraries are written in C++. We provide an API which gives you a whole bunch of features which are there to create software from. So when we say framework, we really mean a set of components and tools that allow you to create the software, everything you would need in software, so threads and strings and events and so forth.

So it's like an alternative to the native SDKs that you get with Mac OS, with their various, I guess they call them frameworks, their core foundation and their UI kit and all that stuff. Or on Windows, the same goes for the Windows SDK, except

you don't have to learn if you want to write software for multiple destinations, you don't have to learn. If you want to write software for multiple destinations, you don't have to learn each of those native SDKs. Well, that's exactly it. And I think some 20, 25 years ago, a couple of Norwegian engineers were writing, I think it was hospital software, to run on Mac and Windows. And that's where the idea really came from,

is that they wanted to write the same application and run it on both the different operating systems so they wrote an abstraction layer which became qt but it's it's more than an abstraction layer at this point i mean i can totally see the abstraction layer i have actually written things for os2 novell netware windows the same program in all of them. So I understand this pain. In a different century at this point, but yes. But what was my question?

I don't know. You understand framework. Oh, okay. You understand abstraction. I understand the hardware abstraction. I understand the operating system abstraction. But it does more than that now. Because, I mean, I saw it listed Bluetooth and unit tests, which are, one of those is hardware and one of those is a software piece to work on a software thing.

That's true. And the Bluetooth layer, of course, is a wrapper around the Bluetooth, which would come on your system. So say you have an iPhone, we have a Bluetooth abstraction for that. So you can interact with it using the Qt runtime. The unit test is an interesting one. We do occasionally hear about the unit tests in Qt. It's the Qtest framework. And it's not super powerful so if you were writing some serious software and you needed a serious powerful unit test framework

it might not be the best choice but we do use it throughout Qt so in Qt itself we use the Qtest framework for our unit tests so in our compile time unit tests in Qt are all written using Qtest and there is a lot of software examples available for it. When I invited you on the show, you were pretty quick

to say you weren't an embedded software engineer. Yeah. But then you also say that you mostly work work with embedded Linux and QNX devices running ARM chips. Yes. How do you define embedded? It's kind of a gray area, really. And when I first started my career, I kind of knew I wanted to be an embedded developer, but at the time, embedded meant microcontrollers and that kind of really small stuff. And even to an extent, the ARM chips then. But the ARM chips we're programming now,

whilst they are kind of embedded in terms of where they're applied, they're actually pretty powerful. So you still do have hardware constraints. You still do have system resources. But in terms of what you can do with them, it's immense. It's more powerful than the first desktop I ever had. So, yeah, it's kind of a gray area, really, I think. When I first used Qt professionally,

it was about 12 years ago now, and, yeah, I was doing a medical device, and I considered it embedded, but the target hardware at the time for the prototype was Windows, even though we had specific custom hardware that we used for the data acquisition and stuff. I still consider that an embedded device. We always intended to move it to something more embedded than Windows.

I don't know if that ever happened after I left, but yeah, so I think that definition is very gray, like you say. It is, yeah. And I'm kind of keen to say I'm not a microcontroller kind of guy. I don't know anything about how they work. But when it comes to an embedded platform, or kind of embedded in terms of application and where it ends up, then for sure I'm an embedded developer uh but you don't

do qt has recently come out with qt for mcu it has and if this is this is more harrison's side but um qt for mcu i think came out last year and that's a qt that's designed to work specifically on microcontroller units and it does give 60 frames per second and extremely nice animations, but I'm just not particularly familiar with how it goes at a kind of deep level. Yeah, we can talk about it another time. But you did mention to me that in the decade, in the almost decade you've been there, Qt has actually gotten smaller kind of um qt in many ways qt and c++ i mean we've added features all the time to qt and now the download

has gone from about 200 megabytes to about 500 when you download the whole source code so in terms of what's available it's. But in terms of where it will run, one of the things I've been aware of since working, I've been in Qt consultancy and Qt professional services for most of the time I've been working with the Qt company and predecessor Digia. And in that time, I've seen customers asking, can Qt work on this chip?

We've got this much RAM, 16 megabytes or however much. And in the past or in the early days, it was kind of like maybe Qt is not the solution you're looking for. We need a bit more than that to run. Qt always had a configuration system in there whereby you could add macros and defines and take things out, but it didn't really work very well until a couple of years ago where we refactored that and created this Qt Lite offering.

So the Qt Lite offering allowed you a better way to configure Qt, so you could take parts of Qt out and you could make it smaller and smaller, so it would run better on the smaller, more resource-constrained devices. But ultimately, that still wasn't quite as small as we wanted to go so that led on to i guess the qtmcu project so i haven't had that much to do with qtmcu i don't really know exactly what started it because this was done over in europe while i've been in the states um i'm not important enough that they actually consult me for these

things anyway but yeah this came out a couple of years ago and i think not important enough that they actually consult me for these things anyway but yeah this came out a couple of years ago and i think first release was last year and uh it's got it running on cute mcu uh or running on microcontrollers um what i've seen a few things from there is i've also seen a few mcu features appearing in cutie now I can't name any off the top of my head but it looks like the MCU feeds into Qt mainline and kind of makes that more efficient which is an extra bonus I think. Qt Lite would let you work around these macros that would let you select what you wanted. Did I understand that right? Yeah, pretty much. We always had this configuration framework

which would allow you to define and remove parts of Qt so you could define out large parts of the Qt source code and make smaller libraries. And Qt Lite was a better way of doing that so that it went from several weeks of kind of suffering to an afternoon of picking through what you want from a list and just taking it out. So that was a big improvement, but it's not microcontroller. It just makes it smaller for the ARM chips and similar.

But what you're saying, we talked to Drew Fastini about Yocto. And it sounds like this Qt Lite is kind of playing the same role that Yocto does, that you're choosing what you want. Is that right or totally wrong? Yeah, Qt Lite is not exactly the same as Yocto, but it's kind of along those lines. It's a way of automatically taking out parts of Qt, but you're taking parts of the source code where I guess the Octo is working at the level of the application and the library. So it's similar. And you said you choosing code, not just choosing libraries.

Yes. Because a good portion of Qt is open source still. How does that work? When I go to the Qt website, it talks to me about purchasing things, but it's open source. And I know there's the consultancy side where you'd be purchasing time for help and training, but there's also a way to get a different kind of license. So you can use QT. You can always read the Qt source code, you can always access the Qt source code, and you can always use Qt without paying us for it at all. But in return for that,

you have obligations both to your customers and to the wider Qt community. Alternatively, if you would rather not have, if you're creating an embedded device, and you'd rather not have the ability for your customers to change the license and access the file system, for example, you can pay us for a license where you would then not be releasing it under the LGPL licenses.

Closed source license. So basically, you have to conform to LGPL if you're using it based on open source. And if people are used to that and they know what it means, then they know what they're getting in for. Yes. And that's the v3 version of LGPL, right?

I think. We changed sometimes. Yeah. I think we changed to v3. Yeah. Okay. Okay. So now the organization part. When I sit down and I have a project and I have so many sensors or

inputs or outputs, and I have a couple of processors I need to support, maybe because I have a product line, and then I have a UI that needs to work on different displays, and I'm not using Qt for some reason, how do you suggest I go about just putting together the file system? It includes source directories. Do I just put it all in one directory and give up, or how do I organize this? I wouldn't recommend it all in one directory and give up or do i how do i organize this i wouldn't recommend putting everything in one directory because you will need to come back to that directory at some point and sort through it um does we we for when it comes to actual applications we we give a kind of a kind of layered structure to your application so you've

got all these numerous different ios, various signals from various places. You'd probably want to put those into the same kind of directory. Maybe if necessary, divide them up, but depending how many there are. So put your IOs into a single directory. And then business logic, assuming you have some of that, which you probably do, why wouldn't you, would go into another directory, which would then read from the io the input um on top of that you would perhaps have kind of a layer which connects to the ui itself so in in um that sense you've got three kind of lower layers kind of behind the scene

um on top of that you've got your user interface which we would put separately now depending on the different displays you're supporting i guess you've got two or interface, which we would put separately now. Depending on the different displays you're supporting, I guess you've got two or three different sizes. So if you are using Qt, it's fairly easy to create a kind of scalable UI. Our technology will lay itself out correctly according to the screen display size. So if you can create it to work with that, and then that just connects to your connective layer, which goes between the backend and the frontend. So that way, the UI wouldn't need to know about the IO at all. It wouldn't need to know even so much about the business logic if

it doesn't need to. And that should be fairly straightforward. And that's one of the things that I'm always in favor of is the code should be as dumb as it can. It shouldn't know about anything but itself if possible. Maybe it knows a little bit about what it works with below it, but it shouldn't know anything about it. It's the things at its level or above. No, I think that's fairly well understood in embedded circles, but we do occasionally see customers who haven't gotten to that point yet, basically. It's something I don't see in embedded that much.

We're kind of talking around a paradigm that I think Apple kind of named, maybe it was Microsoft. I can't remember where this first came out of, but model view controller, right? Where the business logic is in the model code. And then there's a view, which is the UI. And then there's some other stuff that I never really understood the controller that goes between them. But the point that all of this is that the views don't really know anything about the model. The model doesn't know anything about the views,

and they all kind of talk to each other through an abstraction, right? Yeah, pretty much. I mean, Qt, we have a model view framework as a component of Qt, which provides a bunch of different ways of laying things out, list views, scroll views, and so forth, which would then be connected to a model. And the actual knowledge which knows about the model itself would sit in a delegate class, which would then be connected to a model. And the actual knowledge which knows about the model itself would sit in a delegate class, which would then appear in your view. So there's various things which Qt actually provide.

If you were to create this using a non-Qt framework, I think that would be fairly doable, I think. Yeah, I mean, it's a common thing to separate along those lines. But I'm still going back to, well, do you put the files in source directories under spy? Or do you put the files in an ink directory and put all the includes in one directory? Maybe we should analogize to the large project we have in front of us. What does Qt do? I mean, because it's huge, right?

It's huge. We divide by modules and sub-features inside modules and so on and so forth down to the actual source code directories. So we add the C++ and the header files in the same directory. But when it comes to actually installing Qt, we take the header files out and put them in the include directory. So when you install it, you'll find them there. The source files, of course, you wouldn't install them,

but the libraries would go into a separate libraries directory that way. So when you come to deploying it on the target, the include directories and the build tools, which come with QTR in a separate place, the libraries themselves are there for linking and they're there separately for deployment. So that makes sense for linking and deployment because then you have a limited number of include directories

and a limited number of library directories. You just kind of say, okay, Qt is here, here are the libraries, here are the include directories, just don't bug me about anything else. But when you're building it, you do put the.h's with the.c's or.c++'s, CPP's? When it's on GitHub, yes, the.h's and the.c's are in the same place. When we're looking at them in a tool like Qt Creator, that will actually...

Are you familiar with Qt Creator at all? I am. Great. It is the best IDE in the world. I really liked it. That will display them in logically separate areas of the file tree for you, which is useful. But for actual storing on GitHub and working on the code, we just keep them in the same place.

And that means when you build the libraries, you do have to have all of the paths in your make file, which I guess you probably just do automatically you have a spider make um tool um which uh because qt is traditionally built around the project file the dot pro file which lists everything in a single project and that's um i don't know if you're from chris i guess you're familiar withMake. It's the old tool which would read these profiles, or the venerable QMake as we call it these days. It would read these profiles and create the makefile

or whatever kind of file is used by your particular target platform. So in most cases, that's a makefile, but not always. We've actually, since Qt 6, which is coming out, I think, next month. So it feels weird to think that it's November already and Qt 6 is due out in December. December is... Actually, when this show goes up, it will be December.

Sweet. Okay. So Qt 6 might not be out already. It's out in December. And we're moving from QMake to use the regular, the more mainstream CMake as our make file generator. Oh, sorry. I know, I'm going to miss QMake too. I'm bummed out about that. But it's a good thing.

It's going to have a nice retirement. It's going to be looked after. Like an old dog. Okay. So why cmake i mean chris's chris's response is actually mine too which is oh cmake i've uh checked when cmake and cumake came out um and cmake and cumake both came out around about the same time. CMake is actually a little bit older than QMake, so it's the senior tool. Basically, it's a financial decision. QT or the QT company doesn't see any particular sense in competing with the open source community and supporting QMake and its obscure scripting language, it doesn't seem like a particularly useful endeavor when CMake is more widely used.

And we would be able to use it without actually supporting it ourselves, which is useful. So that's why CMake, it's a good tool. It's been around for a while. It's mature and it's well supported. How do you make these decisions? Because that's not the only open source thing that is also out there that Qt competes with. Yeah, and we're not really, in terms of open source, we're not really competing with other projects, but

yeah, I don't have much insight into how the decision was made. It's done over in Europe by people higher up the chain. Well, that's a support tool too, right? And maybe, I mean, that seems like a more reasonable decision to say, well, that's not what we're making, right? We're not making a compiler tool set.

We're making this framework. So why would we continue to expend effort elsewhere, I guess? Yeah. Yeah, that's basically it in a nutshell. You could say that about almost every piece of everything. I mean, well, there are some... Qt has threads. Never make anything. Qt has threads. FreeRTOS has threads.

Well, but... Qt doesn't have FreeRTOS has threads. I will. Qt doesn't have threads, in fact. Qt has a QThread class which uses either POSIX threads or Windows threads or VxWorks processes behind the scenes. So Qt itself doesn't have these threads. The QThread is an abstraction of other people's threads. And that's the key value in Qt. It's not always what we provide,

although some operating systems we do provide things, but the key value in Qt is being able to write the same application and automatically have it pick up the threads where you need them. Okay, that actually makes sense. This is about the cross-platformness of it. Yes, we're cross-platform. What about APIs? Because you have a lot of them. Yes. And you have to balance having them be flexible with also having them be easily understood. How do you create an API to do both?

Oh my goodness, what a question. I was not expecting how cute. This is kind of the philosophy of how cute is designed and how it works. Some of our APIs have been around for quite a long time. So if you look at the QString, it's been there for years. And I guess there's that aspect of something which has stood the test of time has kind of worked. But from a Qt point of view, I have numerous ways to answer that question, but none of the Qt APIs were actually designed by me,

so I'd kind of rather not answer that one as such. Does that ruin the plans too much? No, no, that's fine. It's too big of a question i i'm just a humble contractor or consultant i yeah the the guys who actually designed the um the api i guess it's kind of yeah trying to see every possible use and uh in the early stages of an api they do get refactored and they do get changed many times until they become the kind of stable API that something like QString has or QList has.

And that always happens. I mean, no matter what API you manage, somebody's going to use it in a way you didn't intend and now you can't change it because it's got to be backward compatible. That's true. Yeah. And supporting that and predicting that is not really possible in many ways. As we were talking in messages, you said that QT uses what's called the pimple pattern. That seems unfortunately named. but what is it i will it's not as unfortunate as it seems at the time the company was called troll tech and trolls of course are famous for their pimples hence the pimple pattern pimple is short for private implementation pattern

which is a qt hallmark, really. What we do is we provide, the best example is the QSet. If you've got the QSet source code in front of you, then that's perfect. If not, don't worry. But the QSet provides, or a QT element or object provides a stable API, and then that API itself connects to an internal API API which is a separate

class, a private inner class so if you then need to recompile the libraries and you need to change the private inner class then the compiled API the outer class is not changed at all so you have immediate binary compatibility

which is pretty useful between versions as well. So that's how we keep the binary compatibility and stability in the API. The private implementation itself, if you look, so going back to the QThread, if you look at the QThread class, you'll see there's a QThread Unix and a QThread Windows and possibly another one as well, I don't recall. But the actual code for the actual implementation lives in a private class itself. You shouldn't use the private in the class itself directly. And the source code contains warnings telling you not to.

So read them carefully. But yeah, you can then change the internal class as much as you need to, to support whichever platforms you need and then we use qmake or cmake to uh depending on what platform we're compiling for to include the relevant classes so if you're compiling for mac or linux then it would include the qsred unix if you're on windows and you can get the qsred window included. So that's the pimple pattern in a nutshell. So it's just a wrapper. Yeah, basically, yeah.

I mean, in some ways you could say that a lot of QT is kind of just a wrapper. Oh, yeah, I guess so. I mean, that makes sense because that does make sense, yes. I just, private implementation, pimple, that's some naming there, trolls. Well, trolls are very Norwegian, and Kuti is from Norway. Why are trolls Norwegian? Yeah, this is... So many questions I didn't put in the outline, huh? Yes, you did.

No, I forget this. The trolls are famously connected with Norwegian folklore, I think. Yeah. They're connected. They're actually invented there, but they've been in European kind of, I'm from Europe, obviously, I'm from UK. And in that sense, we always kind of had an awareness that trolls are a Scandinavian kind of thing.

So maybe that didn't cross the Atlantic quest at all. in that sense we always kind of had an awareness that trolls are a scandinavian kind of thing so maybe that didn't cross the atlantic quest at all i mean i just knew they liked bridges and goats norway's got a lot of bridges very exactly it's great for hiding under it's a beautiful place you should check it out one day yeah i can never decide whether i want to see the midnight sun or the arbor alice and I know you can't do that at the same time. Not easily but if you stay there for six months you could do that. You have been working on projects dealing with automotive regulations

and UIs. Could you tell us in a general sense what you've been working on? Mostly I've been working using the Qt Quick API which is our declarative user interface technology and I've been working on? Mostly I've been working using the Qt Quick API, which is our declarative user interface technology. I've been using that to create various different UIs.

Actually, that's been doing that for the last nearly three years. Before that, we had a customer who was using WebKit to create their UI. That was on the IVI unit, which is obviously the center console device. The last three years have been Qt was on the IVI unit, which is obviously the center console device. The last three years have been Qt actually on the IC system, the instrument cluster. When it runs on the instrument cluster, it's a

somewhat different matter than running on the IVI when it comes to regulation and software quality safety. I mean, that makes sense. The instrument cluster tells me how fast I'm going. The IVI just keeps the kid in the back seat quiet. Basically, yes.

So, of course, Qt is the Qt Quick UI itself or the Qt WebKit UI needs to be engaging and dynamic and it needs to make you happy to have the vehicle you've purchased. But when it's on the cluster, of course, we need to make sure that it's not going to fail, or if it does fail, then it will recover and keep working. One of the things I've been lucky enough to work with in the last six months is the Qt Safe Renderer,

which is a fairly new Qt offering and this one is not available as an open source product and that's been that one I think in the notes you spoke about blinking lights and that's where we provide the super safe ACLB, ACLD certified blinking lights I think in the notes I said I don't want lights to blink at me with

useless nonsense while i'm driving you did say that yes unfortunately there are certain requirements that some useless things must blink at you well it used to be that if you had a light on the console and if it was blinking and you wanted it to stop you could just put a piece of tape over it but these days dynamic telltales are a thing where we have telltales which move around the screen so if you can put a piece of tape on it then the telltale is going to move anyway so you can't do that anymore so that's an improvement i guess check engine light is just going to run away from you yeah just move it's like you can't do that um but these need to be certified to a certain standard so that they're not uh giving

you useless irrelevant information or they're not worse than giving you useless information they're giving you the information you need to have um and that's uh in order to run on the roads in America or basically anywhere, they need to be certified. They need to be checked by very sensible people who will say that, yes, we think this is safe. And that's where the QT Safe Renderer comes in. What's the specifics of that? That's very interesting. So when I did a medical device years ago, would that have been something I wanted to use for that, or is it strictly automotive? It's not. It's anywhere where you need something which is running to a higher degree of safety and a higher degree of risk management.

So the safe renderer will run on medical. Well, it will run anywhere you need it to. One of its natural applications is medical business as well as the automotive business. What makes it safe? What makes it safe? What makes anything safe? The safe renderer, whereas Qt has millions of lines of source code and they're open source, you can read them, but it's not possible to certify them because there are too many lines of source code to actually read through in a timely fashion, so you can't check it easily.

Whereas the SOFA renderer, there's a lot less lines of code, and it's been written to a higher standard. Are you familiar with the MISRA and JSF coding standards? The former. The former, yeah. MISRA. Yeah, JSF is not so well known. It's not so widely used, but I like to mention it because it's kind of cool.

It's the Joint Strike Fighter. Oh, right, right, right. Okay, I have heard of that. Yeah. But MISRA is the one which the automotive business uses, the automotive standard. And QT's safe renderer is written to the MISRA standard, and it's certified by TUV, this German certification panel, to say that they've checked it and it's up to scratch.

And that's what makes it safer, really. Okay. So ground up from the beginning, rewrite to be certified. Okay, cool. You used some other letters in there. We talked about MISRA and JSF. Those are standards you code to what is asild it's the automotive standards integrity level i think the s might be wrong but the integrity level of the source code um abc and d are the levels of safety to which it's been

written i should know off the top of my head whether A, B, C, or D is higher. I think the D is the higher one. So yeah, GTE SafeRenderer is up to the highest standard of the ASIL standard. So yeah, it's good. It's good stuff. Those are coding standards that tell you, like, don't put a single line if statement and don't use a single equals in any form of if statement and don't let things fall through switch statements. Yes. What does that have to do with UIs and cars or vehicles? Yeah, this is kind of a design question as much as anything else. But are there standards that talk about... Oh, I see what you're saying.

About how it should look? You were talking about the end product, not the coding. Yes. Yes. Are there standards that talk about how it should look? There are.

These are not necessarily the same ones. There are design standards as well. In some sense, when we're implementing the UI, we're not really focusing ourselves as engineers on the actual design standards, which it needs to run to. There's the ISO 26262, which is the kind of key appearance or key design in the ISO standards for the Telltale icons, 2575 icons.

So those are the icons you need to use, and that's how it needs to look. When we're actually writing the application itself, when we're creating it as engineers, we're not necessarily working to those because we're working to the specification, which comes from the design and the homologation teams at the automotive company themselves. So this is kind of the levels which they work to,

and they just tell us how to implement it according to those levels. So whilst we're aware of them, we're not necessarily working to them, we're working to the UX design itself. That makes sense. I mean, the designer is the one who's going to say, this weird triangle thing indicates your emergency flashers. So you don't really care. As an engineer, it's just a graphic.

I mean, of course, as an engineer, you do care about what you're producing. You don't want to work on a project. Like the guys who created the Ford Bronco, I think none of them wanted to create a car. Was it the Ford Bronco, I think none of them wanted to create a car. Was it the Ford Bronco? The Pinte. The engineers who created the Pinte didn't want to create a car which would blow up when it crashes.

And likewise, as software engineers, we don't want to make a piece of software which is not going to give the driver the information they need. So, yeah, of course, we're not necessarily working to the standards um so much as working to the design but we're aware of them so we know that they're there and we want to make sure everything is um is as safe as possible one of the questions we get a lot is how do i go from pure software or web development to embedded? Uh-huh. Yes.

And you did that. How did you go from web and Java development to where you are now? That, I would say, was persistence and not giving up. I guess I always wanted to be an embedded developer, and that's partly because my dad used to make silicon chips. So when I finally finished my college degree in computer programming, the kind of first job kind of thing was a web developer job. And that was because at the time it was it was an easy job to get into. And web development now is very different than it was back then.

But back then it was a fairly simple job. but that obviously that wasn't what i wanted to do so uh with help from my parents they gave me the money for the ticket out there i flew out to finland which i had finished my degree at i finished there as an exchange student and so i headed back because i was aware that at the time in finland there was a lot of embedded development going on. So yeah, I moved to the right place, and I kept asking people until eventually one of them gave me a job. So at the time, it was kind of good timing, because I'd just finished my degree, and I'd just finished studying Java as a language as well as others.

So I knew Java. At the time, not many people in the town, in the town of Oulu, were particularly familiar with Java. It was more of a C++ kind of town. If you can believe that towns actually have programming languages, then that's my story. So the company I went to work for,

a company called Mental Graphics, were looking for Java developers and they couldn't really find any, so I turned up at the right time and i think i sent about 50 resumes out and the one which gave me an interview were looking for java so that's how i got into it that's how i first managed to get my kind of foot in the door and then being in the town and working for mentor, did that start to push you over to the C++ side? Absolutely, yeah.

Mentor, this was actually the accelerated technology part of Mentor Graphics who created the Nucleus operating system. So I was working as a Java UI developer for an embedded system simulator, but that exposes you to the embedded systems and the code, which was where I wanted to go. So I was able to use what I picked up there to move on to other positions in the embedded world. And so you actually, it wasn't just a, I moved here and there and somehow ended up in embedded. You started out with a, okay, I'm here and I want to go to Embedded. Yeah, I kind of started out with I'm here and I want to move to here and get into Embedded and keep following it. So yeah, that's pretty much I'm here. I wanted to do this and I kept asking till someone let me. Persistence, it pays off. Yes, it gets you to California actually somehow. And now that we're

headed towards midwinter I bet California versus Finland has some advantages. Well you can make better snowmen in Finland but it's a little bit warmer in the afternoon in California at least. A little bit.

Do you have any advice for people who want to follow a career path like yours um keep trying and don't give up um you will find in the early days there's a lot of uh pushback or a lot of people will not be terribly interested but if you keep on going then you'll eventually eventually find something you'll eventually get something actually i have some better advice than that as well my first boss in mentor graphics this american chap called greg um one night we were out and he said to me rebecca becky um if you're always willing to travel for the company companies really appreciate people who will travel because

most people won't um so yeah that, that's helped a lot being willing to travel when going to see customers. Although perhaps not relevant now because there's this pandemic back then. Someday. Someday. I think most of my traveling days are now behind me, which is kind of sad, but kind of good. I had a couple of questions going back to the innards of QT wow

so I used it for a number of years and so I'm kind of familiar with how it works it's not just a framework because there's also kind of, I don't want to call them language extensions but maybe that's the right term so there's this concept like signals and connections.

So it makes some things about C++ and the object-oriented nature of it a little easier because you can communicate between your objects in a much more intuitive way. I don't know if I'm describing it right. I think that's a good description, Chris. It's almost like a message passing thing instead of making function calls. It makes C++ fun. And that's how a lot of the UI is designed.

So there's these language extensions and they're all built on top of C++. Is there, and you may not have an answer for this, but is there trouble with, C++ has kind of had a resurgence in the last decade where new versions come out and they keep adding new features and things and some of those i imagine duplicate or or supersede some of the stuff in in qt so

um has that been a problem or has that been easy to manage or is that something that just don't need to worry about? Again, it goes back to not competing with other technologies, but working with them. We're not, for sure, in competition with the STD C++ standards. But yeah, signals and slots haven't appeared in mainstream C++,

but there is better support for threads. So, an example of the QThread earlier when I spoke about POSIX threads and Windows threads um you could probably do that all with std thread now which in itself is a wrapper to posix and windows threads um yeah c plus plus or qt does absolutely extend c plus plus we have smart pointers of course you can get smart pointers in c plus plus um since c++11, but they've been in Qt for some time, and we've had the signals and slots and the connections, which is kind of like the listener pattern,

but kind of a little bit more than that too. So that's a nice addition. We have the QEvents, which is an encapsulation of an event. So can I just get a refresher on what the question was? Is it a problem having these things in C++? It was more as C++ develops, is it a challenge to keep them in sync or figure out what things to deprecate, I guess?

Not really. I guess the API is being, there's a large open source community who are looking at what parts of the API are kept and which are not kept. So in that sense, yeah, there's plenty of people looking at it to decide. Things like Qthread, of course, now that that's duplicated very nicely by std thread, we need to keep it, of course course because we need to keep systems which we're using q set in the past running so we can't just get rid of it um sure but it's and as far as

i'm aware um it hasn't been rewritten yet or i don't think it will be rewritten to use that for some time um but yeah eventually you can just kind of switch to that i guess um it's not really a huge problem particularly okay is there uh is there an idea of support for other languages i know there's pi qt right so is that for first class or is that just uh something that kind of hooks in i don't i don't remember how this works like if if you want use Qt, do you have to use C++, I guess is what I'm asking. No, that's a fair question. You don't have to use C++.

There is PySide, which is the Qt Python extensions. PyQt, I think, comes from a different company from us. Okay. Not that you shouldn't use PyQt if you prefer it, but we actually do offer the PySide, which has mostly the same, but is supported by the Qt company. And that's our Python bindings. Additionally, we have the Qt Quick language,

which is a declarative user interface, which runs our QML modeling language or UI language and JavaScript runtime. So you can do fairly decent applications using Python. You can do more UI kind of applications using Qt Quick. And then the rest you'd have to use C++.

Are you all paying attention to Rust or is that not on the radar? As far as I'm aware, I couldn't speak for our R&D team. Probably someone is aware of it, but in the consultancy team, we're not particularly focused on it here. I'm just heading off the emails. Oh, no, you're making the emails go to QT instead of us.

I'm redirecting them. I have used GTK in Python for the most part. How do I decide to use PySide instead? I mean, at what point of complexity do I say, okay, that's... Sell us on that instead of GTK. Yeah, I'm selling with PySide. Oh, I'm not familiar with Python GTK. I might have to fail on this question as well. PyQt is fantastic.

It's from the Qt company. It's cross-platform. Qt people are very nice and very friendly. GTK people, I've never met any. I'm sure they're just as nice. I don't know. I've never used GTK. I'm not particularly familiar even with the python programming language i don't tell anyone i said that don't worry it's only a podcast

okay super right we have this wonderful qt yeah world summit which you should come to and meet all the qt people go out for a drink you'll be sold that. That's the best I can do. It's not free. When I went to go look at QT to kind of look it over and figure out what to ask you, there were a lot of things, a lot, a lot of things. I mean, we've talked about how big it is. Yes, it's huge. But I was a little gobsmacked. Overwhelmed?

Overwhelmed. Yeah, it's big. How does somebody, somebody out there is listening and thinking, I don't know if I want to use QT. It's a lot. What is the way to get them to look at it beyond the wall of possible features? We do have a very good getting started guide. So I think in your notes you mentioned the wiki and you mentioned the documentation. Qt has always had very good documentation. Our documentation team is first rate, always has been.

So our getting started guide our documentation guide is a great place to start if you just want to get up to speed and start experimenting with basic qt stuff then installing the or getting the qt installer and installing kind of just a regular qt with cute creator and that will also include a whole bunch of example applications which you can take apart and run the code and pick through them and see how they run. So you have a couple of options. There's documentation itself. Or there's Qt Creator examples.

So those are the basic, if you're doing it yourself, kind of getting running approaches. I think for myself personally, I chose the second of those. I actually just downloaded Qt and started messing with the examples some time ago. If you've got an idea of what you want to create, then, of course, that's always going to give you something to wait for. Linux, sorry, Linus Torvalds recently, he has this scuba diving application, which was, I think, written using GTK. And he recently, well, I say recently, I mean, sometime in the last 10 years, moved from GTK to Qt. Of course, Linus Torvalds is quite a clever guy and quite an accomplished programmer. So probably easier for him than for the likes of me.

But one of the things he did say, which was nice to hear, was how helpful and supportive the Qt community had been. So we have a great community. We're ready to help. So, yeah, get involved with the community as well. Yeah, I found the documentation quite good, and there were a number of books, although, again, it was a long time ago when I first started using it,

so I think the books that I have had are now out of date I think I had C++ GUI programming with Qt 4 which I do not think has been updated to Qt 5 but yeah because that didn't even cover QML or anything

of course if you're working as part of a software team which is transitioning to Qt one of the other great things we can do is both the Qt company and various of our partners, development partners like ICS or KDAB, do also offer training. So we've done that several times where we've turned up on a customer site and trained a whole team in getting into Qt. And there's kind of a pathway of things which you need to learn. So if you start off with the basics like Qt events and objects and the Qt event lips and move on to list views and so on and so forth and then move on to Qt Quick and QML, then that's a good way to go through. So start with the basics like QObjects and work up to the UI.

And, of course, if you're in need of training on it, then there are various open training workshops, which are run, or we can do a bespoke customer-based one too. As I was looking around, I ended up in the sensors section because... In the what section? Sensors. Sensors? QT sensors?

Oh, sensors. I thought you meant with a C, sensors. A QT sensor section. I thought you meant with a C, but that you meant with an S. I know. Sorry. I didn't know there was a sensor. Anyway. Yes, and the example they used was a GRU sensor, G-R-U-E,

and I was so confused until I realized that they were actually looking for GRU monsters. From Zork. From Zork. actually looking for grew monsters from zork from zork and the that was that was actually their example sensor was pretty hilarious once i understood what it was i'm glad that was amused that was amusing so would i mean are the other examples amusing i guess is the first question i don't think so i think probably I'm interested now to know who wrote that because not all of our examples are written by the QT company. They're not always, I mean, some of them are from KDAB and ICS and various other contributing parties.

So it's entirely possible that the grew sensor was written by some individual. I don't know who wrote it. It might not have been an actual Qt company. It would be nice to look into that, and I'm sure we can find that on GitHub. It's a nice one, I think. Yeah, definitely. Not all of our examples are like that, though.

Is learning Qt a good way to learn C++, or do I really need to know C++ first? I would suggest a basic foundation in C++. Qt does make C++ easier to use in many ways. We have that kind of reference counting and various other useful features. But if you aren't familiar with C++, you may find that it's a little bit too close to actual C++ than an entirely separate language. Then the C that I use that is sort of objecty and uses classes

but doesn't use any of the fancy C++ features. Do you use C with classes? Well, I use C++ because, you know i like the booleans but but no i i many of my compilers still don't support the good features yeah i don't know how well keyed mcu would run on those uh definitely worth asking someone about all right well i think we have kept you for uh i think maybe a little longer than we promised so let me ask you uh let's see you qt is hiring for the bay area yeah um qt uh professional services are um very busy right now we're overwhelmed and we're always happy to consider um new qt engineers or C++ or embedded engineers. So, yeah, sure, if you're looking for a position working in this kind of business,

then do get in touch. We are very happy to hear from you. Is there a good place to get in touch? I mean, we can put it in the show notes, really. That's probably the right place for it. Yeah, I think they go to the Qt.io website and look at our careers page and apply that way. It's probably the best way. I'm not sure if I should give out my boss's email on the podcast.

He might be unimpressed. He's a nice guy. No, but you can often email us here, and we're willing to pass along your emails to our guests. Sure, you can do that too. Yeah, you've got my email address, of course. And Becky, do you have any thoughts you'd like to leave us with? Read the manual. No. Yes, forget the manual, read the source code.

Yeah, okay. Our guest has been Becky Woolridge,ridge qt consultant with the qt company and we have also had harrison donahue embedded listener and business development manager for cute for mcu just pronounce it differently in every sentence this is that's my goal every time i say it i'm going to say it a different way thanks becky this was fun. Thank you to Christopher for producing and co-hosting. Thank you to Harrison and Iris for helping us set this up. And thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. And now a quote to leave you with. You know, I totally went and searched for cute in quotes and you

cannot imagine how many quotes I got. But here's one from Abraham Lincoln. Whatever you are, be a good one.