Developer Blogs

This page aggregates the blog contents of people working on the KDevelop IDE.

Friedrich W. H. Kossebau | Mon, 2017/10/09 - 15:09

KTextEditorPreviewPlugin 0.2.0 has been released. The KTextEditorPreviewPlugin software provides the KTextEditor Document Preview Plugin, a plugin for the editor Kate, the IDE KDevelop, or other software using the KTextEditor framework. The plugin enables a live preview of the currently edited text document in the final format, in the sidebar (Kate) or as tool view (KDevelop). … Continue reading KTextEditorPreviewPlugin 0.2.0

Friedrich W. H. Kossebau | Sat, 2017/09/30 - 21:45

KMarkdownWebView 0.2.0 has been released. The KMarkdownWebView software is for the rendered display of Markdown documents, using web technologies (native wrapper around a webpage with a JavaScript library which creates HTML from the plain text handed in). The software contains a KParts plugin for rendered display of Markdown files, which enables KParts-using applications (like the … Continue reading KMarkdownWebView 0.2.0

Friedrich W. H. Kossebau | Mon, 2017/09/25 - 14:26

KTextEditorPreviewPlugin 0.1.0 has been released. The KTextEditorPreviewPlugin software provides the KTextEditor Document Preview Plugin, a plugin for the editor Kate, the IDE KDevelop, or other software using the KTextEditor framework. The plugin enables a live preview of the currently edited text document in the final format. For the display it uses the KParts plugin which … Continue reading KTextEditorPreviewPlugin 0.1.0

Friedrich W. H. Kossebau | Thu, 2017/09/14 - 17:08

KMarkdownWebView 0.1.0 has been released. The KMarkdownWebView software provides a KParts plugin for rendered display of Markdown files, using web technologies (webpage with JavaScript library which creates HTML from the plaintext handed in). This enables KParts-using applications (like the archiving tool Ark or the file manager Krusader) to show Markdown files in the target format. … Continue reading KMarkdownWebView 0.1.0

Friedrich W. H. Kossebau | Fri, 2017/09/08 - 02:59

The “Live Preview” plugin for the editors/IDEs Kate & KDevelop (see introduction) makes use of KParts plugins to support different file formats. Thus it can also pick up the range of existing KParts implementations out there right from the start. A perfect user experience with the “Live Preview” plugin means: automatic updates of the preview … Continue reading In-pane preview of Qt UI files with KUIViewer coming up

Emma Gospodinova (GSoC student) | Tue, 2017/08/29 - 00:38

(function(d, s, id){ var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) {return;} js = d.createElement(s); js.id = id; js.src = "https://assets.gfycat.com/gfycat.js"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'gfycat-js'));
I just watched the season 7 finale of Game of Thrones earlier today, I couldn't help it, sorry.

So, as summer is coming to an end, Google Summer of Code is also wrapping up, and the KDevelop Rust plugin is looking good at this point. It now supports semantic highlighting, go-to-definition, renaming declarations, some code completion, debugging, highlighting code errors, and code formatting. I'll go into a bit more detail for the last three since they were the most recent additions. 
I also focused on a lot of minor improvements this past month to make the plugin easier to build and use, to make it more reliable, etc., so at this point kdev-rust is a solid basis for anyone looking for a Rust IDE.DebuggingAs I've mentioned before, KDevelop supports both the GDB and LLDB backends, so debugging was a matter of hooking up the backend for Rust executables. Here it is in action:

Video should appear here; if it doesn't click hereCode formattingDon't you just hate it when your code is just all over the place like in this totally not contrived example below? Well, worry no more, you can now reformat it straight from the editor!
Video should appear here; if it doesn't click hereDiagnostic messagesI mentioned in my last post that I'm looking at exposing error messages from libsyntax to KDevelop. This now works for parsing errors, but now that the underlying infrastructure is there, type errors and lints are soon to follow:
Video should appear here; if it doesn't click here
If the videos above aren't loading, they are available here, here and here.
What now?If you've been following my blog you should know by now I'm a huge fan of Rust. The KDevelop Rust plugin is usable at this point, but as with any project, there is a lot that can be added. I very much intend to continue working on the Rust plugin in my free time even after GSoC has finished, so please feel free to try it out and send me feedback.
The kdev-rust repository is available here (mirror). A nightly Rust compiler is required to build the supporting library.

Friedrich W. H. Kossebau | Mon, 2017/08/21 - 20:11

You are using Kate or KDevelop and often editing directly the sources of Markdown files, Qt UI files, SVG files, Dot graph files and whatever else formats which are based on plain text files? And you are having to use a workflow to check the current state which is saving the file and (re)loading it … Continue reading Look what you have done^W^Wdo!

Mihail Ivchenko (GSoC student) | Sun, 2017/08/20 - 21:15
Mihail Ivchenko (GSoC student) | Sun, 2017/08/06 - 20:41
Sven Brauch | Sat, 2017/07/29 - 19:39

Akademy, KDE’s annual developer conference, is over — and as always, it was a great experience! Thanks a lot to the local organization team, and of course to all the nice people attending and discussing things. Akademy is typically a mix of hacking, visiting workshops and talks, and socializing with other KDE people. In the KDevelop workshop for example, we discussed about the future of the project — which issues […]

Mihail Ivchenko (GSoC student) | Tue, 2017/07/25 - 18:56
Emma Gospodinova (GSoC student) | Tue, 2017/07/18 - 20:00

(function(d, s, id){ var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) {return;} js = d.createElement(s); js.id = id; js.src = "https://assets.gfycat.com/gfycat.js"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'gfycat-js')); I'M SO SORRY FOR THESE AWFUL PUNS I CAN'T HELP IT.
TIL the Rust compiler panics. A lot. Okay, it wasn't today, it was last week. Still. At this point I feel bad because I feel like I'm constantly coming out with something bad to say about Rust. I swear, I love the language. So I'm just going to point it out and move on: libsyntax panics on a lot of lexing and parsing errors. There. Moving on...
I have to admit, I spent too much time thinking of something interesting and engaging to write in this blog post but unfortunately it's just going to be a small progress report. You know the famous saying, a gif is worth a thousand words...HighlightingIn my last post I showed highlighting done for declarations, but uses were not highlighted. Lo and behold...
Video should appear here; if it doesn't click here
This also means that go-to-declaration works as well. You might notice the uses aren't highlighted the same color as the declarations. That's a mistake on my part and I'm working to fix that.RenamingAs I've said before, KDevelop does a lot of things out-of-the-box if it has the Declaration-Use chain for a project. Renaming declarations is one of them.
Video should appear here; if it doesn't click here
Very basic code completionIn the spirit of short recordings, here's another one.
Video should appear here; if it doesn't click here
(yes, the cursor is slightly off in all of these; blame the recording software)
(((also if the videos aren't loading, you can view them here, here and here)))
Up nextSome more interesting things for code completion are coming up. Also, the Rust compiler has amazing error messages and I'm currently looking into getting the diagnostics out of libsyntax and show them in KDevelop. I'm looking into parsing imported modules as well, starting with libstd. All exciting stuff.
I'll also be speaking at KDE's Akademy this weekend, so if you're there, please feel free to drop by and say hi. I won't bite. :)

Mihail Ivchenko (GSoC student) | Sun, 2017/07/16 - 19:11
Mihail Ivchenko (GSoC student) | Sun, 2017/07/02 - 21:14
Emma Gospodinova (GSoC student) | Tue, 2017/06/27 - 20:39

I've contributed to KDevelop in the past, on the Python plugin, and so far working on the Rust plugin, my impressions from back then were pretty much spot-on. KDevelop has one of the most well thought-out codebases I've seen. Specifically, KDevPlatform abstracts over different programming languages incredibly well and makes writing a new language plugin a very pleasant experience.The Declaration-Use ChainThe Declaration-Use Chain stands at the core of this. It's a simple enough concept: there are things in the language which are declared somewhere and used in other places. Declarations are a generalization of programming language constructs: structs, struct fields, functions, methods, locals, etc. Declarations can open contexts and any declarations in a child context are valid in that context only. For example, functions open a new context for declarations inside the function body. Uses are, well, what you'd expect: instances where these language constructs are used.
Obviously, there's some details I skipped here, but the beauty in all of this is that KDevelop can figure out a lot of things for you if it simply has access to this information.The Rust CompilerThe Rust compiler is also really well designed in that it allows accessing the internals such as the syntax parsing library. It's not necessarily the nicest thing, as the internals are intentionally marked unstable, but given that a lot of other tools for working with Rust source code like RLS also depend on compiler-internal libraries, I think this is an acceptable compromise.
These will likely stabilise over time, especially given the amount of effort being put into the save-analysis API. Speaking of which, one thing missing that would be very useful is to be able to get the full span of declarations that have an internal context (e.g. the span that covers the body of a function).
My main effort on the Rust side is trying to expose a C API to the compiler structures that is more independent from the compiler internals themselves. Think libclang. I think something like this would make adding support in other IDEs easier. I'm currently looking into hooking into the various stages of the compiler in order to get both the pre- and post-expansion AST, as well as type information inferred by the compiler (though I'll likely try to implement this myself first for the learning experience :)).Building the DU Chain for Rust codeAnd now the fun part: how these fit together. Here is a before and after:
 
Much better. Going forwardThere are things still missing here; as you may have noticed, uses are not highlighted. I have to admit, I fell about a week and a half behind schedule due to a university group project which was more time consuming than I initially expected as well as my attempt to think through how to best expose certain things as a C API from Rust before writing a significant amount of code. Thankfully, I accounted for some delays like this in my original timeline, so this should be recoverable from.
Right now, I'm aiming to finish adding the missing elements of the DU Chain by the end of this week and then I'll start looking into code completion. 

Mihail Ivchenko (GSoC student) | Sun, 2017/06/25 - 18:24
Friedrich W. H. Kossebau | Mon, 2017/06/19 - 16:30

Or: Tying loose ends where some are slightly too short yet. When you favour offline documentation (not only due to nice integration with IDEs like KDevelop), develop code using KDE Frameworks or other Qt-based libraries, you know all the KF5 libraries have seen many people taking care for API documentation in the code over all … Continue reading Adding API dox QCH files generation to KDE Frameworks builds

Emma Gospodinova (GSoC student) | Tue, 2017/06/06 - 20:50

After my post last week that I would be implementing the Rust plugin the classic way (that is, manually parsing, deriving type information, figuring out completions, refactorings, etc.), I received quite a few replies about the language server protocol and RLS specifically. I'd like to address RLS in more detail, since some of the replies were rather strongly-worded and sounded a bit patronizing.The Good: in defense of language serversGiven that I will be criticising the language server protocol for the remainder of this post, I want to note that I'm not against the concept. I quite like it, actually. Language servers work great with lightweight editors: implement the protocol once and the editor becomes reasonably powerful for any language which has a corresponding language server. Visual Studio Code is a great example of an editor that benefits from language servers, which I guess is quite obvious given that the language server protocol was practically designed for VSCode. Still, others like Atom, Sublime, Vim and Emacs would also greatly benefit from the language server protocol. (Now, whether I would personally use it in Vim is a whole different story.)
From what I've seen in the language server protocol docs, that's pretty much what they're pushing the protocol for, at least for the time being. I think the language server protocol needs a lot more additions in order for it to be useful for IDEs. Which brings me to my point.The BadIDEs are not just editorsThe thing is, IDEs have to support many things besides just the language itself; debugging and project management come to mind, but for those, the IDE doesn't necessarily need to know much about the language. For other things, such as static analysis, type hierarchy, dependencies, etc., the IDE needs to understand the language. And yes, you could argue that these functions can be implemented by the language servers, but the thing is, they're not just unavailable at the moment for some language servers, the protocol itself does not specify how they should be implemented.LSP is incompleteThe protocol currently only specifies very basic functionality: autocompletions, quick fixes, semantic highlighting, finding uses, formatting and that just about covers it. This is nothing compared to things a good IDE can do. Specifically when it comes to code generation, I think that's where IDEs truly shine, but at the moment LSP does not specify how to do general code generation.LSP is inextensibleSure, individual language servers can extend the language server protocol with additional methods, such as rustDocument/diagnosticsBegin and rustDocument/diagnosticsEnd, but considering the point of the language server protocol is to reduce the amount of work necessary for tool developers, there is little incentive to keep track of every language server's extensions.And The UglyMaking an IDE jump over its own data structures is just plain uglyMost large IDEs are built using a plugin-based architecture, in order to support many languages, and the core usually has some abstract language structures. Declarations and uses; the different kinds of language objects like functions, locals, classes, structures, etc. And just based on those, the IDE can implement a whole lot of functionality like go-to-declaration, rename, semantic highlighting, etc. All the language plugin needs to do is to populate these structures.
The problem with language servers is that they take all of that information away from the IDE. So in the end, it doesn't matter that you don't need to do parse and understand the language since the language server can do it for you, because you end up having to reinvent the wheel anyway by having to reimplement the core functionality to depend on the language server, rather than language support plugins.How it can be improvedJust bashing on the protocol is not particularly useful for anyone, so I want to suggest a way many of these problems can be avoided: provide code structure information. Instead of trying to rip away the main component of an IDE from it, allow the IDE to work with the language server. There's no point in the IDE asking the language server what to highlight when the cursor is on a variable if the language server just tells the IDE where the declaration and where all the uses of that variable is in that document.
There's no need to remove any existing functionality either and the language server already computes all this information anyway! If it's exposed to the client, the client can decide if it wants/needs to use it or not.And yet ignoring all of that, RLS is lacking in functionalityI decided to spend 72 hours last week implementing (a significant part of) the language server protocol in KDevelop in order to prove a point: RLS still doesn't even support many of the features that the language server protocol permits.
Completion support for locals works and not much else.
No completions for functions of something. (The ones shown are keyword completions from Kate.)
No completions could be triggered here. RLS returns an empty list.
No contextual completions: we are in a match block for foo, which is an Option type, which is an enum. It is reasonable to expect that we can autocomplete the enum values.
And this is just code completion. RLS returns empty lists for the documentSymbol and documentHighlight methods, hence why only the syntax highlighting from Kate is available. I haven't tried references, but since RLS computes that identically to documentHighlight, I expect it won't work either. The hover method doesn't work either. Even if the reason for those not working is that I missed setting up something (it happened initially with code completions requiring racer which needed an environment variable to be set), having the user set up all of this manually is not at all user-friendly.
Go-to-definition works. I haven't tried the formatting stuff, but that calls rustfmt, which the IDE can do by itself.
No other methods are supported by RLS at the time of writing. So things like searching for a struct or function in the project, getting information about a function signature, quick fixes, refactorings, etc. are not available.
My project proposal was to create a plugin providing good support for Rust in KDevelop. I intend to deliver on that project, but I do not think at its current state RLS provides good support. That may change in the future and I've shown a proof of concept that KDevelop can interact with a language server. Right now, I think I can do better.

...

Also, Rust's type system is inspired by the Hindley-Milner type inference algorithm. :D No way am I missing the opportunity to implement type inference. After all, Google Summer of Code is an opportunity for me to learn more about things I find interesting.

Subscribe to Developer Blogs