FrogBlog

With our latest addition to our team (say hi to Rob!) we reached the space-limit of our current office. Actually considering that Harri and me are sitting together in the meeting/lunch room I’d rather say that we grew out of it already. At least nobody can waste time in meetings this way

So we looked for new offices and recently signed the contract. For the locals, it is in the “alten Gaswerk” which is a really nice area with a beautiful atmosphere. It’s a new building with no interior yet. So the land-lord is setting set up the offices, walls, floor, etc. according to our needs which is really nice.

We will move there later this summer so everybody will have enough space again. Let’s just hope we will stay there for more than a year this time

I’m quite amazed by how technologies which I used to discard as ‘hype’ (like, Solid or Phonon or so) actually seem to work. For real. Maybe I should feel a bit of shame but I don’t since this reflex of being sceptical of projects which have a fancy code name but not visible code base has proven quite useful in the past - helps to avoid working on vapourware.

Anyway, one of the KDE features of which I didn’t see anything other than mockups yet is KDE’s new panel framework thing dubbed Plasma. I was aware of the fancy web page for some time now (now that I view that page again - what the heck is ‘Appeal’? appeal.kde.org redirects to www.kde.org - is that an omen already?) but still, I didn’t actually *see* it yet. Of course, it’s listed as some integral part of the KDE4 architecture, but that’s pretty much all the information I could get out of KDE’s tech base regarding Plasma.

Okay, not quite. There’s the Plasma project page in the techbase. Unfortunately I can’t claim that it made things any less shady for me. Call me a pessimist but I don’t think that it’s a good sign the Raport Menu Plasmoid has a fancy logo but no code. Maybe I’m lacking vision or professionalism but I prefer to have something before I give it a logo or a name. And something means something which I can compile and run and fix.

Well, I’m not trying to be a naysayer here but I think that the situation around Plasma is kind of… shady. My impression is that it’s –> <– this close to dieing the dreaded buzzword hype death. On the other hand, this is maybe not such a bad thing… Read the rest of this entry »

We are currently exhibiting at the JAX 07, the largest Germany Java conference and expo. It is certainly the largest expo we have been to and also the conference with the longest opening hours (8:30am - 9:30pm)

The traffic at the booths is average compared to other shows we have been to. It’s is good to be here since we aren’t very known in the Java world yet so this is a good opportunity to get known and show the products we have. The feedback we get is very positive as there is a lot of demand for automated GUI testing which goes beyond the generic tools which are available.

Tomorrow I will have my talk about automated Java GUI testing.

Here is also a picture of our booth.

I had the following problem on the Mac: in certain circumstances I want to always display a tooltip and change the text of the tooltip as the mouse moves over different objects. So I looked around and I found the Carbon Help Manager Reference.

The functions HMDisplayTag() and HMHideTag() seemed to be exactly what I was looking for. Implementing this was rather straightforward and it worked most of the time. But sometimes it simply stopped working; after some debugging I found out that after the call of HMHideTag(), I did not get any mouse moved events anymore.

So I looked around for other solutions and found the tooltip article on CocoaDev. That one looked really promising. It has two different approaches of implementing your own tooltips with Cocoa. But since they simply display a window with a style that resembles tooltips, I continued looking (after all, if I use Apple’s tooltip API, I am more likely to get a correct look of the tooltips, especially if Apple decides to change the look of tooltips at some point).

But on CocoaDev there is also an article that shows a different approach: it uses the Cocoa NSHelpManager class to do this job.

This code simply uses the showContextHelpForObject:locationHint: function to show the tooltip and the removeContextHelpForObject: to hide the tooltip. Happy to have a found another solution, I tried this and showing the tooltip worked just find. But to my disappointment, I was not able to get rid of the tooltip anymore — the removeContextHelpForObject: did in fact not hide it. I tried several different ways, but with no luck.

So to cut a long story short, I ended up with using HMDisplayTag() again to show the tooltip. And since the HMHideTag() call was the only thing that caused me trouble, I simply replaced it with:

    WindowRef helpTagWindow = GetFrontWindowOfClass(kHelpWindowClass, true);
    if (helpTagWindow)
        HideWindow(helpTagWindow);

As far as I can tell, this works just fine for me. So I will stick to this unless I discover any mayor problems.

Continueing my rich history of bikeshed-quality blog posts, I proudly present:

Three common ways to declare the iterators for iterating over a map:

1. for ( map<string, string>::const_iterator it = map.begin(); it != map.end(); ++it );
   Not bad. Unfortunately the line is kinda long, and the .end() function is queried over and over again. On the plus side, the iterator is nicely scoped (only valid within the loop) - but that doesn’t work with MSVC6. Oh well.
2. 
map<string, string>::const_iterator it = map.begin();
map<string, string>::const_iterator end = map.end();
for ( ; it != end; ++it );

   Not so cool. Both ‘it’ and ‘end’ outside of the scope of the loop. Might be what you want (for instance, the loop could break as soon as it (no pun intended) found a match. The super-sort for() line looks nice, and there are no unnecessary calls to map.end().
3. 
map<string, string>::const_iterator it, end = map.end();
for ( it = map.begin(); it != end; ++it );

   My personal style. The lines are both pretty short - in particular, I don’t have to type the silly map::const_iterator string twice. map.end() is queried only once.The only thing which bothers me (a little bit) is that ‘it’ and ‘end’ are valid outside of the loop, which is usually not what I want. I usually put the whole thing into { } to fix that.

How do you do it?

This week we held 2 webcasts in cooperation with Trolltech about testing Qt applications with Squish. Doing such a webcase was certainly a new kind of experience. It is very different from an actual talk at a conference or an on-line conference with prospects where you present a product.

The reason is that you don’t really get any feedback during the webcast (unlike on-line conferences, which usually are rather interactive and actual talks where you see the audience). So during the presentation you don’t really know if anybody is still listening

But given the questions afterwards, attendees were able to follow the live demonstration well and the feedback was really good. So this was a good experience and we certainly will do Squish webcasts on a more regular basis now to give evaluators and prospects a chance to see how Squish can be used efficiently.

Next week we will be exhibiting at the JAX in Wiesbaden - one of the largest German Java conferences.

We will show our new Squish for Java edition and also Squish for Web since I expect to meet many people doing Java backend/Ajax frontend there. In addition I will give a talk on automated cross-platform testing of Java GUIs (Swing, SWT, etc.) on Thursday in “Saal 12d” at 8:30 in the morning.

So if you happen to be at the JAX make sure to stop by our booth and at least grab one of our infameous frog candies

When we pre-announced Squish for native Mac OS X testing, maybe half of the people being interested in it, were developing with Carbon. At that time we had Carbon on our todo list, but nothing was implemented yet, since we believed that Cocoa was the more popular toolkit.

It seems that we were wrong. So we decided to give Carbon support a higher priority and I started working on it. The work on it progressed smoothly and after implementing the object model for Carbon (based on the HIObject/HIView classes), I was soon able to record simple mouse clicks. Today I finished the replaying of mouse clicks.

So now, it is possible to record and play back the first tests for Carbon applications. Much is left to do, though (the object model is very basic, recording of other events than mouse clicks, etc.); but still, we reached a point that shows that there are no unsolvable technical obstactles left — what’s left is just to implement the missing features.

One of the nice things Apple did, was to make it easy to mix Carbon and Cocoa into one application. So we don’t need separate wrappers for Carbon and Cocoa; and the tester does not have to specify what toolkit the application uses. The same binary just works for Carbon-only, Cocoa-only and mixed-Carbon-Cocoa applications (it works for both, Carbon-in-Cocoa and Cocoa-in-Carbon).

But now I have to go back to do some hacking, so that you can get your hands on this soon.

I’ve been touching this function which happens to call itself recursively and found that in order to add some feature, I needed to know how deeply I recursed into the function already. Null problemo, I thought:

void f()
{
    static int recursionDepth = 0;
    ++recursionDepth;    

    printf( "Recursion depth is: %d\n", recursionDepth );
    // Lots of code here; for each return path, don't forget
    // to decrement recursionDepth!    

    --recursionDepth;
}

Very little code. Very easy to understand. Very error prone. And - in case you have to keep track of the recursion depth in other places, very repetitive.

The #1 problem is that it’s very easy to forget to decrement the recursionDepth counter variable in case you return from the function somewhere else than the end of it. I happen to do that very very often, and I know myself well enough to know that I’ll probably forget to care about the recursionDepth variable if I add some new code (with a new return statement) in the middle of that function.

Luckily, I found a pretty easy solution to this though. Read the rest of this entry »

Best code is written with bad weather outside. This was proven by Maks recent work on KDE’s JavaScript engine at least. While cold and snow were plaguing North America Maks developed some nice and effective optimizations that were merged into trunk last night.

Now what was this about? The easy but slow dynamic variable lookup of KDE 3 is now replaced by a static lookup where the symbol can be bound to a local variable. On the other hand, local variables are skipped if a variable is known not to be part of the set. Due to the dynamic nature of JavaScript this approach cannot be used in all cases but wherever it applies the speedup is very noticeable. Two performance test cases supplied by Richard Moore and the iBench JavaScript test finished in 13% to 39% less time than before. Quite a bit for a single patch!

If one considers the sum of all the latests improvements done by KHTML hackers from and outside of Konqueror will perform significantly better in KDE 4. iBench and Ian Hixie’s JavaScript and DOM performance tests show a speedup factors of 2, 3 and sometimes even higher! This leads to a clear outperforming of Firefox 2.0 in some HTML test cases.

Above results will not apply 1:1 to every page. Some bottlenecks are definitely still left but will be addressed for KDE 4.0 or later releases.