354: Better Snowmen in Finland
Transcript for Embedded 354: Better Snowmen in Finland with Becky Worledge, Harrison Donahue, Christopher White, and Elecia White.
EW (00:00:06):
Welcome to Embedded. I'm Elecia White, alongside Christopher White. We get a lot of questions about good API design and code organization. This week, we have Becky Worledge to talk to us about how she does it.
CW (00:00:21):
Hi, Becky. Thanks for joining us.
BW (00:00:23):
Hi, Chris. Hi, Elecia.
EW (00:00:25):
Could you tell us about yourself as if we met at a conference?
BW (00:00:30):
Sure. My name's Becky Worledge. 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 bug fixing. And we do implementation of end products for customers as necessary.
EW (00:00:51):
And could you explain what Qt is?
BW (00:00:55):
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.
EW (00:01:24):
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, you can organize anything. Before we do that, we want to do 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. Harrison, do you want to say hello?
Harrison (00:01:57):
Hello.
EW (00:01:59):
You also work for Qt. What do you do there?
Harrison (00:02:02):
I do. I am an engineer turned suit, so I'm a business development manager over at the Qt, focused on our new microcontroller offering, Qt for MCU.
EW (00:02:14):
And I believe you're specially qualified for lightning round.
Harrison (00:02:17):
I am definitely qualified for lightning round. I am a listener of the show, so excited to be a part of it.
CW (00:02:23):
Okay. Are we just throwing this at both of them at once, or what's the plan here?
EW (00:02:27):
Yes.
CW (00:02:28):
Yes? Okay. Have you seen the aurora borealis?
BW (00:02:34):
Yes, I have.
Harrison (00:02:35):
I have not.
EW (00:02:36):
Does it sing?
BW (00:02:38):
It does not. But it does move.
CW (00:02:41):
How do you say thank you in Finnish?
BW (00:02:44):
[Finnish 00:02:44]. Or you could say [Finnish 00:02:47] to be a little bit flatter.
CW (00:02:48):
Harrison, is that correct?
Harrison (00:02:50):
Sure.
EW (00:02:54):
We should ask Harrison this one first. Are reindeer cute?
Harrison (00:02:58):
It depends. It's a lot in the antlers.
EW (00:03:02):
Have you ever pet a reindeer?
Harrison (00:03:05):
Yes, actually.
EW (00:03:08):
What about you, Becky?
BW (00:03:10):
I have never petted a reindeer. I've stood next to one, but I've never touched one.
CW (00:03:15):
Preferred listening when programming?
BW (00:03:19):
Generally listen to the radio, local news or something.
CW (00:03:23):
Harrison.
Harrison (00:03:24):
Yeah. I prefer silence, actually.
CW (00:03:26):
Silence.
Harrison (00:03:27):
Yeah.
CW (00:03:28):
You and Elecia.
Harrison (00:03:29):
Like noise-canceling, totally dead silent.
EW (00:03:33):
Do you have a favorite fictional robot, Harrison?
Harrison (00:03:40):
Yeah. I'm going to have to go with Baymax from Big Hero 6. I have a small child, so he's my most recent favorite robot.
EW (00:03:50):
Becky, what about you?
BW (00:03:52):
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.
CW (00:04:05):
Should we bring back the dinosaurs?
BW (00:04:08):
Heck yes. Why not?
CW (00:04:11):
I mean, they did a whole documentary about how that could be bad, starring ... What was that guy's name?
BW (00:04:19):
Jurassic Park?
CW (00:04:20):
Yes. Harrison, do you concur with that?
Harrison (00:04:24):
That's going to be a no for me. Yeah, growing up on Jurassic Park, that's ...
EW (00:04:29):
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.
Harrison (00:04:38):
Thank you.
EW (00:04:40):
Okay. The first question. Qt, cute, cutie, what is ... I mean, I prefer the last cutie. I could get into that. What is the correct pronunciation?
BW (00:04:57):
I think correctly it's ... because we're an open source product, you can kind of use it how you want to. So that goes even for the title of the product. But we find that native speakers don't like calling it cute, native English speakers. So in America and in UK and in Australia and New Zealand it tends to be Qt, whereas in Europe and other places it's cute.
CW (00:05:20):
Oh, I feel much better. I've been calling it Qt for years, and I always felt bad.
BW (00:05:24):
Happy to help.
EW (00:05:28):
What was the original pronunciation?
BW (00:05:31):
Qt is actually from Norway, or cute is actually from Norway, and I think they always called it cute. This is 20 years ago. Since those days though, Qt has become a Finnish company, for Nokia and Digia. And in Finland, at least, they call it koo-tay, because that's the way the Finnish pronounce it, so there's a third option out there.
EW (00:05:55):
Koo-tay. I like that.
BW (00:05:57):
You can use that.
EW (00:06:00):
And you described it as platform-independent UIs and frameworks.
BW (00:06:08):
Yeah. Qt has a very well known graphics framework. There's Qt Quick and there's the Qt Graphics View Framework, which is slightly older, and the QtWidgets toolkit as well. But it's more than just a graphics framework. It also does general purpose programming. It does network support projects, and other networking technologies are supported, 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, 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.
EW (00:07:05):
Being in embedded, I'm not always familiar with what the word framework means to people who are truly in software.
BW (00:07:15):
Yeah. When I say framework, we're ... a C++ programming language. Our 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.
CW (00:07:46):
So it's like an alternative to the native SDKs that you get with MacOS, 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 each of those native SDKs.
BW (00:08:09):
Well, that's exactly it then. I think some 20-25 years ago, a couple of Norwegian engineers were writing I think it's hospital software, to run on Mac and Window. And that's where the idea really came from is that they wanted to write the same application and run it on both different operating systems. So they wrote an abstraction which became Qt.
EW (00:08:31):
But it's more than an abstraction layer at this point.
BW (00:08:34):
Yes.
EW (00:08:34):
I mean, I can totally see the abstraction layer. I have actually written things for OS/2, Novell Netware, Windows, the same program in all of them. So I understand this pain.
CW (00:08:46):
Different century at this point, but yeah.
EW (00:08:52):
Yes. What was my question?
CW (00:08:55):
I don't know. You understand framework. Or you understand abstraction.
EW (00:09:00):
I understand hardware abstraction. I understand the operating system abstraction. But it does more than that now. Because I saw it listed Bluetooth and unit tests, which one of those is hardware, and one of those is a software piece to work on a software thing.
BW (00:09:21):
That's true. 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, so the Qt test 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 Qt test framework for our unit tests. So in our compile time unit testing kit are all written using Qt test. And there is a lot of software examples available for it.
EW (00:10:11):
When I invited you on the show, you were pretty quick to say you weren't an embedded software engineer.
BW (00:10:17):
Yeah.
EW (00:10:18):
But then you also say that you mostly work with embedded Linux and QNX devices running ARM chips.
BW (00:10:26):
Yes.
EW (00:10:28):
How do you define embedded?
BW (00:10:30):
It's kind of a gray area, really. And when I first started my career and 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 that 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. Yeah, it's kind of a gray area, I think.
CW (00:11:10):
When I first used Qt professionally, it was about 12 years ago now. 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 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. Yeah, so I think that definition is very gray, like you say.
BW (00:11:47):
It is. 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.
EW (00:12:08):
Qt has recently come out with Qt for MCU.
BW (00:12:12):
It has. This is more Harrison's side. Qt for MCU I think came out last year. And that's the 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.
EW (00:12:35):
Yeah. We can talk about it another time. But you did mention to me that in the almost decade you've been there, Qt has actually gotten smaller.
BW (00:12:47):
Kind of. Qt, in many ways, Qt and C++. We've added features all the time to Qt, and now the download's gone from about 200 megabytes to 500 when you download the whole source kit. So in terms of what's available, it's bigger. 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, 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.
BW (00:13:27):
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 and you could make it smaller and smaller so it would run better on the smaller, more resource-constrained devices.
BW (00:14:04):
But, ultimately, that still wasn't quite as small as we wanted to go, so that led onto, I guess, the Qt MCU project. So I haven't had that much to do with Qt MCU. I don't really know exactly what started it, because this was done over in Europe while I've been in the States. And I'm not important enough that they actually consult me for these things anyway. But, yeah, this came out couple of years ago. I think the first release was last year. And it's got it running on Qt MCU, or running on microcontrollers.
BW (00:14:36):
What I've seen, a few things from there, is I've also seen a few MCU features appearing in Qt. 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.
EW (00:14:54):
Qt Lite would let you work around these macros that would select what you wanted. Did I understand that right?
BW (00:15:04):
Yeah, pretty much. We always had this configuration framework which 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.
EW (00:15:37):
But what you're saying, we talked to Drew Fustini 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?
BW (00:15:55):
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 Yocto is working at the level of the application and the library, so it's similar.
EW (00:16:11):
And you said choosing code, not just choosing libraries.
BW (00:16:16):
Yes.
EW (00:16:17):
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. 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.
BW (00:16:41):
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're creating an embedded device and you would 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.
CW (00:17:19):
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.
BW (00:17:29):
Yes.
CW (00:17:29):
And that's the V3 version of LGPL, right? I think.
BW (00:17:34):
We changed some time recently. I think we changed to V3. Yeah.
CW (00:17:37):
Yeah. Okay.
EW (00:17:38):
Okay. So now the organization part. When I sit down and 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? How do I organize this?
BW (00:18:25):
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. When it comes to actual applications, we give a kind of layered structure to your application. So you've got all these numerous different IOs, various signals from various places. You probably want to put those into the same kind of directory. Maybe if necessary, divide them up, depending how many there are. So put your IOs into a single directory.
BW (00:18:56):
And business logic, assuming you have some of that, you probably do, why wouldn't you, would go into another directory, which would then read from the IO, the input. On top of that, you would perhaps have kind of a layer which connects to the UI itself. So in that sense, you've got three kind of lower layers kind of behind the scene.
BW (00:19:18):
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 three different sizes. So if you are using Qt, it's fairly easy to create a kind of scalable UI technology, 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 back end and the front end, 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.
EW (00:20:01):
And that's one of the things that I'm always in favor of. 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 the things at its level or above.
BW (00:20:23):
No. I think that's fairly well understood in embedded circles. But we do occasionally see customer who haven't got on to that point yet, but, yeah, basically.
CW (00:20:35):
And something I don't see in embedded that much, we're kind of talking around a paradigm that I think Apple kind of named. No, 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.
CW (00:20:58):
But the point to 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?
BW (00:21:10):
Yeah, pretty much. Qt, we have 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 will then be connected to a model. And the actual knowledge which knows about the model itself was set in a delegate class, which would then appear in your view. So, yeah, 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.
EW (00:21:44):
Yeah. 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 SPI, or do you put the files in an inc directory and put all the includes in one directory?
CW (00:22:03):
Maybe we should analogize to the large project we have in front of us. What does Qt do? Because it's huge, right?
BW (00:22:13):
It's huge. 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 have 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 Qt are in a separate place, and the libraries themselves are there for linking, and they're there separately for deployment.
EW (00:22:59):
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 kind of say, "Okay, Qt's here. Here are the libraries. Here are the include directories. 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.
BW (00:23:26):
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?
CW (00:23:37):
I am.
BW (00:23:37):
Great. It's the best IDE in the world.
CW (00:23:40):
I really liked it.
BW (00:23:44):
That will display them in logically separate areas of the file tree for you, which is useful. But first, you're storing on GitHub and working on the code, which is kept in the same place.
EW (00:23:56):
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 with a spider.
BW (00:24:08):
We have qmake tool. Because Qt is traditionally built around a project file, the .pro file, which lists everything in a single project. Chris, I guess you're familiar with qmake. 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 make file or whatever kind of file is used by your particular target platform. So in most cases, that's the make file button always. Since Qt 6, which is coming out, I think, next month, it still feels weird to think that it's November already and Qt 6 is due out in December.
CW (00:24:55):
Actually, when this show goes up, it will be December.
BW (00:24:57):
Sweet. Okay. So Qt 6 might or might not be out already. It's out in December. We're moving from qmake to use the more mainstream cmake as our make file generator. Which you're probably-
CW (00:25:13):
Aw. Sorry.
BW (00:25:14):
I know. I am 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.
EW (00:25:25):
Okay. So why cmake? Chris' response is actually mine too, which is, "cmake?"
BW (00:25:37):
I've checked when cmake and qmake came out, and cmake and qmake 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. 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 be used, and we would be able to use it without actually supporting it ourselves, which is useful.
CW (00:26:17):
That's fair.
BW (00:26:18):
[crosstalk 00:26:18]. It's a good tool. It's been around for a while. It's mature. And it's well supported.
EW (00:26:24):
How do you make these decisions? Because that's not the only open source thing that is also out there that Qt competes with.
BW (00:26:32):
Yeah. In terms of open source, we're not really competing with other projects. I don't have much insight into how the decision was made. It's done over in Europe by people higher up the chain.
CW (00:26:47):
Well, that's a support tool too, right? That seems like a more reasonable decision to say, "Well, that's not what we're making."
BW (00:26:56):
No. Yeah. We're not making [crosstalk 00:26:57]-
CW (00:26:58):
We're not making a compiler tool set, we're making this framework, so why would we continue to expend effort elsewhere, I guess.
BW (00:27:05):
Yeah. Yeah. That's basically in a nutshell.
EW (00:27:09):
You could say that about almost every piece of everything.
CW (00:27:14):
Never make anything.
EW (00:27:17):
Qt has threads. FreeRTOS has threads.
BW (00:27:26):
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 those 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.
EW (00:27:54):
Okay. That actually makes sense. This is about the cross-platform-ness of it.
BW (00:28:00):
Yes. We're cross-platform.
EW (00:28:03):
What about APIs? Because you have a lot of them. 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?
BW (00:28:19):
Oh my goodness, what a question. I was not expecting how ... Okay. This is kind of the philosophy of how Qt's designed and how it works. Some of our APIs have been around for quite a long time. 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.
BW (00:28:46):
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?
EW (00:29:03):
No, no, that's fine.
BW (00:29:04):
It's too big of a question. I'm just a humble consultant. The guys who actually designed the API, it's kind of trying to see every possible use. 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.
EW (00:29:31):
And that always happens. 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.
BW (00:29:43):
That's true. Yeah. And supporting that and predicting that is not really possible, in many ways.
EW (00:29:53):
As we were were talking in messages, you said that Qt uses what's called the PIMPL pattern. That seems unfortunately named. But what is it?
BW (00:30:08):
Well, it's not as unfortunate as it seems. At the time, the company was called Trolltech, and trolls, of course, are famous for their pimples, hence the PIMPL pattern. PIMPL is short for private implementation pattern, which is a Qt hallmark, really. 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 or Qt element or object provides a stable API. And then that API itself connects to an internal 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.
BW (00:31:13):
The private implementation itself, 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 inner 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.
BW (00:31:47):
And then we use qmake or cmake, 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 QSet Unix. If you're on Windows, then you get the QSet Window class included. So that's the PIMPL pattern in a nutshell.
EW (00:32:06):
So it's just a wrapper.
BW (00:32:07):
Yeah, basically, yeah. I mean, in some ways, you could say that a lot of Qt is kind of just a wrapper.
EW (00:32:12):
Oh, yeah, I guess so. I mean, that makes sense. That does make sense. Yes. Private implementation, PIMPL, that's some naming there, trolls.
BW (00:32:27):
Well, trolls are very Norwegian, and Qt is from Norway, so yeah.
EW (00:32:31):
Why are trolls Norwegian?
BW (00:32:33):
Yeah. This is a ...
EW (00:32:38):
So many questions I didn't put in the outline, huh?
BW (00:32:40):
Yes, you did. Well, no. Trolls are famously connected with Norwegian folklore, I think. I don't know that they were invented there, but they've been ... And European kind of ... I'm from Europe, obviously. I'm from the UK. And in that sense, we always kind of had an awareness that trolls or a Scandinavian kind of thing. Maybe that didn't cross the Atlantic.
EW (00:33:07):
I mean, I just knew they liked bridges and goats.
BW (00:33:12):
Norway's got a lot of bridges. Very many bridge. Great for hiding under. It's a beautiful place. You should check it out one day.
EW (00:33:19):
Yeah. I can never decide whether I want to see the midnight sun or the aurora borealis, and I know you can't do that at the same time.
BW (00:33:24):
Not easily. But if you stay there for six months, you could do that.
EW (00:33:30):
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?
BW (00:33:41):
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, I've 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 actually on the IC system, the instrument cluster. And 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.
EW (00:34:23):
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.
BW (00:34:29):
Basically, yes. So I've crossed duties. The Qt Quick UI itself or the Qt WebKit UI needs to be engaging in 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.
BW (00:34:56):
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. This one is not available as an open source product. That one, I think, in the notes you spoke about blinking lights. And that's where we provide the super safe SOB/SOD certified blinking lights.
EW (00:35:23):
I think in the notes I said I don't want lights to blink at me with useless nonsense while I'm driving.
BW (00:35:28):
You did say that, yes.
CW (00:35:31):
Unfortunately, there are certain requirements that some useless things must blink at you.
BW (00:35:36):
Well, it used to be 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 tell-tales are a thing where we have tell-tales which move around the screen. So if you can put a bit of tape on it, then the tell-tale's going to move anyway, so you can't do that anymore. So that's an improvement, I guess.
CW (00:35:58):
Your check engine light is just going to run away from you.
BW (00:36:04):
Yeah. It'll just move. It's like, "You can't do that." But those need to be certified to a certain standard so that they're not 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. And that's 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.
CW (00:36:36):
What's the specifics of that? That's very interesting. When I had a medical device, years ago, would that have been something I want to use for that? Or is it strictly automotive?
BW (00:36:49):
It's not. It's anywhere where you need something which is running to a higher degree of safety and a higher degree or risk management. So the Safe Renderer will run on medical. Well, it'll run anywhere you need it to. One of its natural applications is medical business as well as the automotive business.
CW (00:37:08):
What makes it safe?
BW (00:37:09):
What makes it safe? What makes anything safe? The Safe Renderer, whereas Qt has millions of line of source code and they're open source so 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 Safe Renderer, there's a lot less lines of code. And it's been written to a higher standard.
BW (00:37:36):
Are you familiar with MISRA and JSF coding standards?
CW (00:37:40):
The former.
EW (00:37:41):
That's right. Yeah.
BW (00:37:42):
MISRA. Yeah. JSF is not so well learned. It's not so widely used. But I like to mention it because it's kind of cool. It's the Joint Strike Fighter.
CW (00:37:49):
Oh, right, right, right. Okay. I have heard of that.
BW (00:37:51):
Yeah. But MISRA is the one that the automotive business use. It's 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.
CW (00:38:09):
Okay. So ground up, from the beginning, rewrite to be a certified. Okay, cool.
EW (00:38:18):
You used some other letters in there. We talked about MISRA and JSF. Those are standards we code to. What is ASIL-D?
BW (00:38:31):
Automotive Standards Integrity Level, I think. The S might be wrong. But the integrity level of the source code. A, B, C, 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, Qt's Safe Renderer is up to the high standard of the ASIL standard. So, yeah, it's good. It's good stuff.
EW (00:39:02):
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.
BW (00:39:17):
Yes.
EW (00:39:18):
What does that have to do with UIs in cars or vehicles?
BW (00:39:25):
Yeah. This is kind of a design question as much as anything else.
EW (00:39:30):
Are there standards that talk about-
CW (00:39:34):
Oh, I see what you're saying.
EW (00:39:35):
About how it should look?
CW (00:39:36):
You're talking about the end product, not the coding.
EW (00:39:38):
Yes.
BW (00:39:38):
Yes. Are there standards that talk about how it should look? They 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 tell-tale icons, 2575 icons. So those are the icons you need to use, and that's how it needs to look.
BW (00:40:14):
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 from 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.
EW (00:40:41):
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.
BW (00:40:55):
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? The Pinto. The engineers who created the Pinto 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 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 as safe as possible.
EW (00:41:37):
One of the questions we get a lot is, how do I go from pure software or web development to embedded?
BW (00:41:46):
Uh-huh (affirmative). Yes.
EW (00:41:47):
And you did that. How did you go from web and java development to where you are now?
BW (00:41:54):
That I would say was persistence and not giving up. I guess I always wanted to be an embedded developer, and that's probably 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 an easy job to get into and web development now is very different than it was back then. But then it was a fairly simple job. But obviously that wasn't what I wanted to do.
BW (00:42:29):
With help from my parents, they gave me the money for the ticket, I flew out to Finland. Which I had finished my degree. I finished there as an exchange student. 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.
BW (00:42:51):
At the time, it was kind of good timing because I had just finished my degree, and I had just finished studying Java as a language as well as others. So I knew Java. At the time, not many people 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.
BW (00:43:17):
So the company I went to work for, a company called Mentor Graphics, were looking for Java developers, and they couldn't really find any. So I turned up at the right time. 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 foot in the door.
EW (00:43:39):
And then being in the town and working for Mentor Graphics, did that start to push you over to the C++ side?
BW (00:43:46):
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 onto other positions in the embedded world.
EW (00:44:14):
And so 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."
BW (00:44:26):
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." And wanted to do this, and kept asking until someone let me.
EW (00:44:39):
Persistence, it pays off.
BW (00:44:40):
Yes. Gets you to California, actually, somehow.
EW (00:44:44):
And now that we're headed towards mid-winter, I bet California versus Finland has some advantages.
BW (00:44:51):
Well, you can make better snowmen in Finland, but it's a little bit warmer in the afternoon in California at least.
EW (00:45:03):
A little bit. Do you have any advice for people who want to follow a career path like yours?
BW (00:45:10):
Keep trying, and don't give up. You will find in the early days there's a lot of pushback, or a lot of people will not be terribly interested. But if you keep on going, you'll eventually find something. You will actually get something.
BW (00:45:26):
I actually have some better advice than that as well. My first boss in Mentor Graphics, this American chap called Greg, one night we were out and he said to me, "Rebecca," or Becky, "If you're always willing to travel for the company, companies really appreciate people who will travel, because most people won't." So yeah, that's helped a lot, being willing to travel and going to see customers. Although perhaps not relevant now because of pandemic, but back then.
CW (00:45:53):
Right. Some day.
BW (00:45:55):
Some day. I think most of my traveling days are now behind me, which is kind of sad but kind of good.
CW (00:46:03):
I had a couple questions going back to the innards of Qt. Wow. I used it for a number of years, 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 concepts like signals and-
BW (00:46:27):
Signals and slots, yes.
CW (00:46:28):
... connections. So it makes some things about C++ and the object-oriented nature of it a little bit easier, because you can communicate between your objects in a much more intuitive way. I don't know if I'm describing it right.
BW (00:46:44):
I think that's a good description, Chris.
CW (00:46:46):
It's almost like a message passing thing instead of making function calls.
BW (00:46:51):
It makes C++ fun.
CW (00:46:52):
And that's how a lot of the UI's designed. So they're these language extensions, and they're all built on top of C++. You may not have an answer for this. 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 supersede some of the stuff in Qt. So has that been a problem, or has that been easy to manage? Or is that something that just don't need to worry about?
BW (00:47:26):
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 example of QThread earlier when I spoke about POSIX threads and Windows threads, you could probably do that all with STD thread now, which in itself is a wrapper to POSIX and those threads.
BW (00:47:57):
Qt does absolutely extend C++. We have smart pointers, of course. You can get smart pointers in C++ since C++ 11. But they've been in Qt for some time. And we've had signals and slots in the connection, 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. Can I just get a refresher on what the question was? Is it a problem having these things in C++?
CW (00:48:30):
It was more, as C++ develops, is it a challenge to keep them in sync or figure out what things to deprecate, I guess?
BW (00:48:39):
Not really. I guess the APIs, 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 you said, of course, now that that's duplicated very nicely by STD thread, we need to keep it, of course, because we need to keep systems which were using QSet in the past running, so we can't just get rid of it. But as far as I'm aware, it hasn't been rewritten yet. Or I don't think it will be rewritten to use that for some time. But, yeah, eventually, you can just kind of switch to that, I guess. It's not really a huge problem particularly.
CW (00:49:29):
Okay. Is there an idea of support for other languages? I know there's PyQt, right? So is that for first class, or is that just something that kind of hooks in? I don't remember how this works. If you want to use Qt, do you have to use C++, I guess is what I'm asking.
BW (00:49:47):
Yeah. That's a fair question. You don't have to use C++. There is PySide, which is the Qt Python extension. PyQt I think comes from a different company from us. Not that you shouldn't use PyQt if you'd 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.
BW (00:50:11):
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++.
CW (00:50:33):
Are you all paying attention to Rust, or is that not on the radar?
BW (00:50:40):
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 that here.
CW (00:50:51):
I'm just heading off the emails.
EW (00:50:53):
Oh no, you're making the emails go to Qt instead of us.
CW (00:50:57):
I'm redirecting them?
EW (00:50:58):
Yeah. 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."
CW (00:51:16):
Sell us on that. [crosstalk 00:51:19]-
BW (00:51:21):
I'm not familiar with Python GTK. I might have deferred 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. Don't tell anyone I said that.
CW (00:51:50):
Don't worry.
EW (00:51:52):
We won't tell anyone.
CW (00:51:54):
It's only a podcast.
BW (00:51:54):
Okay. Super. We have this wonderful Qt world summit which you should come to and meet all the Qt people. We'll go out for a drink. You'll be sold. That's the best I can do.
EW (00:52:06):
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. We've talked about how big it is.
BW (00:52:21):
Yes, it's huge.
EW (00:52:23):
But I was a little gobsmacked.
CW (00:52:28):
Overwhelmed?
EW (00:52:29):
Overwhelmed. Somebody out there is listening, 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?
BW (00:52:49):
We do have a very good getting starting guide. 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 getting the Qt installed or installing kind of just a regular Qt with Qt Creator, 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 with the documentation itself. Or those Qt Creator examples. So those are the basic if you're doing it yourself kind of getting running approaches.
BW (00:53:41):
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 aim for.
BW (00:54:01):
Linus Torvalds recently, he has a scuba diving application which was I think written using GTK, and he, 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 that 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. We have a great community. We're read to help. So, yeah, get involved with the community as well.
CW (00:54:34):
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 that the books that I had are now out of date. I think I had C++ GUI Programming with Qt4, which I do not think has been updated to Qt5. That didn't even cover QML or anything.
BW (00:55:00):
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 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 event loops 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 kind of the basics like your objects, 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 all we can as well as bespoke customer based one too.
EW (00:55:55):
As I was looking around, I ended up in the sennsor section because-
BW (00:55:59):
In the what section?
EW (00:56:01):
Sensors.
BW (00:56:02):
Sensors?
CW (00:56:03):
Qt sensors.
BW (00:56:04):
Oh, sensors. I thought you meant with a C, but you meant the S.
CW (00:56:07):
I know.
BW (00:56:09):
I didn't know there was a censored part. Anyway.
EW (00:56:12):
Yes. And the example they used was a Grue sensor, G-R-U-E. And I was so confused until I realized that they were actually looking for Grue monsters.
CW (00:56:24):
From Zork.
EW (00:56:25):
From Zork. Their example sensor was pretty hilarious once I understood what it was.
BW (00:56:34):
I'm glad that was amusing.
EW (00:56:38):
Are the other examples amusing, I guess is the first question.
BW (00:56:41):
I don't think so. I'm interested now to know who wrote that, because not all of our examples are written by the Qt Company. Some of them are from KDAB and ICS and various other contributing parties. So it's entirely possible that the Grue sensor was written by some individual. I don't know who wrote it. May not have been actual Qt Company. It would be nice to look into that. And I'm sure we could find that on GitHub. It's a nice one, I think. Yeah. Definitely. Not all of our examples are like that though.
EW (00:57:20):
Is learning Qt a good way to learn C++? Or do I really need to know C++ first?
BW (00:57:28):
I would suggest a basic foundation in C++. Qt does make C++ easier to use in many ways. We have the 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.
EW (00:57:51):
Than the C that I use that is sort of object-y, and uses classes, but doesn't use any of the fancy C++ features.
BW (00:57:59):
You use C with classes? Like Stroustrup's original...
EW (00:58:01):
Well, I use C++ because I like the booleans. But, no, many of my compilers still don't support the good features.
BW (00:58:12):
Yeah. I don't know how well Qt MCU would run on this. Definitely worth asking someone about that.
EW (00:58:16):
All right. Well, I think we have kept you for, well, I think maybe a little longer than we promised. Let me ask you, let's see, Qt is hiring for the Bay Area?
BW (00:58:32):
Yeah. Qt, our professional services are very busy right now. We're overwhelmed. And we're always happy to consider new Qt engineers or C++ or embedded engineers. So, yeah, so, 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.
EW (00:58:56):
Is there a good place to get in touch? And we can put it in the show notes, really. That's probably the right place for it.
BW (00:59:03):
Yeah. I think they go to the Qt.io website and look at our careers page and apply that way is probably the best way. I'm not sure if I should give out my boss' email. He might be unimpressed. He's a nice guy.
EW (00:59:21):
No. But you can often email us here, and we're happy to pass along your emails to our guests.
BW (00:59:26):
Sure. You can do that too. Yeah, you've got my email address, of course.
EW (00:59:31):
And, Becky, do you have any thoughts you'd like to leave us with?
BW (00:59:36):
Read the manual. No. Yes. Forget the manual. Read the source code.
EW (00:59:41):
Yeah? Okay. Our guest has been Becky Worledge, Qt consultant with the Qt Company. And we've also had Harrison Donahue, Embedded listener, and Business Development Manager for Qt for MCU.
CW (00:59:56):
We pronounce it differently in every sentence.
EW (00:59:58):
That's my goal. Every time I say it, I'm going to say it a different way.
CW (01:00:02):
Thanks, Becky. This was fun.
EW (01:00:04):
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@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.