One of the things I’ve heard on every KDevelop sprint is: we should be light, like Kate but with our added value.
We’ve addressed this in many ways so far: we’ve optimized the code for performance so it’s more responsive and starts reasonably fast, we’ve made sure most done is accessible using the keyboard so we don’t feel clumsy and overwhelmed by all the options.
Today, I wanted to reflect on 2 things:
- What do we miss to be that ideal light editor?
- What’s a good lightness inspiration?
Otherwise, TLDR, there’s a video below.
What do we miss?
The avid Planet KDE reader will know that being light is a complex concept, there’s many ways to perceive lightness: Is Kate light? Is KWrite light?
When we talk about lightness, we generally refer to different metrics. If something is worth waiting for, we wait, and that’s fine. We don’t want to feel we’re wasting our time. A good example there I’d say it’s Chromium. It’s probably one of the heaviest beasts we run on our systems. Nevertheless, it doesn’t feel as such (at least until you run out of memory).
There’s another point of view: We bomb users with features. In fact, it’s awesome to have features and it shouldn’t be a trade-off. On the other hand we’re never using all features at the same time, optimizing that would be awesome. We should work on it: identifying the different workflows and creating user interfaces that enable them.
What’s the role model?
One of the developments that have struck me the most during last years is Kate. Instead of focusing on the editor, it went the KDevelop route: it has started to offer all of the information at once (especially odd, given that there’s quite some feature overlapping).
More generally, if I look at what others are doing, I see two major groups:
On one hand, there’s atom.io and sublime that seem to be doing something very similar. Most of the components they have we have as well, but then the focus is rather different: they have very few visual interaction components, mostly just the menu, so you can just play with the text and you know where to go look for stuff. UI’s are usually embedded in the source code view.
On the other hand, there’s Eclipse or Visual Studio that do something quite similar to what we do: present everything in the traditional desktop application way with docks and a couple of smart tricks, because they try to tackle the whole workflow problem.
I understand how we got to where we are, but I also really understand why people can prefer something like atom. My feeling is that “It doesn’t make me feel like I should be debugging while I’m coding”, even though they oversimplify on some areas.
What do I propose?
I decided that I wanted to feel what’s to work without all the clutter, so I implemented a Concentration Mode for KDevelop. I stripped most of the visual stress, so usually we’re left with the good ol’ katepart editor, with all KDevelop‘s features. I’ll become my own guinea pig: now that I have it clean, how do I use the tools? Can I still do the same things? As discussed on the mailing list, this has had some fruits already.
I think it’s really cool: code, code, code, quick open and shortcuts.
The Video!
Now, a bit of a video implementing what I discussed here.
What to look for:
- We get to hide the navigation handle, leaving only the toolbar, the document title and the central view.
- The toolviews are still accessible.
- The menu is still accessible
- For now, I can decide to just see what I’m working on. Now.
I would appreciate if you integrate conspect edit control with quick open edit control. You could use ideas from Firefox and new search bar.
Something tangentially related to this – I wanted to use KDevelop recently to work on some KDE code (KF5-based), but I couldn’t find a way of bringing a KDE application or library into KDevelop in such a way that I could reliably build and run it – the first sticking point was that importing the component as a cmake project meant that KDevelop wanted to build it with the system cmake version which doesn’t work; it also didn’t seem to want to give me a valid context in which to run the application i.e. against the sysroot built with kdesrc-build.
It seems to me that working on KDE itself ought to be a use case that KDevelop should support; perhaps it is and it just hasn’t caught up with KF5, I’m not sure. In the end I gave up and used Kate (in conjunction with kdesrc-build), but that lost me any ability to get context information and lookup on symbols etc.
Have a look at QtCreator. I think they’ve done a fantastic job. It’s the only IDE I’ve ever used that I feel is actually more useful than it is in my way.
Eclipse is probably the worst in terms of clutter to the point that there is barely room on the screen for the actual code. Visual Studio is a little better but not much, mostly by virtue of having more compact controls and Windows defaulting to smaller fonts. KDevelop was pretty similar to both last I tried about 4 years ago but of course has a much better code editor in Kate. Both Eclipse and KDevelop have this idea of perspectives that tries to improve the workflow but feels very clunky. It was really terrible in KDevelop last I tried it because it was very slow to switch between debug and edit. Visual Studio is even worse because it doesn’t expose the feature directly, but switches panes around unexpectedly when debugging.
In a way, QtCreator has the same idea but it’s fast and simple and just works. It exposes the modes in a very obvious way so that I never have to think about “perspectives” or “activities” or some other add-on gadget of the IDE. The output panes never simply disappear (ahem Visual Studio), but are always available in nicely compact tabs along the bottom. It also has some nice intuitive shortcuts, like how repeatedly hitting escape will close output panes and take you back to edit mode with the code taking up most of the screen.
I think the light vs hollistic difference is what separates Kate and Kdevelop. If I’m glueing up a Python script I’ll use Kate. If I’m working on a big multi-file project with complex builds and debugging needs I’ll use kdev.
Of course, options are the best. Having a toggle option to hide the selector bars is great since you can already keybind everything ever, so if you want to keymap your UI and hide the sides thats fine. I never minded it much, and most features I use once in a while I like to keep available, but I won’t memorize shortcuts for them. There is probably a middle ground somewhere, where you have a switcher menu in the individual panels to all the elements you assign there, but by default it only shows “most frequently accessed / recently accessed” features, so that over time you only have immediate access to whatever you are actually using the most.
While I appreciate the thought that went into this, I don’t think modal UIs of this sort really work. You wind up with two very different experiences to maintain which compete for attention, and both tend to suffer from it. I think KDevelop should rather dare to make a hard decision on how it wants to look by default, and stick with it.
(I use a reduced layout myself.)