From Gtk to Qt: An Strange Journey, part 2
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Canabrava, Tomaz
As subsurface evolved from a Gtk Application to a Qt one, cutting a quarter ofthe codebase while still gaining new functionalities, a new developmentproposal was done: "How do we get this desktop based application and run it onmobile, on a unified codebase?" How do we get a kernel developer application writed in kernel-style code forthe desktop and make it universal, running in any operating system, mobile anddesktop? On this talk I'll present you piece-by-piece history on what we had whenSubsurface started, the chalenges that kernel hackers faced when creating adesktop application and why the choice was made to port away from Gtk into Qt- even tougth the main developer of subsurface back then loathed C++. After the initial port to Desktop a new era began, the era of MobileApplications, and Qt had launched it's new Qml language that promissed goodintegration on mobile and even desktop with minimal effort. We wanted to giveit a try. At the same time the KDE hackers launched a new idea "Kirigami", alibrary build on Qml to simplify development of Qml based software, and sincewe where already on the bleeding edge of things, why not give it a try? This is the tale of Subsurface, From Gtk to Qt to Mobile, from one of it'smain hackers.
 I think I need to start talking. As usual, I was finishing my slides just five minutes before the talking starts, which means that I never finished my talk, which is quite okay because I never actually finished anything that I started like I'm still 10 years on the university. No, 12, sorry. When I started doing programming, I was five years old because my dad is crazy. I grew up, I started doing other stuff, and one day I was seated in my computer trying to program, and I saw this. This was an invitation for cute developers to start trying to part an application that was initiated by Linux Torvalds using CNG2K and then I was thrilled. Because, well, as a kid, I always wanted to actually start programming with my heroes of programming. Like, I am a nerd for my whole life. I had my first computer when I was two or three years old. It wasn't Atari. I don't even know if they make them anymore. Dirk Hondo was a second in command of the Linux kernel, he started this programming with Linux Torvalds. It's a dive in application. I never dive it in my life. But I really wanted to do one thing. Well, I like to experiment with new things. So I did origami. After origami, I felt that I was an okay origami artist. So I did pole dancing. I did one or two years of pole dancing lessons. I tried to do a semi-professional pole dancing presentation in Brazil. But then I started doing theater. After I ended on the theater, I was a KD developer and Fizzle. Fizzle is the biggest free software convention in Brazil. We have 10,000 people going there annually usually. Well, I don't feel shame about that. Then I started tap dancing for some reason. But I really wanted to program something with Linux. Mostly because Linux thinks that C++ has horrible language, and it's made more horrible by the fact that a lot of substandard programmers use it. Hello. To the point where it's much easier to generate total and utter crap with it, quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that itself would be a huge reason to use C. Yeah. I made Linux. I'm not afraid of that. I actually put that on my resume. It is awesome because I was yelled two times to today, which is nice because usually Linux don't just yell. He throws people on the windows. If I have time later, if anyone do the question, I will give the fest. Not for you. You have fest. So I really like to be a vector entropy. I like to make Linux use C++. I like to make my wife that is there afraid of me sometimes. I like to make my brother say, oh my God, no. Well, I put my pole dancing picture on his Facebook profile. Then I downloaded the Git source from subsurface. Oh man. It was UI application done by kernel developers. It was a really big spaghetti code. Nothing was happening as I wanted as a UI developer. I know that I need separate code. I need to do some stuff as MVC and Linux told me that, well, that's just it. You have no game from doing that. Yes. So those were the original problems that I saw on the original code base from subsurface. There is no separation between the UI and the car whatsoever. The lack of the knowledge in the original library. Now I need to stop a little bit because I am a Qt developer and the application was GTK developer GTK developed. GTK and Qt are usually seen as fighting with each other, but that is not just true. The problem on this application regarding GTK is that the developers of the application, Linux and Dirk, usually, they didn't know how to use GTK. It's not GTK's fault. The fault of GTK there was they didn't found people on GTK to help them. The lack of UX, well, they are kernel developers. They don't care about UI, but they really needed to do something quite pretty if they want people to use it. And they had in the time 50 users, now they have more than 3,000. So good. Lack of integration in the base systems, they had an application that looked like really almost not UterCrep on Linux. And it looked like UterCrep on OS 10 and Windows. It worked, but it was not integrated whatsoever. And lack of anyone who give it a shit because nobody was actually helping them to do anything. So they did, sorry, that they invited people to try to help. And I saw this. I was borrowed in my work and I saw this. And since I was doing nothing in my work, I was paid to just stare off the roof, I used my work time to develop Super Surface. And this was the original subsurface code. Well, not really, but mostly like that. I mean, they had around 10 files for everything. It was scary. It's still scary. Because on the parts from C2C++, I had to stick with a lot of the C parts and the C++ parts. And well, it's now like this. After two months of work, I've managed to separate the core and the interface. I'm going to show a little bit of the code. I'm going to show the interfaces. But I have no experience doing presentations. I usually am a latex guy. So it's usually worse than that. Core, it's a mess. And the interfaces is still a mess. Because I am the only one that knows how to do the interface. And the core being a mess, I cannot actually make a really good code for the interface, because I have to deal with the mess that is the core. And well, mess, mess, mess, mess, mess, mess, mess, mess, no, no, no, no, no, not that. This. So you know that there is far on C++ and that we can iterate over collections. But because the core is right in C, our collection is actually a linked list to write in C. And we have for each something for all of our types. And I have to use this. Is it a macro? It's a macro. OK. Back, back, back, back, back, back, back, back, back. Here. No, not here. Here. So the core is not my responsibility. The core is a responsibility from Linus and Dirk. And I actually don't want to touch the code, because, well, there is a function. There is around 1,500 lines that I could replace by three lines in C++. That's the reason that I don't want to touch the core. So I done my work on the interface. And on the interface, I did a massive entanglement. But I couldn't really do what I wanted, because both UIs needed to coexist for a while. The GTK should continue working. And I had to create the kutes based on the same core. So I couldn't really break anything. And as little changes as possible in the core, because the core people are C, and they still want to use C. So I fixed the spaghetti codes. And now I had this. I had a few classes that meagled the top window, the main window, the models for the data structure. On the C, everything was done inside of the interfaces. Now we have a somewhat clear MVC model for that. And there was one file that had 15,000 lines that created all of the graphs. Oh, let me try to show you this application, because I'm not sure if you guys know what I'm talking about. Oh, that. Where's the mouse? Help me find the mouse. So this is subsurface. And this is basically one of my hobbies nowadays, after theater and tap dancing and origami. This graph here, it has more than 17 different types of graph running here. And this little part here, it's 200 lines of code. Usually, the size of this graph in the C code was around 15,000 lines, but it only had six graphs. Now it has 17 graphs, and the size is the same, because we actually managed to organize the code in a way that worked. Actually, really cool. If you guys like to dive, I have no idea what a dive is. I've done a diving lessons after three months working on the system to actually understand what the hell I was doing. This is a dive to 100 meters and going up slowly for more than 14 minutes. Yes? Microphone? Take it. Hello. How are you? Fine. Thank you. Good. So and now, this is a profile. And right now, this is a lot of different files. And each curve is a different class. And because of that, we could actually manage to make it a lot more than that. They only have lines. I mean, measure the graphs. We can put some on. Make them to the mouse. Out. And get multiple. So we can put more graphs in the same stuff. And then we can put this out. Out. And there is a little bit of communication. It's not really good because I don't know how to make it. But there is a lot of things. So I'll go down. There is dynamic stuff here that you couldn't do on the GCK part. Not because the GCK doesn't serve for that, but because the guys that did the GCK all didn't know how to do that. So this is the application that I'm showcasing now. Yes. Hello. Working? One, two, three. OK. I would. But I have a bigger problem than that than you see in the lens of the thingy, where I was here. So now, that application works. We already have a lot of users, and it's working on a lot of computers. We have every programmer is on Linux, but the most user base is on Windows, which is a problem because we have one Windows developer. That's not paid to work on subsurface. Actually, nobody is actually paid to work on subsurface. We do it because we want to try to see if he can scarlinus and make him annoy us. Now, remember this interface. How can we put that thing inside of this? It is too big. I mean, the interface is too bloated. There is a lot of information. There is no native code there. I mean, we are using Qt Widgets. Qt Widgets will work on different operating systems, but it's not prepared to work here. It has a deep integration with Qt Widgets. I mean, there is buttons, there is lists, there is text, there is everything here is Qt Widgets. Besides the graph, the graph is my code entirely and not a really good one. And there is a globe here. That is pretty. And you don't need a globe if you are trying to run this on a mobile because on Android, you already have the maps and on iOS, you also have the maps. So we can just remove this. But the problems are there is six tabs there. That's too much information. There is 17 possible graphs here. I cannot show 17 possible graphs here. There is no space. And there is 15 columns that you can show on this list, which is quite too much. As you can see, this program was not thought at all to run on a mobile. And this was a problem. But we managed to build it and we run it completely like that inside of... I don't remember the name of the tablet, but it was an Android tablet and it run. But, well, it was made for the mouse. It was hard to use. It was made for the mouse not fingers. So you try to click on one thing, you click on three things at the same time. It didn't felt like a mobile application. And the dialogue, the files should be reshared somehow, some way. And the application didn't have access to the Android's operating systems to actually get the files. Because Android and iOS, they have some strange ways of having any file that you want. It's not really like a UNIX-based system or a Windows or anything. So it was...it worked. But it didn't really...it worked. And it enters LibiGit. And the clowns. LibiGit is awesome. And I'm not sure if anyone here did that because they didn't thought that this was possible with Git. But we are actually using Git as a file. Not as... What do you use Git for? Sorry, yes, repository. We are not using Git for a repository. We are using Git as a file format. Which is awesome. Because now we are storing everything in the Git, not as a text, not as an XML file. We are using Git storage information to save the dive. Which is quite okay. And it's fast. And we can apply GIFs over files. And if we sync something, we can just do a Git pull and pull only the difference of the Git repository. Which is awesome. Because that file that I opened here on subsurface, it has 80 megabytes of data. Because the guy that did those dives is just stupid and he dives with four different dive computers to test the software. Yes, I still think that he's crazy. And that's Linus, by the way. But with Git, we have a lot of things. We can add something and we can compare GIFs. So it's really good for a programming perspective because we can diff the file format that it generated. And it's easy to spot regressions. It's easy to improve. You get a Git repository for free. So you can send your dives to Git hub and then just Git pull. And you can use that to get the files on the computer and on the mobile. And because of that, we created the subsurface cloud service that is also free. Well, it's free for the users because Linus is paying for that. And the problems of the Qt really gets that I said before. It's proven. It works. It will not crash. It's really lightweight. I mean, really, really lightweight. For people that thinks that Qt is not lightweight as GTK, for instance, if you use the same stuff from GTK and from Qt, they both will use the same amount of memory on your computer. So not really difference. And it's still used for everything. And there is Kim. Oh, OK. It can use the card directly, means that I can call the C code that the code is made of. And I've done that. I showed that before. So I'm going to just pull over that. And it enters KML. People here do you know KML? Two, three, four. OK. Quite much. KML is something that Qt created not a long time ago, because when Qt was social Nokia and then Nokia was another company, and then another company split into other company, how can people trust that if the company is not solid? Well, you guys know Bentley, right? Bentley uses KML. You guys know Tesla. Tesla uses KML. You guys know Mercedes, BMW. They are starting to use KML. Samsung is using KML. So how can you trust a company that's never really solid and stable? I'm not sure. They do trust for some reason. And one of the reasons is that this thing can run everywhere on desktop, on mobile, on Kinect. Do you guys know Kinect? Yep. So Kinect is one of the most used operating systems for vehicles, for cars. And it's being used currently on embedded systems. It's being used currently on airplanes, on cars, on smartphones, on drones, on fridges, on boats. And I actually did the first drone using KML. It was amazing. I crashed at three. Literally. Literally. Yes, literally. Because when you have the drone and you have no idea how to counter it, well, that was my first crash. And then I actually, I put some parachutes on it. So it wouldn't actually crash that way. And then on my job, I had to replace an arm core and change it to Intel. I was Intel developer. So we were trying to make the drone work on an Intel chip. The problem, ah, the problems. Intel chip was too slow to actually do the mathematical calculations that we needed for the drone on the first trial. And it completely collapsed when it started to roll down on the sky and crash it. And the parachute didn't work it because it tried to open, but it was spinning. It was awesome. We have the video for that. And KML started a long time ago when this was considered a smartphone. This was... It was awesome. It was awesome. Yes, it was awesome. It worked. It was the green phone. Thank you, because I forgot. It was a little bit sluggish because we didn't actually have the OpenGL working on that thing back in the time. But it was the first trial of having something declarative to work. It used a tilt widget, so it had a lot of libraries to load. It was a little bit bloated, but it worked. It worked on OS X. It worked on Linux, Windows, Kinects, Android, iOS. And now you remember probably on the university or when you guys were starting to program or you heard this, that Java is compilers run everywhere. But it's not because you have Java say, Java me, Java something. And here you have actually a C++ code that you can code once and run everywhere. You have to modify a little thing here and there sometimes, but it usually works. And it's KML, a language that runs on top of V8. V8 is the library from Chrome to run JavaScript. But it was a little bit modified to load small files instead of big JavaScripts. And it also uses a Git. And it can interact directly with QObject. So if you have in your program a QObject, you can just pass it to the V8, to the KML engine. And it can interact with it. You can call the properties. You can call the functions. But it doesn't interact with C codes now. My whole core is in C. How the hell am I going to interact with it? I cannot. So I need to do. Oh, sorry. There is no drawing primitives on KML, which is also a bummer, because if there is no drawing primitives, I cannot do the profile. The profile is the little fancy graph. On KML, I can do rectangles. And I can do texts. And I can do a combination of rectangles and rects. For real. For real. I don't have anything on KML that is more than a combination of rectangles and texts and maybe a PIX map. Can you not load or secure it at some point? No. You can't. You can't load any kind of QTweet to get inside of KML. Unless you go to C++ and you create a new KML object that loads the PIX map for that widget. So there is nothing ready for that. But it can interact directly with Qpainter. So you could use Qpainter for that, but it's not really performance because it is done in OpenGL. And if you use Qpainter, you are interacting actually with PIX maps. And the act of sending a PIX map to OpenGL, every frame is time consuming. And you can also use JS canvas because KML is built on top of JS. And JS has a canvas. You could use that not performance. Don't do that. Nobody does that. Don't even try to do it. Well, actually, we on KDE, we are doing that. We have three libraries for that. Because we had to experiment. And for a desktop, that's mostly OK, but not for a mobile. Mobile doesn't have the power as a desktop has. So we could not use that because our graph is just huge. This is painful. So Stratdive uses a double-linked list with two pointers that have a few other members as a seed pointer that has a few macros to work on it. And we need to transform that on the C++ object to throw this to the KML. And create a model because NVC and KML are made to be used together. So let's duplicate the code. And by duplicating the code, we actually managed to make this to work. And now KML has code to deal with dives and related things because, well, we need to work with dives. But it was painful. But it worked. This is an actual picture of the program working on drives. And it's even blinking because it was really a lot of work to make this work. It was two summer code projects because the first one the guy just gave up and never answered our calls. It was not really good. But we still had the problem with the profile. Oh, this is using Kirigami. Do you guys know Kirigami? Yep. So Kirigami is a library that the KDE developers are building on top of KML to make the application not use the device-specific information for widgets. We want to use something five minutes. OK, I need to run. We need to... Damn it, I hate to run. We need to show the application as a unity everywhere. Every device should have the same face. So we started to use in KML. Kirigami, sorry. But the profile was also a problem. And we couldn't use JS Canvas. We couldn't use the OpenGL by hand because OpenGL by hand is just too painful and I don't have the time to learn that. If anyone of you knows how to use OpenGL by hand, please help us. We had KDE charts, Q-charts, and we could try to export our current charts somehow. I tried Q-charts and Q-charts and none of them worked for what you want because you already talked about this. No current charting library had what you had, what you wanted, because we wanted to put a lot of axis overlapping on top of each other. We wanted to make them not really show because we already have the information on the curve. We wanted to invert some axis to show the graphs upside down. It was hard to do that in a pretty way using the current things that we could. So we parted everything that we could to KML. And the profile, the Q-tweetget that you told us, how can you put a Q-tweetget? We had to write a C++ class. And it's a little bit of magic because we had to do this bit of code just to make it show correctly on the screen. I'm thinking that you can read this. It's not made for reading, it's just because I want to show you how we did it. And there is a lot of magic functions there. There is a lot of magic numbers that we have no idea why they are there, but they seem to work. Yes, and it's working. It appeared. And we are happy and this application is actually running here in my iOS that I can try to show you. Ah! This is the application. I don't have access to the data right now, so I cannot show you running that, but it's loading. Woo! So we still have a lot of code on C. We still have the lack of an actual KML developer because I am a Qt developer, Qtweetget. I've done 10 or 12 years of C++ development with Qt for the desktop. My head doesn't work for KML. And we have a constant API breakage on KML because we have KML controls 1, 2, they are incompatible. We have Kirigami 1 and 2, they are compatible, but they are using KML 1 or 2 that are incompatible. So we had a lot of issues on that. And it's hard to get the documentation because they are still creating it, so... hard. So we need more people, please, if you guys want to try to work with Linus and annoy him, please join. Yes, we need artists, we need testers, we did divers, preferably programmers. Yes. And it's actually true. Come join us, you might meet Linus and he will pay you a dive someday. And questions? Sorry, I don't have the time. I have a plane to catch right now and I need to run. That's all. And I finished it in time, which is more awesome. So I think I have one minute. Anyone has a question? Yes. Have you looked into rendering the rough using shader or having multiple shader effects on top of each other? We look into that, but for that we need to know OpenGL. I have no idea OpenGL and you won the fest. Thank you. You're welcome. So people, thank you very much. And I really need to catch a plane. Okay. Okay.
 I think I need to start talking.  As usual, I was finishing my slides just five minutes before the talking starts,  which means that I never finished my talk,  which is quite okay because I never actually finished anything that I started like I'm  still 10 years on the university.  No, 12, sorry.  When I started doing programming, I was five years old because my dad is crazy.  I grew up, I started doing other stuff,  and one day I was seated in my computer trying to program,  and I saw this.  This was an invitation for cute developers to start trying to  part an application that was initiated by  Linux Torvalds using CNG2K and then I was thrilled.  Because, well, as a kid,  I always wanted to actually start programming with my heroes of programming.  Like, I am a nerd for my whole life.  I had my first computer when I was two or three years old.  It wasn't Atari.  I don't even know if they make them anymore.  Dirk Hondo was a second in command of the Linux kernel,  he started this programming with Linux Torvalds.  It's a dive in application.  I never dive it in my life.  But I really wanted to do one thing.  Well, I like to experiment with new things.  So I did origami.  After origami, I felt that I was an okay origami artist.  So I did pole dancing.  I did one or two years of pole dancing lessons.  I tried to do a semi-professional pole dancing presentation in Brazil.  But then I started doing theater.  After I ended on the theater,  I was a KD developer and Fizzle.  Fizzle is the biggest free software convention in Brazil.  We have 10,000 people going there annually usually.  Well, I don't feel shame about that.  Then I started tap dancing for some reason.  But I really wanted to program something with Linux.  Mostly because Linux thinks that C++ has horrible language,  and it's made more horrible by the fact that a lot of substandard programmers use it.  Hello.  To the point where it's much easier to generate  total and utter crap with it, quite frankly,  even if the choice of C were to do nothing but keep the C++ programmers out,  that itself would be a huge reason to use C.  Yeah. I made Linux.  I'm not afraid of that.  I actually put that on my resume.  It is awesome because I was yelled two times to today,  which is nice because usually Linux don't just yell.  He throws people on the windows.  If I have time later,  if anyone do the question,  I will give the fest.  Not for you. You have fest.  So I really like to be a vector entropy.  I like to make Linux use C++.  I like to make my wife that is there afraid of me sometimes.  I like to make my brother say,  oh my God, no. Well, I put my pole dancing picture on his Facebook profile.  Then I downloaded the Git source from subsurface.  Oh man. It was UI application done by kernel developers.  It was a really big spaghetti code.  Nothing was happening as I wanted as a UI developer.  I know that I need separate code.  I need to do some stuff as MVC and Linux told me that,  well, that's just it.  You have no game from doing that. Yes.  So those were the original problems that I saw on  the original code base from subsurface.  There is no separation between the UI and the car whatsoever.  The lack of the knowledge in the original library.  Now I need to stop a little bit because I am a Qt developer  and the application was GTK developer GTK developed.  GTK and Qt are usually seen as fighting with each other,  but that is not just true.  The problem on this application regarding GTK is that  the developers of the application, Linux and Dirk, usually,  they didn't know how to use GTK.  It's not GTK's fault.  The fault of GTK there was they didn't  found people on GTK to help them.  The lack of UX, well, they are kernel developers.  They don't care about UI, but they really needed to do  something quite pretty if they want people to use it.  And they had in the time 50 users,  now they have more than 3,000.  So good.  Lack of integration in the base systems,  they had an application that looked like really almost  not UterCrep on Linux.  And it looked like UterCrep on OS 10 and Windows.  It worked, but it was not integrated whatsoever.  And lack of anyone who give it a shit because nobody was  actually helping them to do anything.  So they did, sorry, that they invited people  to try to help.  And I saw this.  I was borrowed in my work and I saw this.  And since I was doing nothing in my work,  I was paid to just stare off the roof,  I used my work time to develop Super Surface.  And this was the original subsurface code.  Well, not really, but mostly like that.  I mean, they had around 10 files for everything.  It was scary.  It's still scary.  Because on the parts from C2C++, I  had to stick with a lot of the C parts and the C++ parts.  And well, it's now like this.  After two months of work, I've managed  to separate the core and the interface.  I'm going to show a little bit of the code.  I'm going to show the interfaces.  But I have no experience doing presentations.  I usually am a latex guy.  So it's usually worse than that.  Core, it's a mess.  And the interfaces is still a mess.  Because I am the only one that knows how to do the interface.  And the core being a mess, I cannot actually  make a really good code for the interface,  because I have to deal with the mess that is the core.  And well, mess, mess, mess, mess, mess, mess, mess, mess,  no, no, no, no, no, not that.  This.  So you know that there is far on C++  and that we can iterate over collections.  But because the core is right in C,  our collection is actually a linked list to write in C.  And we have for each something for all of our types.  And I have to use this.  Is it a macro?  It's a macro.  OK.  Back, back, back, back, back, back, back, back, back.  Here.  No, not here.  Here.  So the core is not my responsibility.  The core is a responsibility from Linus and Dirk.  And I actually don't want to touch the code,  because, well, there is a function.  There is around 1,500 lines that I could replace by three lines  in C++.  That's the reason that I don't want to touch the core.  So I done my work on the interface.  And on the interface, I did a massive entanglement.  But I couldn't really do what I wanted,  because both UIs needed to coexist for a while.  The GTK should continue working.  And I had to create the kutes based on the same core.  So I couldn't really break anything.  And as little changes as possible in the core,  because the core people are C, and they still want to use C.  So I fixed the spaghetti codes.  And now I had this.  I had a few classes that meagled the top window,  the main window, the models for the data structure.  On the C, everything was done inside of the interfaces.  Now we have a somewhat clear MVC model for that.  And there was one file that had 15,000 lines that  created all of the graphs.  Oh, let me try to show you this application,  because I'm not sure if you guys know what I'm talking about.  Oh, that.  Where's the mouse?  Help me find the mouse.  So this is subsurface.  And this is basically one of my hobbies nowadays,  after theater and tap dancing and origami.  This graph here, it has more than 17 different types  of graph running here.  And this little part here, it's 200 lines of code.  Usually, the size of this graph in the C code  was around 15,000 lines, but it only had six graphs.  Now it has 17 graphs, and the size is the same,  because we actually managed to organize the code in a way  that worked.  Actually, really cool.  If you guys like to dive, I have no idea what a dive is.  I've done a diving lessons after three months working  on the system to actually understand  what the hell I was doing.  This is a dive to 100 meters and going up slowly for more  than 14 minutes.  Yes?  Microphone?  Take it.  Hello.  How are you?  Fine.  Thank you.  Good.  So and now, this is a profile.  And right now, this is a lot of different files.  And each curve is a different class.  And because of that, we could actually  manage to make it a lot more than that.  They only have lines.  I mean, measure the graphs.  We can put some on.  Make them to the mouse.  Out.  And get multiple.  So we can put more graphs in the same stuff.  And then we can put this out.  Out.  And there is a little bit of communication.  It's not really good because I don't know how to make it.  But there is a lot of things.  So I'll go down.  There is dynamic stuff here that you  couldn't do on the GCK part.  Not because the GCK doesn't serve for that,  but because the guys that did the GCK  all didn't know how to do that.  So this is the application that I'm showcasing now.  Yes.  Hello.  Working?  One, two, three.  OK.  I would.  But I have a bigger problem than that  than you see in the lens of the thingy,  where I was here.  So now, that application works.  We already have a lot of users,  and it's working on a lot of computers.  We have every programmer is on Linux,  but the most user base is on Windows,  which is a problem because we have one Windows developer.  That's not paid to work on subsurface.  Actually, nobody is actually paid to work on subsurface.  We do it because we want to try to see  if he can scarlinus and make him annoy us.  Now, remember this interface.  How can we put that thing inside of this?  It is too big.  I mean, the interface is too bloated.  There is a lot of information.  There is no native code there.  I mean, we are using Qt Widgets.  Qt Widgets will work on different operating systems,  but it's not prepared to work here.  It has a deep integration with Qt Widgets.  I mean, there is buttons, there is lists, there is text,  there is everything here is Qt Widgets.  Besides the graph, the graph is my code entirely  and not a really good one.  And there is a globe here.  That is pretty.  And you don't need a globe if you are trying to run this  on a mobile because on Android,  you already have the maps and on iOS,  you also have the maps.  So we can just remove this.  But the problems are there is six tabs there.  That's too much information.  There is 17 possible graphs here.  I cannot show 17 possible graphs here.  There is no space.  And there is 15 columns that you can show on this list,  which is quite too much.  As you can see, this program was not thought at all  to run on a mobile.  And this was a problem.  But we managed to build it and we run it completely like that  inside of...  I don't remember the name of the tablet,  but it was an Android tablet and it run.  But, well, it was made for the mouse.  It was hard to use.  It was made for the mouse not fingers.  So you try to click on one thing,  you click on three things at the same time.  It didn't felt like a mobile application.  And the dialogue, the files should be reshared somehow,  some way.  And the application didn't have access to the Android's  operating systems to actually get the files.  Because Android and iOS, they have some strange ways of having  any file that you want.  It's not really like a UNIX-based system  or a Windows or anything.  So it was...it worked.  But it didn't really...it worked.  And it enters LibiGit.  And the clowns.  LibiGit is awesome.  And I'm not sure if anyone here did that  because they didn't thought that this was possible with Git.  But we are actually using Git as a file.  Not as...  What do you use Git for?  Sorry, yes, repository.  We are not using Git for a repository.  We are using Git as a file format.  Which is awesome.  Because now we are storing everything in the Git,  not as a text, not as an XML file.  We are using Git storage information to save the dive.  Which is quite okay.  And it's fast.  And we can apply GIFs over files.  And if we sync something, we can just do a Git pull  and pull only the difference of the Git repository.  Which is awesome.  Because that file that I opened here on subsurface,  it has 80 megabytes of data.  Because the guy that did those dives is just stupid  and he dives with four different dive computers  to test the software.  Yes, I still think that he's crazy.  And that's Linus, by the way.  But with Git, we have a lot of things.  We can add something and we can compare GIFs.  So it's really good for a programming perspective  because we can diff the file format that it generated.  And it's easy to spot regressions.  It's easy to improve.  You get a Git repository for free.  So you can send your dives to Git hub and then just Git pull.  And you can use that to get the files on the computer  and on the mobile.  And because of that, we created the subsurface cloud service  that is also free.  Well, it's free for the users because Linus is paying for that.  And the problems of the Qt really gets that I said before.  It's proven.  It works.  It will not crash.  It's really lightweight.  I mean, really, really lightweight.  For people that thinks that Qt is not lightweight as GTK,  for instance, if you use the same stuff from GTK and from Qt,  they both will use the same amount of memory on your computer.  So not really difference.  And it's still used for everything.  And there is Kim.  Oh, OK.  It can use the card directly, means that I can call the C code  that the code is made of.  And I've done that.  I showed that before.  So I'm going to just pull over that.  And it enters KML.  People here do you know KML?  Two, three, four.  OK.  Quite much.  KML is something that Qt created not a long time ago,  because when Qt was social Nokia and then Nokia  was another company, and then another company split into  other company, how can people trust that if the company is  not solid?  Well, you guys know Bentley, right?  Bentley uses KML.  You guys know Tesla.  Tesla uses KML.  You guys know Mercedes, BMW.  They are starting to use KML.  Samsung is using KML.  So how can you trust a company that's never really solid  and stable?  I'm not sure.  They do trust for some reason.  And one of the reasons is that this thing can run everywhere  on desktop, on mobile, on Kinect.  Do you guys know Kinect?  Yep.  So Kinect is one of the most used operating systems for  vehicles, for cars.  And it's being used currently on embedded systems.  It's being used currently on airplanes, on cars, on  smartphones, on drones, on fridges, on boats.  And I actually did the first drone using KML.  It was amazing.  I crashed at three.  Literally.  Literally.  Yes, literally.  Because when you have the drone and you have no idea how to  counter it, well, that was my first crash.  And then I actually, I put some parachutes on it.  So it wouldn't actually crash that way.  And then on my job, I had to replace an arm core and  change it to Intel.  I was Intel developer.  So we were trying to make the drone work on an Intel chip.  The problem, ah, the problems.  Intel chip was too slow to actually do the mathematical  calculations that we needed for the drone on the first trial.  And it completely collapsed when it started to roll down on  the sky and crash it.  And the parachute didn't work it because it tried to open,  but it was spinning.  It was awesome.  We have the video for that.  And KML started a long time ago when this was  considered a smartphone.  This was...  It was awesome.  It was awesome.  Yes, it was awesome.  It worked.  It was the green phone.  Thank you, because I forgot.  It was a little bit sluggish because we didn't actually  have the OpenGL working on that thing back in the time.  But it was the first trial of having something declarative  to work.  It used a tilt widget, so it had a lot of libraries to load.  It was a little bit bloated, but it worked.  It worked on OS X.  It worked on Linux, Windows, Kinects, Android, iOS.  And now you remember probably on the university or when you  guys were starting to program or you heard this, that  Java is compilers run everywhere.  But it's not because you have Java say, Java me, Java something.  And here you have actually a C++ code that you can code once  and run everywhere.  You have to modify a little thing here and there sometimes,  but it usually works.  And it's KML, a language that runs on top of V8.  V8 is the library from Chrome to run JavaScript.  But it was a little bit modified to load small files instead  of big JavaScripts.  And it also uses a Git.  And it can interact directly with QObject.  So if you have in your program a QObject, you can just pass it  to the V8, to the KML engine.  And it can interact with it.  You can call the properties.  You can call the functions.  But it doesn't interact with C codes now.  My whole core is in C. How the hell am I going to interact with it?  I cannot.  So I need to do.  Oh, sorry.  There is no drawing primitives on KML, which is also a bummer,  because if there is no drawing primitives,  I cannot do the profile.  The profile is the little fancy graph.  On KML, I can do rectangles.  And I can do texts.  And I can do a combination of rectangles and rects.  For real.  For real.  I don't have anything on KML that is more than a combination  of rectangles and texts and maybe a PIX map.  Can you not load or secure it at some point?  No.  You can't.  You can't load any kind of QTweet to get inside of KML.  Unless you go to C++ and you create a new KML object  that loads the PIX map for that widget.  So there is nothing ready for that.  But it can interact directly with Qpainter.  So you could use Qpainter for that,  but it's not really performance because it is done in OpenGL.  And if you use Qpainter, you are interacting actually with PIX maps.  And the act of sending a PIX map to OpenGL,  every frame is time consuming.  And you can also use JS canvas because KML is built on top of JS.  And JS has a canvas.  You could use that not performance.  Don't do that.  Nobody does that.  Don't even try to do it.  Well, actually, we on KDE, we are doing that.  We have three libraries for that.  Because we had to experiment.  And for a desktop, that's mostly OK, but not for a mobile.  Mobile doesn't have the power as a desktop has.  So we could not use that because our graph is just huge.  This is painful.  So Stratdive uses a double-linked list with two pointers  that have a few other members as a seed pointer  that has a few macros to work on it.  And we need to transform that on the C++ object  to throw this to the KML.  And create a model because NVC and KML are made to be used together.  So let's duplicate the code.  And by duplicating the code, we actually managed to make this to work.  And now KML has code to deal with dives and related things  because, well, we need to work with dives.  But it was painful.  But it worked.  This is an actual picture of the program working on drives.  And it's even blinking because it was really a lot of work to make this work.  It was two summer code projects because the first one the guy just gave up  and never answered our calls.  It was not really good.  But we still had the problem with the profile.  Oh, this is using Kirigami.  Do you guys know Kirigami?  Yep.  So Kirigami is a library that the KDE developers are building on top of KML  to make the application not use the device-specific information for widgets.  We want to use something five minutes.  OK, I need to run.  We need to...  Damn it, I hate to run.  We need to show the application as a unity everywhere.  Every device should have the same face.  So we started to use in KML.  Kirigami, sorry.  But the profile was also a problem.  And we couldn't use JS Canvas.  We couldn't use the OpenGL by hand because OpenGL by hand is just too painful  and I don't have the time to learn that.  If anyone of you knows how to use OpenGL by hand, please help us.  We had KDE charts, Q-charts, and we could try to export our current charts somehow.  I tried Q-charts and Q-charts and none of them worked for what you want  because you already talked about this.  No current charting library had what you had, what you wanted,  because we wanted to put a lot of axis overlapping on top of each other.  We wanted to make them not really show because we already have the information on the curve.  We wanted to invert some axis to show the graphs upside down.  It was hard to do that in a pretty way using the current things that we could.  So we parted everything that we could to KML.  And the profile, the Q-tweetget that you told us, how can you put a Q-tweetget?  We had to write a C++ class.  And it's a little bit of magic because we had to do this bit of code  just to make it show correctly on the screen.  I'm thinking that you can read this. It's not made for reading, it's just because  I want to show you how we did it.  And there is a lot of magic functions there.  There is a lot of magic numbers that we have no idea why they are there,  but they seem to work.  Yes, and it's working. It appeared.  And we are happy and this application is actually running here in my iOS  that I can try to show you.  Ah!  This is the application. I don't have access to the data right now,  so I cannot show you running that, but it's loading.  Woo!  So we still have a lot of code on C.  We still have the lack of an actual KML developer  because I am a Qt developer, Qtweetget.  I've done 10 or 12 years of C++ development with Qt for the desktop.  My head doesn't work for KML.  And we have a constant API breakage on KML  because we have KML controls 1, 2, they are incompatible.  We have Kirigami 1 and 2, they are compatible,  but they are using KML 1 or 2 that are incompatible.  So we had a lot of issues on that.  And it's hard to get the documentation because they are still creating it, so...  hard.  So we need more people, please,  if you guys want to try to work with Linus and annoy him, please join.  Yes, we need artists, we need testers, we did divers, preferably programmers.  Yes.  And it's actually true.  Come join us, you might meet Linus and he will pay you a dive someday.  And questions?  Sorry, I don't have the time.  I have a plane to catch right now and I need to run.  That's all.  And I finished it in time, which is more awesome.  So I think I have one minute.  Anyone has a question?  Yes.  Have you looked into rendering the rough using shader or having multiple shader effects on top of each other?  We look into that, but for that we need to know OpenGL.  I have no idea OpenGL and you won the fest.  Thank you.  You're welcome.  So people, thank you very much.  And I really need to catch a plane.  Okay.  Okay.
From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_0_131.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_132_1127.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_1128_2399.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_2400_3875.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_3876_4679.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_4680_5579.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_5580_6371.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_6372_6683.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_6684_8963.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_8964_9371.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_9372_9443.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_9444_9815.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_9816_9947.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_9948_10103.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_10104_11015.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_11016_11111.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_11112_11183.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_11184_11399.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_11400_11891.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_11892_11987.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_11988_13343.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_13344_13439.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_13440_14135.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_14136_18215.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_18216_18539.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_18540_18635.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_18636_18743.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_18744_19799.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_19800_25439.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_25440_26975.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_26976_27083.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_27084_27143.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_27144_27407.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_27408_28127.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_28128_35735.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_35736_36887.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_36888_38507.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_38508_39047.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_39048_41339.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_41340_42659.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_42660_42911.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_42912_43883.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_43884_44303.png From_Gtk_to_Qt_An_Strange_Journey_part_2_The_continuation_of_the_original_talk_from_Dirk_Hohndel_44304_44450.png