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 ).