 Welcome. Let's welcome our next speaker, David Foh. He will be talking about KDE development of the last 20 years, how it was done in the last century, how it's done today. He has been around for basically always in KDE and I guess he's the best person to talk about this now. So please welcome David. Hello everyone. Yes, I'm here to talk to you about a little bit of history of KDE that sounds boring but actually the reason I wanted to do that was I want to transmit some of the culture from the old days to the newer days to have some sort of continuity there and I think it's also always interesting to learn more about where the project comes from and have some of the old jokes carry around and that kind of stuff. So I used to look like this, yeah I used to be young and I have hair and then the funny part of this is what we used to call KDE1 look like this. One of the things it shows in there in middle is a message box that says someone is trying to talk to you and that's the very first thing I implemented in KDE. I needed some graphical environment for my talk demon and I thought I need a message box and that's how I came to KDE just for a message box. Then, well, things happened over many years. Sorry, this way around. So basically I'm going to tell you a number of things just to make sure you know. Did you know what the K in KDE stands for? In the very early announcement of where the whole KDE project got started, it used to stand for cool with a K. It was the cool desktop environment. Fortunately, that name didn't stick around for very long and it became just the K desktop environment and that's what it says on very old t-shirts. It does say K desktop environment. One of the very early founders of KDE is Caledale Hammer, who happens to be my boss today. Of course, we joke that for him, surely it must have meant the Caledale Hammer environment. Since then, he didn't contribute to KDE anymore, but he created a company called KDAB. Do you see any pattern there? I don't know. Coincidence, of course. Now, who knows what the Q in Qt stands for? Okay, Albert. Sorry? What's that? Quasar. I think that's the other way around, actually. You're right. The very first name for Trolltec before it was Trolltec was Quasar Technologies, but that's because they had to come up with a name that started with a Q. And why did they pick the letter Q? Because it looked good in the fonts that the founders were using in Emacs. They said, oh, this letter looks good. Let's use that, right? So that's how they picked Q and then had to find a name to go around it. And of course, the lower case T is because at the time, one of the very often used toolkit was Xt, the X toolkit. So they made the Q toolkit. So it was a little bit named the same way. Did you know that when the founders of KDE chose Qt as a technology, they didn't think of it as a binding decision for the next 20 years. They thought we just need something to bring some GUI up. But that's, you know, let's just be Qt for now. We can always switch to something else later. Yeah, right. At this point, we can't really do that anymore. But it's kind of funny that it was, you know, decision taken by two people in a very long time ago, and they didn't think of it as a very long-term decision. So how it started is two applications. That was a window manager and a panel, the thing at the bottom, right? And that's what Matias Etrich started in the very old days. That's what he started with first. But then this triggered the need for some library classes, like a class that would store configuration, and that's how Kconfig got to be created. But, of course, you have the problem of accessing this Kconfig object, and that's why K application was created, just as a sort of singleton where you could get hold of Kconfig. It only took us 15 years to finally get rid of K application, but Kconfig is still around. Yeah, I have a copy-paste problem here. Okay, and then just for fun, I looked up the very old API documentation for Kiconloader, and you could see it was very simple at the time. It had exactly one to six methods. One of them returning a pointer to a list of strings. Okay, things have changed since then. We don't do things this way anymore. And already in the old days, only half of the methods were documented. So where did I find this API documentation? Actually the website that was showing the KDE1 API docs is still online, and it still has the KDE1 documentation. I found that quite amazing. Later on, that site was replaced with developer.kd.org, and that site was initially hosted by the university where Richard Moore was working. He was one of the very early contributors even before me. And just for fun, I found his ancient homepage from the time. Now I want to talk about my hero in the KDE community, and that's Torben Weiss, which three fourth of you don't know about, so that's a good opportunity. Torben is the guy who started the file manager, which was called KFM at the time. Very initially, KFM was really just a file manager, but it was using HTML technology to just show a file listing. The file listing wasn't a web page, actually. And that meant that KFM was also a web browser because it could display HTML pages, basically. In KDE1, KFM was also taking care of the icons on the desktop. Same design as Nautilus in these days. It was very strange that when you kill your file manager, the icons on the desktop go away as well. It all seems very strange nowadays, but it made sense at the time, because all of this wasn't in the library. It was the KFM application would take, would have all the code for icons, so, of course, it would do that. Queen still has special code for KFM. Ah, nice. I think you can clean that up nowadays. It is difficult to remove. Okay, I'll trust you on that. So that work that he did on KFM in KDE1, he then redesigned all of it, and that's what became Conqueror and KIO. So, basically, all of that code was extracted into a library. That's what gave birth to KIO. And also in KDE2, we created that separate application called K Desktop that would take care of the actual desktop. So, it was separated from KFM, but all of that is based on his initial work. He even took care of that redesign. So, he started KFM, and then at some points around KDE1 to, or 112, he said, I'm looking for a new maintainer for KFM because I want to go up and start my own office suite based on KDE1. Okay? And that's how I came to maintain KFM at the time. So, he went on and designed K-Office. So, what I really liked about Torben is that he had lots of ambitions and a lot of architectural knowledge and know-how that led to a lot of the stuff we still have today. Because, obviously, to create an office suite, one of the big design decisions that had to be made from the start is we need to be able to embed components from the other parts of the suite. The thing that used to be fun at the time was I want a spreadsheet inside of my work processor document, and that means you need component technology. So, he went off to work on that as well. So, what I really like about him is all of the architecture work that he did. He not only did architecture on paper, he would actually implement all of that really fast. So, we all thought, surely he must have clones. That's the only way that he can get all of that done so quickly. But the saying at the time was Torben has many clones, but the problem is he broke the cloning machine. So, we can't use it for ourselves. So, even to this point, to this day, when people say, you know, you should have clones, I always answer, no, I can't. Torben broke the cloning machine. One of the things, you know, as I said, all that he did is still visible in a way. But if you look at the output of KL Client, then you'll find in one of the examples, it says slash home slash vice. So, that's still a reference to Torben vice that we still have in our documentation. I have to put another screenshot of KDE that might be KDE 2, I think. Quite colorful. This one, this screenshot is actually from Torsten Ran, the guy who was doing all of the icons at the time. You can see K-Words, you know, as part of K-Office. So, you can see how it looked like and yet people said, we copied from Windows. I don't see where they got that from because this looks nothing like Windows. Yes, the Windows are rectangles. That's probably the only thing that, and also the buttons to close the window are on top of the decoration. But, you know, apart from that, it's not really Windows. Right. So, before Git, what did we use? Subversion, right. What did we use before that? CVS. And what did they use? Because none of us were there at the time. What did they use before that? Just an FTP server where people would upload their sources and then Kulo would take care of integrating all of that. That's how it all started. Right. Now, subversion, most of you might have played with it, but CVS, I have to have a slide about CVS. That was so great as a tool. If you just want to diff your local changes to see what you changed, you need to be connected. That's fine. We all connected all the time these days, but not at the time. At the time, to be connected, that meant you had to dial up with your 38K modem and it would cost you a fortune just to diff a file. Right. You want to rename a file and preserve history? You can't do that. You need to ask one of the system administrators to do that for you. And what we would do would be to go to the server in the directory, copy the file, which has all of the history, and then we would tell you, OK, now you can delete the old file and that's how you rename or move a file. Very convenient. Also, with CVS, you could check out every file from a different branch, because basically all of the branches are information that are inside of the file. There is no global notion of a branch. Each file knows, I have this branch, it has this name, and this is the contents I have in there. So you could do all sorts of weird checkouts for no good reason. And something else from the old days. Whenever we would create branches for redesigning something like KIO, the way we would call that branch is make it cool. And that name stuck around for a very long time. We had make it cool branches for many different things. I wonder if that's related to the cool desktop environment. That was something about cool at the time, right? Also funny is that Stephen Kulo, who's written K-U-L-O-W, would have, as a nickname, Kulo as written up there, right? Yeah, it was all cool. And then the CVS server that we were using actually moved to Sourceforge in 2000. Nowadays, when you think Sourceforge, I guess you think mostly dead code, right? But at the time, it was great. They are going to host this for us. It's excellent opportunity, because we don't have to ask a university to take care of it anymore. Yeah, things have changed. Another question for you. Which version of the KD desktop used Cobra? Hm? Two. KD2 did not use Cobra. We only used Cobra in the betas for KDE2, meaning after KDE1, we thought, let's redesign everything. We need component embedding and everything. Let's use Cobra. So we had KDE2, alphas and betas using Cobra. One of them was called name Crash. You can guess why, right? It didn't really work well. The idea of using Cobra was we need to embed components. That's inside of the office suite. That's also in Conqueror where we want to have a component for web browsing, another component for PDF viewing and all of that, right? But the initial design was let's do that out of process. The thing embedding actually comes from another process. And that meant using Cobra. And of course the other use for it was inter-process communication as we do today as well. I have very strange memories of that stuff because what we ended up doing was basically duplicating all of the menu and toolbar API as Cobra API. So anytime you wanted to do something with a toolbar button, you wouldn't just call a method from Qt. You would go through Cobra to ask the toolbar button to change so that it could be a different hosting application. That was kind of horrible to maintain and make work. And lots of other problems, of course. If you embed something from another process, what happens if the process goes away, then you have a blank area in the middle of your application and all that kind of problems. But it's interesting that one of the concepts in Cobra is that everything is very generic and you can ask for a service by asking a trader where you specify your constraint and you get a result. And that's the origin of the trader stuff that we still have in KDE these days with a service type trader and the MIME type trader. It's all Cobra technology even though we don't use Cobra anymore. So we moved away from Cobra before even KDE2 was out. And to do that, that's because we replaced the inter-process communication part of the usage of Cobra with DCOP. I heard on IRC recently, DCOP was invented at Academy many years ago. That's not exactly true. Did you know that we didn't have Academy in the very first years, right? What we had before was developer meetings. As we called it, nowadays you would call that sprint. At one of these developer meetings, I wouldn't be able to tell you the year, but a long time ago, Mathias Zittrich and Preston Brown got drunk and they thought, okay, we can replace Cobra in one night. We'll write something that can do better than Cobra and that's how they wrote DCOP. And they confirmed to me that DCOP is actually what gave birth to D-Bus later on. It's kind of a second iteration of the solutions for that so that we would have something that does not depend on the Qt data stream, more shining, but something that would be more interoperable. So that was one usage of Cobra, right? Inter-process communication. The other use of it was component embedding. And the solution for that was, you know, we don't use D-Bus for that. We do it in process with simply plugins we open. So that's something that Torben came up with and he initially called this Canosa. So if you don't know your history, Canosa is the name of a castle where the Roman Emperor Henry IV, you know, he went to ask for a pardon. It was basically an act of shame and I'd like the fact that Torben said, okay, I've tried over-engineering this. It didn't work. So now my penance is to call this Canosa and make something that's much simpler and that actually works. But we didn't keep the name, we called it K-parts. Trisil is a ski station in Norway. The reason I'm mentioning it is because we had two KD developer meetings there. The first one being just after the switch to D-COP. That's where he was showing us Canosa. One of the funny things about that meeting is that we had a very weird schedule where we would start working at noon and then go on working until 4 a.m. and then it's Norway in summer. That's where you notice the sun going down for just a quarter of an hour. That's when you realize, oh maybe we should go to bed now and then start again. And of course Norway means mosquitoes. We had a second developer meeting in Trisil in 2006. Many things happened at that meeting. We were just 20 people I think. One of the things that happened is that there was the Euro football championship happening at the same time and Kullo went a bit crazy and painted the German flag on anyone who wouldn't run fast enough. Clearly I didn't. And then we had people from the U.S. George Stalckus was quite funny. He would hack a bit and then he would sleep because of the jet lag. And when the competition was finished he would wake up again and walk a bit more and then sleep again. That was an interesting way of solving the jet lag problem. There was more sleeping happening. Aaron in very interesting ways. Yes the photo is not upside down. That's how he was actually sleeping. And then Celeste sleeping and then others putting a post-it note on the front saying do not disturb. Yeah we had fun there. So that's just a few tidbits from the very old days and I wanted to share some of that history and culture so that now you know what Kanosa is, you know why Tobin broke the cloning machine. And also I like the fact that there was, you know, because there was less history in the code itself. In these days it was a lot easier to say okay I'm going to redesign this and think about the problem completely differently. And I find that these days we tend to take a lot of the common infrastructure as granted. Who lately said I'm going to redesign a framework, right? We tend to just build on top of it and build applications and so on. It's great but I don't really see the same enthusiasm and creativity at the lower levels. So I'm hoping to see a bit of that again. Okay any questions? Oh yeah. Well that's easy. I wear that t-shirt once a year for academy and then at home I have a humidity-controlled room, no I don't. I have an older t-shirt which I'll be wearing tomorrow but I wanted this one because it says K-Dexter environment but the older one says KD now. So if there's a framework you would, from the old times, which you would like to redesign now, what would it be? To bring back the spirit. Well the thing is, the funny thing about this is I've never really been creative, you know right? I took over a KFM maintenance so that Torben could go off and start the office with. I took over a K-World when he got bored by K-Office and then you know I'm the guy who cleans up after all the people. I do backfixing quite a lot. I don't think I ever really created something from scratch. I thought okay let's do it, well K-Parts okay I was involved in the K-Parts redesign and the XML GUI creation stuff. But about from that, the thing about me is I was in a lucky position to be sponsored to work on KD for 13 years. So I saw it as my duty to do the boring stuff that the others then didn't want to do because they were doing that on a free time. So it's a bit of a different perspective right? But if I had to redesign something today I would have to think about it actually. It's a tricky problem. But the thing, the final thing is too many options or too few options for I read you that, signing things. It's mostly that when you work on a library and you can ask the key developers they would tell you the same. The most difficult thing to know is what do application developers need from you? Because you basically have the view from the bottom and you lack the view from the top. And the reason I like working on libraries is that I like providing services to application developers because they give you usually better feedback than users would. It's a different level in the stack and you provide services to people you actually know. So I enjoy that quite a lot. But I think the definition of what comes next should come from the application unless someone has a great idea and it happened in the past sometimes. But I think it's even better if the libraries are there to serve the application developers. So if something has to change I think the application developers should be the saying this should work in different ways. Yeah right unfortunately application developers don't particularly like to design frameworks or to get involved with that low level stuff. Well that's one of the things I regret right. We have this split between application developers and library developers that didn't used to exist. It used to be that the libraries were a common ground for everyone and if you work on your app and you're missing something you go into the library you add it and so on and so on. And now because the community grew so much we have these different departments that almost don't talk to each other and that's also something that I find has killed a little bit of the creativity. Not just applications and libraries but also the whole if you work on this app you're not talking to the guy who works on this app and then you maybe both invent the same thing at the same time and so on. But still the application developers can say yeah we need something that works better for this problem and then it can come from the ASB. Yeah from my experience the application developers will don't talk to you as a framework guy and work around that bug they found and then another application developer will find a different workaround and nobody will ever put something in back into the library to actually fix the bug. Yes that's what I've been seeing for many years and that is exactly the reason why we are releasing frameworks every month. Because I've seen that change mentality a little bit because application developers no longer think I have to work around this bug because otherwise the fix will come up in six months and I can't wait six months but now that it's every month it's a lot more worth it to say okay I'm gonna fix or ask for the bug to be fixed in the frameworks because the next frameworks release will actually come out before my application is released and that helps a little bit with doing the fixes at the right level. Albert? So it's more a comment than a question but you know like back in the days we didn't have a code review right. I mean those guys that rewrote corba into the cop in one night probably didn't post something for people to read about it and comment and nitpick for weeks until it got merged. So I'm not complaining I mean I understand why we need code review code review is great and it fixes problems you might not see but I wanted to know like your opinion on being on the past where we did broke kdlibs and now where we don't break them that much. If you think we are if we could find a better balance maybe for speed sometimes like I have the opinion that some of the code drops a bit too much on review board sometimes. Yeah I don't think that code reviews prevent creativity or redesigning or all of that stuff right. Both of us work well you reviewed my patches for redesigning the way that cico car works and because it was going through code review and because of test driven development and all of that it made me do that work in little chunks instead of wiping everything out and then restarting from scratch and I think we all know that this is a much better approach because we get something that's better tested every changes understood and so on and so on. So I think this is actually an improvement over the old cowboy hacking where you know stuff changes and it breaks for everyone. This being said I mean if two people re rewrite something in a night obviously that work is not going to go through code review they do it in their own playground and then it's reviewed later on so I don't think that code reviews prevent redesigning it's just in these cases it's kind of a second step where you ensure that the thing is actually stable and well well done and well documented and so on and the act of reviewing helps of course a lot but even knowing that your code is going to be reviewed forces all of us to write better code so I think that has a lot of value even for redesigning and so on. So in my opinion that is not the reason why redesigning doesn't happen that much more it's it's more the growth and the well the the fact that it seems to have become more more fun to work on apps than Libs I don't know but it's it's a matter of also the fear of touching very old code and the the the problem is people seem to prefer starting the wrong thing than taking over an existing thing and that of course leads to and maintained library code in particular or even applications. I have a comment to concerning code review because I know from the history in Quinn how it partly was done like I can find comments with slash slash materials call on question then below another comment slash slash call on answer so code review was partly done by checking into CVS or SVN whatever was used at the time I never found out whether the first name was the one who did ask the question or whether it was the one to whom the question was that was ambiguous isn't it and I I try to blame it but it's impossible to to go down because the code moved too often and well I still have an SVN checkout of KD3 because sometimes it's easier to look up history into an SVN checkout than with all the git conversion and rewrites and everything but you see the the reason that why that worked is that we use the the thing about all the commits going to mailing list we still have it but come on who here reads all of KD commits right it has become impossible but in the old days it was possible to just look at every commit that goes by and I was known to actually do that and I wasn't the only one which means if someone asked the question you would see in there and reply to that but that's also a kind of a consequence of the growth that is just not possible to do that anymore even with filtering and all of that but yeah at least these comments were not in check so that's okay okay thank you a lot thanks everyone ah one last question over there then we're times up short question so we started off with c++ and we've kind of continued with that and throughout with Qt how do you feel nowadays if you were doing it how because c++ has evolved a lot as a language if now you were doing KDE would you really go down the c++ route yeah I don't know anything else short question right okay well we are out of time so thank you