Being Wow’ed by FLOSS, again

Lydia Pintscher* has written a nice summary about the results of this year’s Google Summer of Code for KDE. I think it’s really amazing what has been done. KDE 3 seems so simple and old compared to this.

Or is it just the Oxygen look which makes it look so elaborated?

* I have heard some think there are too few women doing FLOSS stuff. Seems, at least by looking at this weekend’s blog posts on Planet KDE, KDE is doing well and seems a good place not only for small and large, young and old, but also female and male humans. Much better obviously than the BMX community at the BMX ground in my neighbourhood, where when I passed this evening the only two female humans were two mothers waiting while there small boys where doing their jumping. Perhaps they can learn from us?

Tutorial: Add a Binary Filter to Okteta

Welcome to the first in hopefully a row of little tutorials showing how you can yourself add the features you need to Okteta, the KDE 4 hex editor.
Although, after writing this one, which took way too much time, I will see how I can make this more economic for me.
For now, you simply have to make use of this tutorial, so my time was well spent!

Setup of the development environment

Unless you already have a development environment, including the sources of kdeutils, e.g. after following the instructions from TechBase, the following little setup should work for you, too:

You need to have installed a proper compiler, cmake, a subversion client and the development packages of qt4 and kdelibs4. You might not need the kdelibs from trunk, version 4.3, perhaps even 4.2 should do it, I do not remember to have used any newer kdelibs API in Okteta so far. (Please report if you experience problems.)

Now get the sources of Okteta:

svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdeutils -N
svn up kdeutils/okteta

Build the program in a separate directory (replace “yourinstallpath” with a proper path as useful for personal development, e.g. the output of kde4-config --prefix):

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=yourinstallpath ../kdeutils
cd okteta
make

The build will take a while as all those files you just saw when doing the checkout want to get compiled…

Do a make install to see if the installation works, too.
Then testrun Okteta with yourinstallpath/okteta.
(Or just okteta if you are sure your shell does not outsmart you and instead starts okteta from a path it has cached from a previous start when this version of Okteta was not yet installed)

Hoping that all went smooth we can now turn to…

Adding a Binary Filter

In this tutorial you write a filter which will turn all bytes either to 0×00 or 0xFF, depending on whether their old value is below or above a given level. It will look like this:

Call for action: Write your own plugins for Okteta

Up to now I have written Okteta, the KDE 4 hex editor, completely on my own. This has pros and cons:
The biggest pro is that I do not have to argue a lot about design decisions, especially as I have some big plans with the co-developed framework Kasten, which Okteta is built on (to serve as testing area) and which might not yet be understood/followed by others (could just be a crazy idea, after all) as I have implemented only parts of it and also added unmarked intermediate shortcuts to get things running already.

The biggest con is that Okteta doesn’t grow as fast as it could.* So there might be some features you, dear Okteta user, are still missing from it. Additionally, remember that I do not really use Okteta myself, it really is almost only a testing area of Kasten for me (I still am happy if Okteta is already a useful tool to many, as this indirectly results in more testers for Kasten). And so I concentrate on things which help to develop Kasten further. I now turned to think about support for very large files, meaning working with data not completely copied to the working memory (just do not hold your breath for this ).

So, what about the binary filters (e.g. a bit switcher), your export plugins (e.g. Base64) or even complete tools (I can not even imagine) you are missing from Okteta and hoping for in a future release?

For the coming weeks I am going to show you how simple it should be to help yourself, in a series of short tutorials.

Okteta/Kasten has been designed very modular, with a lot of interfaces and plugin-prepared structures. For now everything is hardcoded, but as we have readwrite access to the sources this is of no great problem here

There is almost one month left for you to decide if you want to make your hands and keyboard dirty with an addition to Okteta, then the soft features freeze will hit the development branch for KDE 4.4. And only November 11th would set the barrier for a basically working solution, so should be enough time to get your plugin done, given it doesn’t include rocket science. Or you could be still pleased if it only will be part of KDE 4.5 next summer (well, still not assumed to include rocket science). In any case I will be happy to help you where doable.

The first tutorial will appear on sunday (September 27th) and teach you how to write a binary filter (Update: online now). So stay tuned if you are in need of a hex editor like Okteta and interested to give the implementation of your needed features yourself a try.

* For sure, the pace of development for Okteta has been quite good, just have a look at the automatic analysis done for Okteta at ohloh.net. 48,042 lines of code have been gathered in the last two or so years. Which, using LOC while admitting it’s an evil metric for code work, is estimated to have, taking the given default average salary of $ 55,000 / year, a “Project Cost” of some $ 641,343. I just hope I never will write myself this bill. Because the moment I do I am for one in big debt to someone and also in trouble because someone doesn’t pay my bill.
Another interesting metric seems behind the assigned property “Well-commented source code”: Well, I have spread the code over quite some files, and each and every file has 20 lines comment from the license header. The other comment I often leave is done with this pattern:

// TODO: some improvement

currently around 560 times. Instead almost all API is missing proper apidox. So, rather not well-commented. Still, I use expressive, thus pretty long names for classes and variables, so comments are not often needed (it’s obvious what ByteArraySourceCodeStreamEncoderConfigEditorFactory does, or?). But I wonder if this metric takes this into account

Polishing the tools for Okteta 0.4

While still avoiding to tackle the next big task for Okteta, supporting very large files, thanks to a strain in my right leg I have found some time to polish the tools a little.

Last night I worked on the input widgets for addresses/offsets and byte strings. Those enable the user to select one from several formats in which to do the input (auto detection still a TODO). While I wanted to make a widget similar to the one of the searchbar for Konqueror, with the current format to be selectable like the current engine in the left of the searchbar widget, I found this not easy to implement and the searchbar implementation not pleasing my needs (e.g. not focusable with keyboard, no method QComboBox::setEditedIcon() or similar). So I stayed with my old implementation where the format is selected in an external combobox, but which is now placed to the left of the input field and only shows an abbr. of the format type (“Hex”, “Dec”, …). The input field itself is a combobox which can and is used to store previous inputs (the popup still lacks a delegate to also show the corresponding format). These widgets are now used all over Okteta, just cmp. the screenshot below.

Already in trunk for some time are support in Kasten for inlined dialogs, with Okteta’s Goto dialog and the (new for 0.4) Select-range dialog (see screenshot) ported to it. Additionally all tool views are ported to the new AbstractToolWidget in Kasten which has support for default buttons which are activated on the press of the Return key, like you know from the dialogs. So if any widget in a tool view has focus (and doesn’t eat the Return key itself) one now longer needs to switch the focus to the button but can simply press Return (just seems that the Oxygen style does not give an extra style to default buttons?).

Also switched to use QFormLayout where possible. And found the great KIntNumInput, so any units are shown inside the input field (including bytes, as in number of bytes )

Just the Find and Replace dialogs may stay popup dialogs for a while. For one I have no idea how to best place all the options into an inline-dialog (e.g. the solution in Kate does not follow my workflow) without getting a monster dialog. Even with the Go-to and the Select-range inline-dialogs the window size is sometimes changed, which is a no-no IMHO. And for another on this change I want to implement search-as-you type, which is still lacking a proper foundation for worker threads and locking of document objects. So, support for very large files has a chance to be done before that.

Okteta widgets now plugged into Qt Designer

As blogged about before, one of the things that will be new in the next release of KDE, 4.4, is the publishing of the Okteta Libraries, a set of classes to enable the display and editing of byte arrays of all kinds, using hexadecimal, decimal, octal, binary or several character encodings.

While I personally prefer to do the construction of dialogs and forms directly in code, others like the possibilities that come with the UI files and the ability to edit them in a drag-and-drop interface like Qt Designer offers. To please those among them who might be interested in the Okteta Libraries, trunk now features a Qt Designer plugin for the Okteta widgets. It should also improve discoverability of these widgets as well as enable people to play around with them to see if they fit their needs. Screenshot as proof for the next step in “Okteta everywhere” following:

You can write Qt Designer plugins for your widgets, too, if you haven’t already. Just follow the new tutorial on TechBase (and please report any problems you might encounter).