Welcome to KC KDE! This week in KDE development was a busy one. The recently released KDE3beta2 was superseded by KDE3rc1 and then KDE3rc2. These were primarily intended for developers and users who are willing to compile from source. Many issues were identified and fixed as a result of these quiet releases.
A few discontent developers weren't so quiet, however, and caused a fairly public controversy over the KDE3 development cycle. A rather blunt rant complaining about various problems in the KDE3 development process as perceived by the authors was cross posted to the two primary development mailing lists. The email was picked up by both Newsforge and Slashdot. This sparked much discussion both in and out of the KDE development community. While it is dubious that the ranting email had any direct positive effects on KDE, hopefully everyone involved in KDE development will consider what fomented the outburst in order to improve future releases.
In more positive news, KOffice has been showing remarkable signs of life. There was active development in KWord, KPresenter, Krita, Karbon, KSpread, the core KOffice libraries and several of the filters, including the PowerPoint filter. It appears that a recent influx of new developers to the KOffice project, thanks largely to attention KOffice has received in the online press, is starting showing results.
We hope you enjoy the rest of this week's summaries and Happy Hacking!
C++ offers an improved type casting syntax over C and developers are encouraged to use C++ style
casts. Unfortunately, commonly used compilers have problems with some of C++ casts, in particular
run-time casts used in dynamically loaded libraries. Regarding this shortcoming Joseph Wenninger wrote,
Pavel Troller detected a crash problem in my
sidebar for konqueror with gcc 3.0.4.
I don't have this compiler, but it seams to be a
problem with dynamic_cast in a dlopened library
^H^H^H^H^H^H^H plugin. It happens for instance in
konqueror/sidebar/trees/dirtree_module/dirtreemodule.cpp
in line 35.
Does someone know of a quick and not that dirty
fix for this problem ? Do I have to add special
link parameters to get it working ?
Simon Hausmann replied,
See
http://lists.kde.org/?l=kde-core-devel&m=100746955931520&w=2
and related posts in the thread. There is no way for us to get rtti
working in that case, unless we use RTLD_GLOBAL (which is fatal for
us) . Use QObject::inherits if you can.
In the wake of a long discussion to find a new name for the KOffice graphics
program Krayon, Patrick Julien asked,
If there are no objections, could I be the krayon maintainer?
There
were no objections, only encouragement. Since Patrick has become the maintainer of
this long-neglected KOffice application, now called Krita, there has been a steady stream
of development.
Konqueror and the KDE file dialog can show thumbnails for several types of files.
Simon MacMullen has been working on adding KOffice files to this list. Simon wrote
the KOffice development list with an update on his progress saying,
My continuing obsession with thumbnails has now created one for koffice
files:
http://www.babysimon.co.uk/kde/kofficepreview.png
If you look carefully at the code you may see traces of the HTML preview and
Philippe Fremy's KParts tutorial :)
Simon has continued to work on polishing and improving these thumbnails with the input of other KOffice developers. This has resulted in some useful improvements to the KOffice libraries as well.
Near the end of February 2002, Adam Treat wrote an email to the kde-devel
list saying,
Just wanted to let anyone who might be interested know what is going on with
the Qt c# bindings. Tonight, I was finally able to compile the bindings for
476 Qt classes. The hello world example is now referencing this compiled
dll. Slots and Signals are also fully implemented and all of this running on
linux with mint and mono. mcs is not able to compile the bindings _yet_
although I have been able to exercise mcs a little and point out some bugs
;-) There are still quite a few tasks before the qt bindings will be useful
for real development
Adam listed four areas that needed further
work to complete these bindings, such as including the KDE classes.
Richard Dale replied saying,
If you can do it for 300+ Qt classes, then it's just more of the same for
KDE.. You can convert KDE kdoc comments to C# style xml, which should be fun
though. [...] the code is also most welcome in the kdebindings CVS too.
Maybe it wouldn't do any harm to have it in both places. But if you check in
the kalyptus C# + P/Invoke bindings code generation option into kdebindings,
I would be happy to help tweak it.
Adam noted that the KDE classes
were indeed next on his list but that he wanted to refine the Qt bindings first before moving on.
Just over a week later Adam said,
Well, the bindings are ready for an initial commit. This is pretty good
timing because Mono just became self-hosting tonight. That means people can
start compiling and using the bindings on linux, without need for
Microsoft's .Net SDK.
Finding people who are willing to write and translate documentation is challenging enough without discouraging their efforts by destroying months of hard work. Thousands of translations were temporarily lost when an errant documentation commit was made to CVS without coordination with the documentation team. Fortunately the translations were retrieved by reverting to older revisions in CVS, but this took many hours of what could have been productive time away from documenters and resulted in some frustration. Lauri Watts, the KDE documentation coordinator explained:
It is *deeply* appreciated if people volunteer to write documentation on their own initiative, but please be aware that committing docs without checking with either me directly or even better kde-doc-english mailing list is causing some real disasters. I'm going to assume it's because you're not aware that these things affect i18n or docs, so I'm going to lay it out for you here.
If you plan to start writing a document that is currently unmaintained, or you just want to patch one that's already there, please say so on kde-doc-english *BEFORE* you start.
If we know you're doing work, we can keep the translation templates in sync. [...]
Don't *EVER* rename a doc file, unless you're going to check out kde-i18n and fix the resulting carnage for every language that has already translated it. You'd rather avoid that? Then if you want document files renamed, ask kde-doc-english or me directly to do it.
*ANY* change to translateable strings, including completely removing or adding buttons should get a GUI: tag in their commit. Things with GUI: in their commit logs get forwarded to me separately, and I can forward them on to the documentor concerned, or fix the docs myself, whichever is most efficient.
Although you can substantially change an application's behaviour and appearance without affecting translateable strings and breaking the message freeze, do remember that it's still going to make the documentation entirely wrong. Use the GUI: in your commits, or post patches to the docs when you post your patches to the code for review.
[...]
We deeply appreciate when you write documentation, but it is less appreciated when the result is hundreds of hours work by potentially hundreds of other people is summarily thrown out. Simply keeping us informed would avoid this.
The concept of introducing CVS ACLs on documention was suggested
but Lauri said,
I actually considered asking for this, but thought I'd try a little
education first.
While not as desirable among organic creatures, having multiple
back ends is a highly sought-after feature for digital creations as it allows for greater
flexibility and diversity. Attempting to endow KDE3's new address book with
the ability to use multiple back ends for storage at run time,
Cornelius Schumacher posted a series of patches saying,
The attached patch adds the option to libkabc to attach different backends,
e.g. a SQL database or a LDAP directory. The patch moves dependencies on the
file backend behind an additional layer of Resource classes. There is an
example class ResourceSql, which accesses data from an SQL database. It's not
really useful at the moment, but it serves as a second case for testing the
design. It would be good to add the patch before the 3.0 release, because otherwise we
wouldn't be able to add it before the next binary incompatible release.
After several reviews of the patches and only positive replies, Cornelius committed the improvement to CVS.
