FEB
17
2005

What I learned at LWE

Presenting KDE as an exhibitor at LWE is an interesting experience. I've learned a couple tricks that make things more interesting, both for me and for booth visitors:

FEB
9
2005

DataKiosk

DataKiosk is a JuK-like database interface tool for generic SQL databases. What does that mean? Essentially, DataKiosk provides a series of wizards (anyone familiar with Qt Designer's database wizards will find them familiar) that allow you to build a custom Juk-like interface for any SQL database with a QtSQL driver. It now resides in kdecvs in the kdeextragear-1 module.



DataKiosk 0.5


JAN
26
2005

Solaris, Java and the CDDL

By now everyone has heard of Sun's foray into Open Source Solaris. Groklaw has an interesting run down of the incompatibilities between the CDDL and the GPL. I find the whole thing tremendously interesting, but when you really think about it and the possible implications for Linux, it is not all that exciting. Sure, Solaris 10 is a hell of an operating system by most accounts, but at this point I think of it like the hoopla that surrounded Apple's release of Darwin. That too, was one hell of an operating system, with all of the doomsayers heralding it as the end of Linux... Well, a few years later not so much. Heh.

SEP
13
2004

KDevelop C# Language Support

So, I've been working on some kdevelop language support C# for the past few days. I already have some pretty interesting screenshots, but I recently discovered that KDevelop is going through a major change in the way it handles different build systems. Roberto Raggi is working on a New Project Manager (NPM) that will form the basis of a common project editor widget for all the various languages. Individual language/buildsystems will then customize the interfaces to this NPM in order to provide language/buildsystem specific features. It is a great idea as it will cut down on the duplication of code in KDevelop and provide some standard and uniform UI widgets. Since I found out about it, I've been porting my initial C# build part to this new architecture. More...

SEP
7
2004

Update on the C# bindings

I just added features regarding the C# bindings to the 3.4 feature list. As 95% of the major work towards the new super spiffy Qt# bindings is done, I figured it was time to set some goals for getting all of this in shape for a KDE release. For those curious about the current state of my bindings (as opposed to the other C# bindings efforts) this kind of stuff is working now. For those confused by all the myriad twists and turns of the various C# bindings efforts here is a short history:

  1. The original C# bindings for Qt were initially created with the Kalyptus tool. Richard Dale helped me greatly when I first started out with this approach. After awhile the obfuscated perl code wore on me and I decided to create a C# generator.
  2. The first (and only) functional Qt# binding was created with this first generation C# generator that has no name. It generated the C# source by parsing a xml based metadata file that was created with... get ready... kalyptus. The code really, really bites. I'm embarrassed by it really. And to add insult to injury, the kalyptus extension that I wrote to output the xml has been lost entirely.

That is the current production state of things and has been for quite sometime. If you go to the Qt# webpage you'll find the fruits of this generator.

AUG
18
2004

MS touts new C++/CLI standard calling it most powerful language for .NET

Just came across this article via msdn, C++: The Most Powerful Language for .NET Framework Programming. Microsoft seems especially pleased with their new version of Managed C++. They've done a complete revamp of their previous .NET support for C++ and submitted it to ECMA and ISO as a standard. This brings C++ inline with C# as far as first class support for the Common Language Runtime. I really like what they've done to improve the C++ experience for .NET, but still think it will be incredibly hard to adapt the Qt/KDE libraries to fit into this framework. Consider this annoyance, the new proposed standard mandates PascalCase be used for the core API. For a technical challenge you'd have to consider how to integrate MOC and the new C++.NET properties. Read on.

AUG
14
2004

To byte code, or NOT to byte code? Is this really the question?

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.

Pages