"Linux Gazette...making Linux just a little more fun!"

Mosfet is a key developer in KDE Project and ahead a great reponsability as the world waits for KDE2 and KOffice suite releases. Mosfet told OLinux about the details related to KDE2, its current development stage and how "KDE2 intends to compete with Windows head-on in all features".

OLinux: Tell us about our career: college, jobs, personal life (age, birth place)

Mosfet: Well, I'm 25 years old and was born in Chicago Il, USA. When I was a child we moved to Austin, Texas and I'm currently living in Indiana. As far as a personal life, that is mostly just something that exists in theory for me ;-)

I went to school at Purdue University in Indiana and started doing Unix admin professionally when I was 19. I started with Unix when I was around 15 yrs old with a bootlegged copy of Xenix because I wanted to do 32bit graphics programming. Previously I was making DOS calls in assembler to the extended memory manager, throwing myself in protected mode to do calculations, then going back to real mode. Unix was pure joy compared to that :)

Once I got older my career has been pretty much swinging back and forth between work and education. For most of the time work involving Unix has focused on both administration of Oracle and either Digital Unix (now Tru64) or HP/UX database clusters and custom application development for database interface applications. Recently, with the advent of Linux and user interfaces such as KDE, I have been involved with that and am now paid by Linux Mandrake to work on KDE2 full time.

Olinux: What are your responsibilities at KDE? Do you have any other jobs?

Mosfet: KDE2 is my sole focus at this point. I am responsible for widget and window manager style engines (dynamic look and feels written in C++), widget and window manager theme code, the plugin mechanism for the window manager, a lot of the new panel's code is mine (although recently Matthias Elter is working a lot on this), some of the KDE graphical effects engine, and a new extensive image management system called "Pixie".

Of course, being free software people can pretty much choose what they want to work on and when. The best place to see what myself and others are currently working on is my KDE2 development webpage at http://www.mosfet.org.

OLinux: How is KDE organized? Try to give us an idea of how KDE works? How the work is coordinated and managed (servers, directories, contribution, staff payment)? ow many people are involved? What are the main problems?

Mosfet: KDE core development is based on contribution from a large group of free software developers. KDE's core system gets several thousand commits (developers doing stuff and making improvements) a month - you can get exact numbers for a given month at http://lists.kde.org. This is excluding the hundreds of applications not maintained in the KDE CVS and part the KDE project itself. As far as the exact number of individual authors I don't know off hand but there are a few hundred developers registered with our source management system (CVS).

If you write code and it rocks it gets into KDE. Anyone can contribute to KDE, although each project has it's own maintainer and if you want to do extensive work it's best to contact that person first. Once that is done you can work either in our CVS or via patches.

There is a difference between software included in the KDE core packages (such as kdebase, kdegraphics, etc...), and those maintained by individual authors. The core packages are largely a collaborative effort and gets the attention of a large group of developers. Individual packages are usually the efforts of either individuals or small groups of people. As an application developer, the approach you take is largely a matter of style. Do you want a potentially huge group of people fixing things and adding features to your code or do you want to maintain strict control over the development of your app? This largely mandates if your going to be a core developer or maintain a separate app outside of the core of KDE.

OLinux: Does any private company supports KDE? Everyone is volunteer?

Mosfet: Many companies support KDE development. Most notably Linux Mandrake, Suse, Caldera, Corel, Red Hat, and Troll Tech all have developers dedicated to KDE - and that's just what comes to mind. There are also several non-Linux distribution companies I know of that are acquiring KDE developers for free software development.

The difference between KDE and competing projects is KDE developer funding seems to be spread over a wider group of Linux companies. You don't have one or two interests controlling an important group of KDE developers. You have a couple people working on KDE in many different companies and collaborating with each other. A vast number of different interests both by volunteer developers and those working on distributing free software are represented.

KDE also seems to be the choice being made by commercial application developers coming from Windows such as Inprise/Corel. Many of these people can't imagine doing application development in a primarly C API as a step above what they had in Windows, even if there are bindings, etc... The KDE/Qt API is the only one which makes sense to these people. Combining the power of Linux/Unix systems and the powerful C++ API of KDE is a dream compared to what they had on other platforms and what they could get with other toolkits and bindings. This is extremely important considering Linux's growth. If Linux continues growing at it's current rate most of the developers will be coming from non-Unix platforms, where C++ application development has been the standard for compiled GUI applications for almost a decade.

Of course, despite all of the above, KDE core development is maintained and controlled by volunteers. People do it for fun, make applications because they want to, submit patches because they like to fix things, etc... If they are good coders and want a job developing free software, more likely than not they could get it with KDE.

OLinux: What are the main differences between KDE1 and the next release KDE2?

Mosfet: Pretty much everything ;-) The libraries have been rewritten to be more extendable, most of the UI is configurable with XML integrated into the core system, there is a new internet transparent I/O subsystem, a new browser, new HTML capabilites with support for things like CSS, bidirectional text, unicode, and soon Netscape plugins, a new window manager, help system, configuration system, panel, a whole slew of new widgets and classes, widget styles and themes... The list goes on and on.

The main difference is now KDE2 is heavily component based, focusing on the browser. All of the KOffice applications (KWord, KPresenter, KIllustrator, KSpread, KImageShop, KIllustrator, KChart, and KFormula) as well as many other KDE applications such as the PS/PDF viewer, mpeg and image viewers, and DVI viewers are all components now - internet transparent and embeddable in the browser. You can even embed the terminal application in the browser and change directories using the arrow buttons ;-) Pretty cool. KDE easily boasts the most extensive and complete component model support for Unix desktops.

OLinux: Do you consider Corba technology as a advance for KDE in matters of a better functionality? Do you see a lot of programmers using it? Give us some advantages.

Mosfet: Well, actually we found it wasn't an advance for us ;-) The problem with Corba is the API is not ideal and it's very difficult for new programmers to learn. We rely on components more extensively than any other free desktop project has attempted thus far, and the requirement to learn Corba in order to do even trivial KDE development was a huge restriction. AFAIK Gnome got around this by both using components less and providing easier function specific bindings where non-Corba experts are likely to be doing development (such as control panel applets).

This did not seem reasonable or clean to us. Even though we were using Corba for a long time (well before KDE2 development started), and had hundreds of thousands of lines of code based on it with both KOffice and KDE2, people started looking at other standard Unix technologies that accomplish the same thing. Orbit (the Corba Object Request Broker used by Gnome) was considered and was faster than the ORB we were using but still didn't solve the problems mentioned above - which are inherent in Corba. We then came up with the current KParts technology we are using for components. It is all based on standard Unix libraries such as libICE, and allows people to learn how to do fully functional components in less than a half hour. Using KDE you get the most component features such as browser embedding and internet transparency that are extremely fast and require the least amount of effort. No need to purchase 1,000+ page Corba tomes at your local bookstore, you can learn it over lunch :) Once this transition was made the development of KDE2 increased significantly over what was occuring before (an increase of over a thousand commits a month now usually compared to our Corba days). This shows that we made the right choice for developers. As far as interoperability, under the hood all the technology we use is in C and accessible through that, XML bindings are available, and Corba middleware is in the works. AFAIK a Java interface is also being looked into. The interoperability argument for Corba is largely misleading anyways, you need to do custom programming to interface legacy code with the desktop's API's no matter what mechanism you use - it doesn't just happen magically. Both Linux desktops introduce new component API's you need to port to, but using KDE this is extremely easy to do without any prior experience.

You can learn more about KParts and check out the "Learn KParts in 1/2 hour" tutorial at http://developer.kde.org. You can read a small overview I wrote of why we chose the mechanism we did when the decision was made a few months ago at http://www.kde.org/technology.html.

OLinux: About Qt without X, do you think it will run in all Unix's machines and influence some special feature of KDE?

Mosfet: This is an interesting new development. Troll Tech has written a version of Qt (the base toolkit used by KDE), that can run solely off the Linux framebuffer and doesn't require X11. Originally intended for embedded systems, combined with virtual windowed framebuffer windows it can potentially end up as a very low overhead KDE desktop framework. It already offers many advanced features directly influenced by direct framebuffer access such as anti-aliased (smoothed) fonts and alpha channel support.

As far as what varients of Unix it will run on, I currently know it supports Linux although any Unix system with a framebuffer (such as Solaris) shouldn't be that difficult.

Nonetheless, KDE will remain supporting X11. There is no reason not to, one of the reasons for using high level toolkits like Qt is you don't have to deal with the lower level stuff like if your running on a framebuffer or an X server. Also, KDE/Qt is leading the way with this technology and we are the first people to support it with a toolkit used by a desktop. Some users will want access to legacy and non-KDE apps and games, and X11 is essential as a common platform where you can run applications developed under many different toolkits. As far as people who only use KDE applications, they may very well get a quite cool low overhead desktop...

OLinux: KDE1 use to be a heavy application, now that KDE2, adding all this new technology to KDE2, do you think that a new and potent hardware will be required for users to have a good system performance?

Mosfet: Hopefully not ;-) The component model of KDE helps a lot here. When you start KDE1 a lot of things happen like the file manager and browser are loaded, etc... Now KDE is designed to start the absolute minimum until you actually use something - then dynamically load what you need. A lot still happens, but now it is mostly low level stuff like initalizing the client server I/O system and not things like loading HTML widgets.

KDE2 is still alpha and there are issues getting in the way of making this really giving users a gain yet, but it's being worked on. KDE2 will certainly not require any more resources than KDE1, and hopefully will require even less.

OLinux: What are the better features KDE will bring to users that Windows doesn't have? Can KDE already compete with Windows2000 in terms of GUI?

Mosfet: Absolutely! KDE2 intends to compete with Windows head-on in all features - no excuses made. We got the components, the transparent access to the web, the modern C++ API, developer support, and the applications needed to seriously contend for user's desktops. As far as the GUI, that is a matter I specifically deal with and I believe ours is becoming far superior. Although as a fan of Mac and BeOS interfaces, I feel most UI's are superior... what will be the default look and feel of KDE2 is drastically improved from KDE1.

OLinux: When KDE expect to release KOffice1.0?

Mosfet: Alongside the release of KDE2.0, which is now in a library freeze preparing for the second alpha release. I'm not sure if there will be a third or if after that we will go straight to betas. KDE does have a long beta cycle though, we will not release an official version until we are sure it works well for the majority of people. We feel that is our responsibility to the users of KDE, who have come to expect a stable system.

OLinux: How do you see the Digital Society and future of Intenet five years from now? Say something about ecommerce, wireless internet, hand held appliances briefly.

Mosfet: Eeek, a long stream of buzzwords! Hell, I don't know. We will all probably be out of shape and unable to tolerate sunlight because of too much time on the internet ;-) That's about all I know...

OLinux: Send a message to programers in Brazil that work in Free Software/Opensource projects and to OLinux user's?

Mosfet: Brazil rocks! I lost my credit rating there last year...

[By the way, I really like the animated image of the turning gears in the bottom left of the KDE web site. -Ed.]

Copyright © 2000, Fernando Ribeiro Corrêa
Published in Issue 53 of Linux Gazette, May 2000