Categories:
Saturday, 14 August 2004
Boston
When going to Boston for the USENIX conference I started to read Quicksilver by Neal Stephenson in the plane from Frankfurt to Boston. I didn't know much about about the setting of the book, so it came as a surprise that the book starts with the execution of a woman at the Boston Common. Ten hours later I was standing at the place where Enoch the Red watches Jack Ketch doing his job.
Read More
Saturday, 14 August 2004
To byte code, or NOT to byte code? Is this really the question?
Manyoso
|
It seems Trolltech is continuing to wrestle with the problem of pesky developers clamoring for bytecode based (read: higher level) languages. I talked with him quite a bit about this at the recent LinuxWorld in New York, so I know it is on his mind. In his recent interview at aKademy, Matthias even identified this as the "next big thing" for KDE. But, is bytecode really the question? Read on. Q: What do you think the "next big thing" in KDE will be? MATTHIAS: There is one thing that will become increasingly important in the future, not just for KDE, but for all of Linux: a convincing answer to Microsoft's .Net. I'm not concerned about the server, I'm concerned about the client... Still it would be nice to take advantage of JIT-compiled bytecode where it makes sense, and have the two worlds interoperate. Currently there are two technical options: integrating Mono and the CLR, or going for a Java Virtual Machine. Mono at present has several advantages: First, there is no free JIT-compiling JVM that is equally actively developed and it doesn't look like there will be one. Second, cooperating with Miguel and the Ximian group at Novell is probably a lot easier than cooperating with Sun. And third, it is easier to integrate native C++ code with the CLR than going through the JNI. To me, the real thing TT should be concerned about isn't so much nativecode VS bytecode... it is how to satisfy those pesky developers clamoring for higher level language access to Qt/KDE API's. I think this is what TT had in mind creating QSA, but that is only a scripting language. Ultimately, there are three niches of development I think TT needs to cater to:
Read More
Friday, 13 August 2004
To make Clee happy
Chouimat
|
This blog entry is just to make clee happy ... he should be now ...
Thursday, 12 August 2004
Karlsruhe
The last months have been a busy time. Some special things like the USENIX conference, the KDE Free Qt Foundation agreement, the final phase of the KDE 3.3 release cycle or the preparations for the upcoming KDE conference aKademy took a considerable amount of my time in addition to the usual having a job and a family. But it was fun and still is.
Read More
Wednesday, 11 August 2004
Qt 4 - "Interview"
Ok, so Qt 4's listview / table / iconview / listbox replacement is called "Interview" collectively. I started playing around with it last weekend and well, there's some good and some bad. The good is that at least from an initial take on things the performance seems much better. This could just be the double buffering tricking me and making it look smooth since I haven't actually done any really intensive tests on it, but it certainly feels more responsive.
Read More
Sunday, 8 August 2004
Conference fu
I've been working on my presentation for aKademy, and it looked a lot easier before someone posted a link to a guide about lightning talks to the linux.conf.au 2005 organisers list. That lead me to another guide, called Conference Presentation Judo. At that stage I realised I was spending too much time talking about what meta-data is, and why you should have some. That is particularly bad news considering that Scott Wheeler is probably going to spend most of his talk about metadata explaining that.
Read More
Sunday, 8 August 2004
Hack-o-rama -- TagLib, JuK, KDE, MusicBrainz, aKademy
Ok, as usual it's been a while, but I've had a reasonably productive last couple of weeks -- I've been hacking on quite a few things and generally doing a good job of overextending myself as usual. ;-) Here's a run down of the last couple of weeks:
Read More
Sunday, 8 August 2004
KApplication dependency sucks
Krake
|
Caution, rant ahead!
I started working on an extension library for Qt applications which should enable them to use service or features offered by desktop APIs without creating link time dependencies on the respective desktop libs. http://www.sbox.tugraz.at/home/v/voyager/qds/index.html
Read More
Friday, 6 August 2004
KDE_3_3_BRANCH
Beineri
|
For those not following the mailing lists, the KDE_3_3_BRANCH (and ARTS_1_3_BRANCH) has been created in CVS from which the release candidate and the final KDE 3.3 release will be created. kdelibs/kdecore/kdeversion.h already states "3.3.0" and won't be touched soon again so you can do a CVS build without fearing a complete rebuild to get 3.3.0 Final. Coolo has created release candidate tarballs which are currently tested for compilation. They should be publicly available tomorrow (without binaries) when I will also commit an updated Konstruct version.
The colors of the latest splash screen are said to be changed (to look less childish/cartoonish) and there seems to be a recent regression within Konqueror which immediately deselects text selections. Other than that everything looks fine and there are afaik no other showstoppers known (yet).
Read More
Wednesday, 4 August 2004
System Tray Getting Full
Jriddell
|
A quick rant: I don't like the system tray getting full for no good reason. My system tray is getting almost as bad as the ones on a Windaes desktop where device drivers put their company's logos just because they can. Why do an increasing number of KDE apps insist on not quitting when I those their windows and instead stay around in the system tray. When I close the main window of an application I expect it to quit, this isn't MacOS. But Noatun, KGet, Akregator, KSCD, Kaffeine and no doubt others just hang around for no good reason. I'll let KMix off because it can actually be useful. JuK shouldn't be needed either since everyone should use the mediacontrol applet which is wonderful.
Read More