Copyright © 2008 Alan Ezust and Paul Ezust

One picture is worth more than 10 words, but that's the limit for a blog entry

Due to our little hackweek project winning in two categories, I have the rest of the year so called "Innovative time off". In the beginning 10 days ITO sounded like nothing, but now I'm kind of forced go give up on real work and do fancy experiments

So I tried something. Certain voices claimed, porting Yast to Qt4 would be almost impossible due to the different event loops and threading and all that. But thanks to Thiago's little explanations on how things to go together, it was actually a job done pretty quickly (it was once tried in july, so I didn't start from scratch). Damn! Did I say, I have the rest of the year?

Anyway, here you can compare qt3 to qt4 when running the infamouse Wizard3.ycp example:

I don't know about you, but there's this hugely annoying behaviour of QDockWidgets. Since Krita 2 uses them, I tend to run into it a lot. The symptoms are simple: if you have a floating dock widget and Krita loses focus, the dock widget gets hidden.

Sounds like a rather silly annoyance, you might think. I'd agree with you, if not for the fact that I run into this all the time. Not only that, but I can actually provide a plausible scenario that would make using some configurations of KDE4/Krita2 impossible to work with.

My personal annoyance is because of my Krita coding workflow. Often I break some feature, and then debug it with gdb. What I do is sparkle some breakpoints around Krita, and let Krita run into them. Since I have plenty of screen space, I scale my Krita window so that it fits in the top half of my screen. That way, I can trick Krita into triggering a breakpoint, and see gdb breaking on the bottom of my screen.

So far so good. But if I now transfer focus to my gdb, the unplugged dockwidgets suddenly disappear, while my Krita window stays there.

'Ok', you say, 'but I don't debug like that!' Sure, but you might run into it anyway, as a user! Maybe you like focus-follows-mouse. And perhaps you like to style your Krita like the GIMP (don't laugh, some people like this) by undocking the tool docker. This combination is, unfortunately, impossible at the moment.

This afternoon, I finally got so fed up with it, that I decided to try and fix it, at least for myself. After wasting a time figuring out exactly what was going wrong, I came up with 3 possible fix vectors. The first one was looking into KWin, as I am still unsure if this is a Qt bug, or a KWin bug (I'm betting Qt, since it's always easier to blame ). Since my Kate was already filled with Qt4.3 source files, I decided to stick with fixing Qt.

The second possible fix was changing the isTransient function, forcing windows with a Qt::Tool windowtype to not be transient. This worked, but had the silly side-effect of adding my dock widgets in Kicker's window list.

Leading me to the third and final fix of forcing the window type of dock widgets to not be of the 'utility' type. This doesn't have the previous silly side effect. As a bonus, though, the dock widgets are listed in Alt+Tab, just the way I like it! (This has the minor silly issue of labeling the window in Alt+Tab as '&Tool Options', but I can live with that .)

This is the patch (against an ancient svn revision of qt-copy 4.3.0, which is kinda outdated) (the 'tt' tag seems to lose indending spaces, weirdly enough, but I'm not willing to use nonbreakable spaces here; probably looking in the HTML source will give you the right formatting):

Index: gui/kernel/qwidget_x11.cpp
===================================================================
--- gui/kernel/qwidget_x11.cpp (revision 671344)
+++ gui/kernel/qwidget_x11.cpp (working copy)
@@ -563,7 +563,8 @@
net_wintypes[curr_wintype++] = ATOM(_NET_WM_WINDOW_TYPE_TOOLBAR);
} else if (type == Qt::Tool || type == Qt::Drawer) {
// utility netwm type
- net_wintypes[curr_wintype++] = ATOM(_NET_WM_WINDOW_TYPE_UTILITY);
+ if (!q->inherits("QDockWidget"))
+ net_wintypes[curr_wintype++] = ATOM(_NET_WM_WINDOW_TYPE_UTILITY);
}

if (dialog) // dialog netwm type

The reason I'm posting this here instead of bugging TT, is that I'm actually quite sure this behaviour is intended: the detached toolbars already behaved liked this, even in Qt3.x. But since I don't detach regular toolbars, that never annoyed me. For those that are annoyed by it, though, this could be a place to fix it for you, too. Also not that I can give no assurances that this fix is actually correct! I have absolutely no knowledge at all about windowmanager specs and so on, so this might as well break your system (Unlikely, but one never knows...)

There are other things I hate about my KDE4 install atm. The most hateful one is the 'Temporary KColorScheme change' by Matthew Woehlke, but at least there I know which patch causes it

My Application of the Day: Kochizz for Apache2 Configuration

My application discovery of the day (well of the yesterday, to be more precise), is Kochizz. Kochizz is a Qt4-based GUI tool to get to grips with the Apache2 configuration.

As anyone who ever tried to set up an Apache2 web server may know, this can be an insanely complicated task, because the thingie can use multiple configuration files at once, which are included and nested into each other with (you guessed it?), Include directives.

Kochizz makes that job much easier now. Mind you, Kochizz is not yet released as a stable application, but it is already in Release Candidate 1 shape. Being a Qt4 app, it means you get Linux, Windows as well as Mac OS X versions... for free. Not least because the license is GPL v2...

.

This is a detail screenshot of the brand-new Kochizz ("Configure My Appache2 Installation") application depicting its GUI "Property Editor" component. See also for a fuller description in my main posting.

Things to remark:

• I had deliberately inserted a typo ("Serveros") in the configuration to see how Kochizz handles that. (See the previous shot to see how the Text Editor component handles it). Note how directive is displayed in a different color due to the typo.
• See the "MinSpareServers" entry underneath? The enabled checkbox means it stems from a commented out directive (to re-enable it, just remove the checkmark). (See also the previous shot).
• Note the balloon help frame: Kochizz uses the original Apache2 documentation to display help for each configuration directive. (Full help texts are available via the context menu.)

This is an detail screenshot of the brand-new Kochizz ("Configure My Appache2 Installation") application. See also for a fuller description in my main posting.

Things to remark:

• I deliberately inserted a typo ("Serveros") to see how Kochizz handles that. Note how you can see it does underline the typo.
• In the next shot you'll see that the very same typo is propelled into the GUI "Property Editor" component, but also highlighted in a different color to indicate something is wrong with it.
• See the "#$*MinSpareServers" entry underneath the typo? That is a commented out directive. However, that comment uses a special syntax, so Kochizz can still display it in its GUI "Property Editor" component, and offer it for re-enabling (see also the next shot). In fact, I didn't use the Text Editor component to insert that comment (though I could have...), but the GUI Property Editor.
• Note how Kochizz preserves all the other comments in their original form.

This is an overview screenshot of the brand-new Kochizz ("Configure My Appache2 Installation") application. See also for a fuller description in my main posting.

Things to remark:

• There are currently 3 different main tabs with 3 different Apache2 configurations opened (top row of tabs).
• Left pane shows the treeview of the full configuration. Note how you can see which directive is originating from which Include-ed sub-config file
• Right pane shows a GUI representation ("Property Editor") of the individual directives contained in the tree leaf that is highlighted on the left. Note how you can switch to the "Text Editor" on the second tab.

There are also two shots showing more details: one showing the config editor in GUI "Property Mode", one showing the raw config text editor mode

(Click on "original" link below to see the shot in full size.)

I started Jambi package to Mandriva at Akademy this year, but process was complex since we're dealing with buildsystem changes, Java new packages, Qt4 layout changing, so lots of barriers to get the task done.
My personal effort on this is have next Mandriva releases be ready for developers in all cases, to use best available Qt and KDE technologies as possible, improving our situation from the past.
Then, yesterday i had all things in really good shape, and finally a good initial package could be produced.
I tested many environments. gcj/ecj was having some compile issues, but java 1.6 sun and the best, java 1.7 icedtea worked as a breeze.
Linking against system Qt 4.3.1 was not a problem at all. Great that both i586 and x86_64 arches are compiled fine as well ( thanks for David Walluck tips ).
So the major trouble in my special case is the install process, as Jambi not provide a proper install script, and even a proper layout to install.
I decided make launcher and designer-jambi scripts to lauch on doc and devel package respectively, and separate Jambi jar and libraries in different packages, and most of files fall down on same qt4 dir on Mandriva.
We fall down with this result:

One should think that reading and writing XML are solved problems. But interestingly there still is heavy development going on in this area. So Trolltech includes their new QXmlStreamReader and QXmlStreamWriter classes since Qt 4.3, which was released less than two months ago. Today I used these classes for the first time and was delighted. This is the first XML API which lives up to the high standard of Qt.

The QXmlStreamReader is a streaming pull parser. That's a great approach because it's easier to use than the SAX parser and is more efficient than using a DOM tree. But for now let's concentrate on writing XML.

The QXmlStreamWriter is the counterpart to QXmlStreamReader. If you look at its API you might think: "That's it?" But it really is that simple. Why did we have to live with hand-crafted XML output via printf, QTextStream or similar awkwardnesses for all the years? One simple example to illustrate how nicely XML can now be written with Qt:

  QXmlStreamWriter xml( &file );
  
  xml.writeStartDocument();

  xml.writeStartElement( "toothache" );

  foreach( Meal *meal, food ) {
    xml.writeStartElement( "candy" );

    xml.writeEmptyElement( "chocolate" );
    xml.writeAttribute( "count", QString::number( meal->chocolateCount() ) );
    
    xml.writeEmptyElement( "softdrinks" );
    xml.writeAttribute( "count", QString::number( meal->softdrinkCount() ) );
  
    xml.writeEndElement();
  }
  
  xml.writeEndDocument();

This writes something like:

  <toothache>
    <candy>
      <chocolate count="7"/>
      <softdrinks count="2"/>
    </candy>
    <candy>
      <chocolate count="5"/>
      <softdrinks count="1"/>
    </candy>
  </toothache>

One slight annoyance is the need to convert integers to strings manually for the XML attributes. This could be made more convenient by providing some overloaded functions. Or did I miss something?

The most elegant way I know to write XML still is the Ruby XML Builder, though. This fully uses the dynamic nature of Ruby and allows to write amazingly intuitive code like the following example which is equivalent to the Qt code above:

xml = Builder::XmlMarkup.new :target => $stdout

xml.instruct!

xml.toothache do
  food.each do |meal|
    xml.candy do
      xml.chocolate :count => meal.chocolate_count
      xml.softdrinks :count => meal.softdrink_count
    end
  end
end

I tried to write something which comes close to the Ruby XML Builder in Kode with my XmlBuilder class, but in C++ it simply is not possible to reach the elegance of Ruby for this use case.

Anyway, it is great to see that even in presumaby simple areas like XML writing there still is progress in the software world. The future is bright