 Hello everyone. Yeah, I'm jumping in for Aleich doing a little lightning talk on the current status of K-Develop in 2015. I kind of missed the deadline for proper presentation this year while I was on vacation. So what I want to talk about today is that K-Develop is still alive and kicking. Quite some people are still contributing actively and it's actually looking very very good in my opinion. The framework's port is kind of done in a sense that both K-Dev platform and K-Develop as well as the core plugins like PHP and Python are ported and work We're even at the stage where the core stuff is got ported away from KDLyps 4 support and in so many areas it's simply much better than whatever we had before. Not only because of the port but also because we decided to strip away code and for example the Cmake and C++ area we decided to simply cut away throw away old code and replace it by something new. I'll talk about that in a bit. That also means that by throwing away code we obviously missed removed a couple of features. We do plan to bring them back sooner later, but yeah, more on that later. Cmake, you might have heard that before, we decided to use upstream instead of writing our own Cmake via engine in a sense. We are currently waiting with upstream more in a sense of waiting for them to do the work. Upstream in this case is Stephen Kelly. He's actively refactoring Cmake and in the long run will hopefully then give us something to work with. What he's essentially creating there is a way to build some tool that we or any other IDE can then query and use for things like code completion help but also build wizards on top to add files to a target and these kind of things. Thanks to the work that Alech did by removing the old code and working with the upstream external binary means that it's significantly faster. The only thing that is actually missing at this point as far as I'm aware of are the wizards. Like you add a new file and it asks you like do you want it to a certain text file? Like that's what Cmake files are. So in my opinion it's not that big a deal and it's certainly worth the reduced maintenance cost and improved performance. On the C++ site, we still do have our old C++ plugin that essentially is implementation of parts of what also a compiler would need to do. So parsing, tokenizing and then analyzing these things to figure out template structures and yeah, it's still more or less in the same stage as what you know from KD4 based KDevelop. So it still does not support lots of C++ 11 features or if you throw in standard library stuff, it simply breaks. That's because we have concentrated on KDF Clang instead. That's a completely new tiny code base based on the C API that Clang from the LLVM project offers us. So it's really really awesome in my opinion to see that work out. It's not only supporting the latest and greatest in C++. It's also much more stable in a sense of if that crashes and yes, sometimes Clang does crash. It does not take down the whole application because it's kind of sandboxed. The performance is by far not as bad as I feared. There are some cases where it's currently still less performant than what we had before. But overall, especially when you analyze a huge project, it is much faster than what we had before, especially on modern multi-core machines you hopefully use for developing. And yeah, the language support as I said is immensely better. Some features are not yet implemented but being worked on so do wait for that. We still have other languages as I mentioned PHP, Python, but also the QML, Ruby, CSS stuff is still there. Even though it's not officially released, we have to do something about that. But it's all there. If you need any kind of these languages to ask us and we can tell you how to do that. There's also new people coming into the community contributing a Go plug-in and there's someone working on a Rust plug-in for K-text editor, which we then can also use in K-develop. GDB has been worked on by another new contributor and it greatly improved the stability of the whole thing. There are still some issues when you work on embedded or across different machines. That's definitely something I want to work on this week. But yeah, there also expect some improvements compared to what we have in our latest stable release based on KDE 4. And right now we have three Google sum-of-codes students working on K-develop. Sadly, none of them could attend the academy. First of all, we have Flaslo working on a unified checker framework in the sense of we had... Yeah, welcome. Welcome to my world. That checker framework essentially aggregates problems we find in your code from all over, like be it the language analyzer, be it the external tool like Valgrind or Linter like crazy and all that is now displayed in a central place and he's further improving that part. Marchek, I hope I pronounced the name correctly, is working on C++ refactoring. It's a highly... How do you say that? Research and development project, like we are not yet sure where this will go because it's based on Klang and the C++ API of Klang, which has no stability guarantees whatsoever. And right now it seems as if we can use it in some parts, in other parts, we have to come up with our own solutions. So it's very interesting work. I'm very grateful that he's working on that because someone needs to play around with it to see whether it's actually feasible to implement proper large scale refactoring based on Klang. Just a side note, Klang always works with translation units and has no real idea of doing full project analysis. So that's something we have to fill the gap. And then last but not least, we have Sagge, who's doing a tremendous job in improving further the KDF Klang plugin, picking up where Kevin Funk left off last year. I mean, Kevin Funk is also still contributing, of course. There are performance improvements, adding missing features like in code completion, these kind of things he's working on and advancing quite nicely. Then kind of the pain point we have forever and probably will have forever, I don't know. I hope to get feedback from you side as well. But right now what we often hear is that the KDevelop UI is too cluttered, too distracting, whatever. Actually, based on Breeze and modern KF5, it doesn't look that bad anymore, in my opinion. And not only that, Alek also implemented an experimental concentration mode, also he said. It's like a shortcut to hide craft. Of course, you need to know the shortcut. We are aware that this is a strange way of handling the situation, but at least it is solving a very, a problem we have. We simply did not come up with a proper UI that has the functionality we need and is not distracting. So if you have any ideas on that, please attempt our above, send us emails, whatever. And right now, do try the concentration mode. It's windows, so meta seed to enable it or disable it. So it hides the menu bar, it hides the tool view buttons, but you can still blend them in based on shortcuts, as you like. So yeah, KDevelop 5.0.0 is looking good, in my opinion. So I really want to release the first alpha beta, however you want to call it, this week, I think. What's really missing is the proper support for KTex editor plugins, so we can share even more code, meaning we can remove stuff on our side and blaming the Cade people, so blaming myself as well there, partly if something breaks. Then the big open question is, do we want to ship something with old CPP still enabled, or do we want to start from scratch and not from scratch, but it directly go to KDEV Clang. I actually tend nowadays to the letter, but feedback on that is very welcome. Yeah, with that I come to the end. Do we have any questions? And again, if you have feedback, either by email, ISE, or the buff on, what was it, Tuesday, I think, 12.30 in that room, wherever it is. So yeah, thanks. The Qt creator, you mean? I'm sure we could copy stuff from the UI. Some of them, that part is extremely good and well done. I completely agree there. Other things, yeah, could be done, but I actually would like to find a proper, like, have someone with an idea and drive us forward. I don't simply want to play catch up by copying their work, even if it's very good in many areas, but let's see how it goes, right? No, but I can tell you, or I can put it in a wiki on how to do it. But probably best put it into the default KDAF plus code, I see, so that it gets at least third. Yes, and no, because that would mean I need to fix KDAF platform to not load both plugins and then both try to analyze CC plus plus code and then hell breaks loose. So can I have my state lab back, please? Is there anything else? There is one more question, I think. Oh, no, I'm over time already, I think. Sorry.