New Interfaces for kdesrc-build

A few weeks back, a fellow KDE developer asked me in the IRC development channel whether I had thought about adding a GUI for kdesrc-build, to supplement (or even replace) the existing text-based interface.

In fact, I’ve been thinking about how to improve the interface for some time.  I’ve long thought that the existing console interface is very wordy, and while that’s led to some very minor streamlining and internal code changes to prepare for a quieter future, the codebase would seemingly not make improvements here very easy.

We discussed in IRC whether it might be simpler to do something like CMake’s server feature for kdesrc-build, where kdesrc-build would export a simple REST-style API while it was running.  However it was difficult enough to permit kdesrc-build to run update and build processes at the same time, so expanding the existing codebase to also support being an HTTP server would probably have been quite difficult, especially since I actively try to avoid too many non-core Perl dependencies.  Maintaining a custom environment for KDE-based software is hard enough without making our users also become proficient at maintaining a full-fat Perl distribution.

kdesrc-build: it’s Web Scale(TM)

This would normally leave a dilemma of how to add the capability kdesrc-build would need without requiring a great deal of extra dependencies or invasive surgery.  But I think I’ve found a solution, using (of all things) a web framework, called Mojolicious.  It is Perl-based and can be installed without any additional non-core Perl dependencies, and perhaps more importantly, it is quite svelte for all the capability it delivers, which means we can use it without worrying about a large performance impact.  In fact my perception has been that some things have sped up after being replaced with Mojolicious counterparts.

The result of a good deal of code refactoring can be seen below.

The konsole session on the right is the normal kdesrc-build output you know and love, running from the kdesrc-build make_it_mojo git branch.  On the left is a Chrome browser tab pointing to an HTTP port on localhost.

The web page shown in that tab was served up by kdesrc-build, handled by Mojolicious even as Mojolicious was helping to take care of the asynchronous updates and build processes.

Within the web page, the table shown is updated dynamically using a WebSocket connection back to kdesrc-build.  It’s harder to see without animation, but as each build completed, the appropriate table cell was updated, and background changed to green (for success) or red (for error).  The effect is even more impressive when performing source code updates like normal, as you can visually see how fast source code updates are completed even as the first builds are underway.

When the build finished, a “Build complete” entry was listed at the top.  All of this is still quite ugly, of course, but it’s worked well in my testing.

Getting to this point has required quite a bit of work: I have 37 commits in make_it_mojo alone since it was branched off, encompassing:

• The introduction of Mojolicious,
• Porting from my custom multiprocess IPC handling code to Mojolicious, using Mojolicious’s support for running blocking code in subprocesses to be able to slowly add new changes in,
• Restructuring the update/build process to use promises (Mojolicious supports the same concept for promises as used in JavaScript, though without support for async/await keywords).
• Adding the HTTP server,
• Making it work with WebSockets,
• Adding the web page
• And of course all the little bugs on the way…

Trying it Yourself

To try it yourself (and I’m hoping to get some testing here!), you would first need to install Mojolicious.  It seems to be libmojolicious-perl on Debian/Ubuntu, and perl-Mojolicious in Fedora or openSUSE.  Or if you’re familiar with Perl’s CPAN, it’s just a matter of installing the “Mojolicious” distribution.

From there you’d run git checkout origin/make_it_mojo within the kdesrc-build source directory, and then run kdesrc-build as normal, from where you normally run it.  Assuming everything turns on, you should be able to run kdesrc-build --launch-browser in a separate terminal window to open your preferred browser to whatever dynamic port the kdesrc-build web server ended up being pointed to, and hopefully watch a bunch of boxes start turning green.

Next Steps

As I continue this I will be interested to hear feedback on how I should take this.  I have a prototype Qt app that I was working on, though now that I’ve got WebSockets working I’ll probably shift to use QML once I pick it up again.

Clearly there’s still a lot of work left to do, such as sending important status messages across, hyperlinks to log files (for build failures), statistics on update/build time, perhaps even a dependency explorer.  At least the framework is in place for this now, and I think this is the kind of thing that would benefit from hearing from the users before I go too far in one direction.  How should this evolve?  What would help you all the most?