Okteta@Akademy 2008

The seven days of Akademy 2008 have passed quickly. Everything felt so smooth, seemed well balanced, nothing was really annoying (besides a sometimes jittering net access, but that’s it). The organisators must have really done an excellent work. Even the weather was fine. And the local team was very responsive and helpful all the time (even not moaning if contacted when already gone to bed). So once again thanks to all who were responsible! Especially because it was unpaid for almost all!

Now that the dust settles I think the most interesting thing I learned was the power of dtrace, during the OpenSolaris BoF: just handle an object of your interest as a virtual machine, plug into the interface, and voilà, create data in the dtrace fomat which can then be handled by the dtrace tools. And those are really powerful, too. Just too much CLI for my taste I really need to spare some time to learn more about dtrace.

Another interesting thing for me, as author of Okteta, was trying Okteta for the first time myself on Windows and OS X. While I do not really care for these platforms, I am still impressed they are supported, too, without me writing any special code for them, besides staying with the abstraction layers of Qt and KDE and using the proper CMake macros in the buildsystem. So Patrick Spendrin, one of the culprits for the Windows platform support, let me play with Okteta on Windows:

Okteta 0.1 running on Windows XP

And Alexander Neundorf was so kind to have it built and run on his OS X-powered machine:

Okteta 0.1 running on OS X

A minor problem is that on OS X it dies often if opening a filedialog (also seen with e.g. KMail, so this should be a problem in kdelibs). Both platforms are still experimental as of now, but I expect at least for KDE 4.2 official support, given the interest and the work done already.

Okteta is part of the KDE module kdeutils, which I have become the coordinator of. So it was also nice to get to know some of the other kdeutils developers face-to-face. See Jonathan Riddell’s blog for a group photo.

Another group photo is not online yet. It shows those of the city with the most representatives, which is Dresden in Germany. Or is there any other city which had more than 5 people coming from it (besides Oslo)? Hm, this is a statistic question, should be sent directly to Paul Adams, I guess Then the usefulness of a number like committers per city is in question: Does that town lack cultural offerings? Or does it have too many, so one is being spoilt by the choice? Is there just a greater mismatch between the genders? Or is the sun more glaring and the birds more noisy? No idea. If the KDE Research team is out of tasks, I will approach them with this.

I am less satisfied with my own performance at Akademy. I did not manage to achieve what I wanted to. So in the end I should have done more talking and socializing instead of sitting all the time in front of my laptop until late in the night. I got somewhere with the work on the new feature, but till Friday afternoon, when the WLAN was cut off exactly at 17 h, I rather found some little flaws in my design again, which took all of the time (as to be expected). Following you can see what Okteta currently looks like on my system, with some helper environment added for the feature in development:

Okteta: Connecting models...

If it works one day, I think it will be not only cool, but a start to more. Until then just guess what it will be

So another lesson learned: Talk, don’t hack, at Akademy. Let’s rename Hackathon to something else, to not mislead dummies like me.

Riding home under the full moon

After two additional days in Bruxelles last night I went back to Dresden, after Frankfurt using the CityNightLine, a train with a lot of couchettes. As I wanted to keep the price at a minimum I had booked a simple seat and not a couch, which are out of experience too small for my needs anyway. To my pleasure I had a 6-person cabin all alone for me, so I could lay myself down across several seats. Still I was a little bit dissatisfied, because the modern seats could not be moved flat, to build a closed plane alltogether, like it was possible in the Goold Old Days. Then again the windows were like they used to be, so I could pull them open, held my head into the wind and look into the countryside enlightened by the full moon. At 5.50 h this morning I arrived in Dresden, the moon still up in the sky, yet the dawn almost complete. So after a somewhat romantic ride I was complete and safe at home, other than some unlucky fellows.

Bruxelles is a really interesting city. It’s somehow a mess, but with a lot of nice ingredients. Still I don’t think I would like to live there. I think I have to avoid getting into the European Commision and similar. But there seems to be a job position vacant: In front of the EU buildings there are some unprotected WLAN access points to be found. Perhaps these free WiFis are just a way to give the EU citizens something back for their taxes? Or they just do not consider people walking around with WLAN-enabled handhelds…

I was not too prepared for my stay, only had quickly browsed some About Bruxelles pages before Akademy. So on Saturday afternoon, after finding a hostel, I walked around randomly, still catching a lot of the must-sees. Like having a visit of the rooms in the King’s castle. The King and his family seem to be very old-fashioned: I could not find any modern media device, no TV, no computer, no hi-fi system. The King must be a lucky man, there is less to be annoyed by in his life Somewhere before me in the row in front of the king’s castle I had a last trace of Akademy: My eyes were suddenly catched by an Akademy bag, which made me recognize Pradeepto. Did you see any devices there?

I also tried to use that new handheld toy I as many others got at Akademy. Having not even booted it until Friday I finally wanted to see what it can do. At first I had it guide the car when Michael Leupold gave George Goldberg and me a lift to Bruxelles. Well, besides that the streets shown to be larger ones did not really feel like being main roads, it worked, we (and our GPS shadow cross) arrived finally at Gare du Midi.

Using the built-in map to do the sightseeing was not that successfull. It takes too long to get the coordinates by GPS, if at all (oh satellites, where are thou?), and the UI is not that usable. I often would have liked a split view, one with a high resolution for the current location to see street names and alike, and one with a low resolution to see where I am in terms of the city. A history of views would be nice to have, too. And zoom mode should be left after some timeout. I was trapped into zooming too often when I just wanted to drag. I am looking forward for Marble@Maemo with OSM data.

In general I was just tired. So tired on Sunday morning I had to force myself to continue the sightseeing. When I arrived at the Atomium I finally could not walk any longer, so layed back on the large ring of stone around the building and took a nap for an hour or so, enjoying the sun warming me and the sounds around me. The other option to achieve more vivacity, to hang on some rope and jump/glide from the top of the building, was discarded due to the costs of 20 EUR per 10 seconds and my respect for height. After that I continued my tour and managed to in the end check off almost all typical tourist sights, so I consider Bruxelles done now

Still my lesson learned: Do Sightseeing before Akademy. You will enjoy it more.

Open now: Web agency of Okteta

During the recent weeks the module kdeutils, containing the KDE Utilities, has got a website at http://utils.kde.org/.

Okteta, part of the KDE Utilities, has got its share there at http://utils.kde.org/projects/okteta/.

So if you are interested in Okteta and want to know about the
features, to look at the FAQ, to read the documentation, to find your way into development, or to get in contact with the community, you now have a place to go to.

Open 24/7/365. You are welcome

Final polishing of Okteta for it’s first release

If all goes well Okteta will have it’s first real release ever this month, together with KDE 4.1.0. Exciting times.

Exciting because…

… I managed to make it happen. Yeah. Success.
… Okteta is going to fill the gap KHexEdit left. Quite a big gap, as I can guess from the search terms leading to my blog. I hope Okteta can fill large parts of that gap and meet most people’s expectations about what a simple hex editor should work like. There sure will be some disappointed that they will not find certain special features of KHexEdit, I hope they understand how development of Free Software works.
… the code has not yet received bigger real life usage tests. Large parts are covered by extensive unit tests, but only parts. And in the last days I did find some new bugs triggering data loss, when I had been thinking for some time they had been all found, oh dear. Fixed they are again, but I now understand completely how you feel to word things like this in the GPL:

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Other than that, I am really satisfied with the state of Okteta. I managed to do all features I wanted to do, also some I just hoped to do. And for a 0.1 version, Okteta is already quite feature-rich and should serve me and others in a lot of cases well.

The last days I concentrated on fixing the last big flaws in the UI:
All processes which can take some time, like I/O operations, printing or searching, no longer block the refreshing of the UI, additionally also a busy mouse cursor is shown, like expected.
Another flaw were four hardcoded colors for the four different types of bytes I currently use. They resulted in unreadable views especially with dark color schemes. No more now, using KColorScheme and assigning one of the certain roles to each type of bytes, also in selections, so the colors of the current color schemes are used:

There are still a number of minor glitches left, but I think now: Let the release come

Oh, and BTW:

Catch more with Dutchmans than with others

[[Usenet is dead, now Email and Mailinglist are dying, in Web 2.0 times Blog is the way to communicate/discuss. I am just curious how Akregator will learn to display these threads, given that there can be multiple ancestors :)]]

There are currently some classes in Okteta used for rendering which are named the same (*ColumnRenderer), one of each pair living in a namespace (KHEUI), the other in the standard one. Product of lazyness and temporary solutions (printing needs a renderer, the one for the screen is not yet usable, so until it is, let’s just copy,paste&adapt it).

Without any dutchman:
It worked for me, as the code depending on the renderer never sees both of them.

Here comes dutchman #1:
Unless you compile KDE with enable-final turned on, which puts all source files into a single big one. I never have done, but dutchman #1: So Tom Albers sent in a patch to fix this. E.g. it added the prefixed double-colons to remove ambiguity. With lazyness still turned on, I just had him apply the patch as is, because while not too happy with the look I know^Whope the time of the doubled classes is limited (KDE 4.2). Also my knowledge regarding namespace stuff is, well, improveable currently.

Now dutchman #2 comes in:
On his quest to have the traditional targets of KDE, namely unixoid platforms, not being left aside due to some hyped new targets like OSX or Windows, dutchman #2 puts the KDE code on the plate of quite some more compilers, some I have even never heard of. And a few of them seem to have a different taste about what to swallow and what not, compared to all the compilers that have had it one their plate before. Especially regarding one of the solutions of the other dutchman, namely the prefixed double-colons. So Adriaan de Groot, with his brain’s parser broken so he can not detect the maintainer’s email address or his bookmark to bugs.kde.org, stays with his opened blog editor window and throws his findings into the sea of the world wide web, hoping one of the bottle copies will find the person addressed. Lucky he is, it did
So lazyness is no more, will just rename half of the classes and hopefully have all the compilers now eat all from the plate. So the weather will be nice (central europe mothers tell you this relation). Because I fear dutchmans are more used to play soccer in rain, so they will have a little more advantage against the germans in the final of the EM (European championship about dealing with a single ball and two nets the European style). I do not want to be guilty of that, because I want the german team to have a little chance against them. If only for a goal of honor. As to be seen yesterday, they at least have chances to improve, too. A lot of chances… Or they will have to catch a lot with dutchmans, too.

Broken by broken design fixed by fixed design

Or: Eat your own dogfood, not just taste it.

I was so happy with my draft piece table code pretty much working as the backend for the undo/redo system of the basic bytearray model implementation in Okteta. Alright, it still lacks some heavy tests that it can be thrown against. But from my simple tests by just using it it seemed to work.

Then I proudly showed Okteta to someone else. To see that editing in the value column is broken by it. The way the intermediate states in the editing process of a value are synched with the model did not match the change model in my piecetable. Ouch. So I had to switch editing in the value column completely off, just in time for the KDE 4.1 Beta 1 release. Still, I could be a little bit proud as the switch-off was just a one-variable substitution: mNavigator instead of mValueEditor. Things like the latter are what then keeps me thinking again I can code a little

One obvious solution to the problem above was to add the concept of grouped changes to the piecetable code. I had not planned to do this for KDE 4.1, but it was the best fix I could imagine. So when I found/took some time the last days I went ahead and tried to implement something like that. Looks today like I succeeded. There are some little bugs left, but it works enough that I switched editing in the value column on again, in time for 4.1 Beta 2, hurray.

As a bonus I did another few-liner, so changes done by the filter tool are not just named “Replace” as before, but get the name of the filter. I consider this also a fix, as you can only now identify the filter operations in the history, which is to be suspected I guess:

BTW: The version view on the right in the screenshot is just for development, not included in Okteta release builds since 4.1 Beta 1, so do not wonder if you do not find it in the tool menu.

Bonus for you reading until this line: There is a hidden feature in the value column: In Overwrite mode you can increase and decrease the value of the byte below the cursor by pressing + and - (And now that I write it I think I should add support for operating this way on whole selections. But that should be another feature for Okteta in KDE 4.2 ).

Final Okteta features for KDE 4.1

By becoming module coordinator for kdeutils I had to shift my time from hacking on Okteta to some module coordination. And that with the date of the hard feature freeze coming closer, oh well.

But the big cleanup of the module was finished just in time to get two more features done for Okteta:

• a strings extract tool
• an export facility

The first is roughly done, simply surprises me with new problems over and over. The latter is rushed in, ignoring some concepts I have with the Kakao framework, but works for now. And still has some smartness, as it reuses the encoder classes which are used for “Copy as…” (thanks to the QIODevice abstraction).

In the process I moved a very old, but well hidden feature to a visible place: the ability to copy the current selection as the view rendered to plain text. I still remember how I did it in 2003 in Nové Hrady, when I was new to all the KDE development, yet sitting in the same computer room with all the famous KDE guys, how exciting for me. I showed it there to Josef (Spillner), next to Tobias (König) one of my two leaders from Dresden. Besides him nobody might have ever noticed it, because you only triggered it if you dragged a selection from the value column of the Okteta part, which itself only a few might have used (KPilot generic database editor, KDevelop debugger view, …). Touching personal history, oh well…

Selecting the shown menu entry adds this to the clipboard, using all the settings of the view (except for “Show unprintable chars”, for a good reason):

0002:D0E0 |                 2F 68 6F  6D 65 2F 6B  6F 64 65 72 |      /home/koder
0002:D0F0 | 2F 4B 6F 64  65 2F 6B 64  65 73 76 6E  2F 74 72 75 | /Kode/kdesvn/tru
0002:D100 | 6E 6B 2F 4B  44 45 2F 62  75 69 6C 64  2E 64 65 62 | nk/KDE/build.deb
0002:D110 | 75 67 2F 6B  64 65 75 74  69 6C 73 2F  6F 6B 74 65 | ug/kdeutils/okte
0002:D120 | 74 61 2F 63  6F 72 65 2F  6F 6B 74 65  74 61 63 6F | ta/core/oktetaco
0002:D130 | 72 65 5F 61  75 74 6F 6D  6F 63 2E 63  70 70       | re_automoc.cpp

There is one more feature I would have liked to get done for KDE 4.1, but which won’t make it now: support for very large files. Is rescheduled for KDE 4.2. Until then just do not load too large files! I should perhaps add a warning to the file selector.

Spring-cleaning of KDE Utils is done

Since the release of KDE 4.0.0 there have been quite some changes in the module kdeutils up to now:

Moved in:

• okteta
• printer-applet

Stayed:

• ark
• kcalc
• kcharselect
• kdessh
• kdf
• kfloppy
• kgpg
• ktimer
• kwallet
• superkaramba
• sweeper

Moved to kdepim:

• kjots

Moved to playground:

• kdelirc

Moved to unmaintained:

• klaptopdaemon (successor is worked on in playground)
• kmilo
• ksim
• charselectapplet (plasmoid already exists)
• khexedit (directory already contained only Okteta libs)

So if you miss one or the other program, now you know where to look.

The call for new maintainers was quite successfull. The only program left in kdeutils without an interested person is kdessh:

• Michael Zanetti now cares for kdelirc in playground, looking how to add a solid base.
• Sascha Peilicke, Troy Campbell et Bart Slootweg are having some thoughts about the future of KWallet, while Michael Leupold is already busy fixing the current codebase.
• Ben McDonald is looking to get a take on KRegExpEditor.
• Pino Toscano took over maintainership for Sweeper.
• Constantin Berzan is going for KCharSelect.
• Alex L. Spehr sees what she can do to KTimer.

Want to join? Subscribe to the KDE Utils development mailinglist!

Adopt a KDE Util as your baby

The module KDE Utils is getting a cleanup currently. Which in the process opens opportunities for you to take over some responsibility for a part of KDE and enhance it even more:

The programs listed below are working, thus are going to be part of KDE 4.1, but are without a real maintainer. They got ported by KDE’s main v3->v4 porters and some, but then noone really sees them as their baby, cares for them and has a master plan how to make them even better*. Do you perhaps?

• kcharselect - select special characters from any fonts and put them into the
  clipboard (applet variant still needs porting to plasma)
• kdessh - front end to ssh
• KFloppy - format a floppy disks with this program
• KTimer - execute programs after some time
• KWallet - KDE wallet management tool
• Sweeper - cleans unwanted traces the user leaves on the system

Then there is kregexpedit, the good old regular expression editor, waiting for someone in playground/utils to pick it up again, as the person willing to do so before sadly has run out of time. Won’t be part of KDE 4.1 of course, but the luxury of being a program’s developer is that you can still compile and run it yourself and do so from the bleeding edge all the time

The programs listed next are not working or not compilable and also without any maintainer/developer. They got partially ported to KDE4, but nobody has really cared for them, so they are currently disabled in the build system. Are you interested in taking over development of any of them? As we are in soft feature freeze mode now you would have to restart development in playground/utils and have a first chance for inclusion of the program with preparations for KDE 4.2 again. Still you can make independent releases in the meantime of course. Or move to extragear if you like. All of the below which will not find an active maintainer until May 2nd will be moved to tags/unmaintained/4 otherwise.**

• kdelirc - frontend for the Linux Infrared Remote Control system
• kmilo - kded module to support various types of hardware input devices
• ksim - plugin based system monitor

I suppose that ksim is obsoleted by solid+some plasmoids.
KDELirc looks like it should better end in Solid and kdebase/workspace/kcontrol/.
kmilo might be a candidate for that, too?

If you are interested in taking over maintainership of one of these programs please subscribe to the KDE Utils development mailinglist and say Hello.

You are also invited to subscribe if you are just interested to follow development in KDE Utils in general.

So far there have been two adoptions already:
Thomas Gillespie is looking to care for a future of the functionality of KLaptopDaemon.
And Nicolas Ternisien is already giving much love to KDF (KDiskFree) and is merging it with the Partitions module for KInfoCenter, and it’s looking good:

So, is one of the babies smiling at you?

* For KDE 4.1 you would be limited to make only existing features shiny, given that the soft feature freeze already set in. Yet this makes you familiar with the code base, so for KDE 4.2 you can go crazy.

** Of course this does not stop you from taking over even at a later point, but things in unmaintained just are out of sight and do not even get random updates to latest kdelibs changes.

Okteta on its way to kdeutils + WhatsThis

The longest journey starts with the first step. Or: The biggest program starts with the first line. (Just: These terms do not contain any mentioning of the category time. I definitely need other proverbs which complement these to help me with life.)

Now, that a lot of lines have been collected in the subdirectories of the Okteta project, a new milestone is approached: The stand-alone program Okteta is heading for inclusion in kdeutils. Since Monday its code resides in kdereview, awaiting your objections or change requests.

Christian Ehrlicher already did what looks like almost every KDE4 module is having to cope with: He adopted 5 lines (in words: five, really only) and now it compiles also under another platform, delivered from Redmond. Impressive. CMake, Qt and KDE, your friends for almost-instant-multiplatforming, obviously.

Instead of an image (for a screenshot just go and build the code yourself) this time some words (just not thousands) for those, like Thomas Z., who are still curious what Okteta is at all:

Okteta is a successor to KHexEdit for KDE 4.x. It is a simple editor for the raw data of files. This type of program is also called hex editor or binary editor.

The data is displayed in the traditional view with two columns: one with the numeric values and one with the assigned characters. Editing can be done both in the value column and the character column. Besides the usual editing capabilities Okteta also brings a small set of tools, like a table listing decodings into common simple data types, a table listing all possible bytes with its’ character and value equivalents, a info view with a statistic and a filter tool. All modifications to the data loaded can be endlessly undone or redone.

Due to its very modular design it should become soon extensible for plugins.

So yet another hexeditor. Besides, this one can use sexy Oxygen.