KDE Developer's Checklist

There are a number of things that are easy to overlook when working on KDE applications. I've put together a checklist on to help developers keep track of important items when creating new applications or when making changes to existing ones. You can send me any additions, corrections, or comments. Happy hacking.


> make sure you aren't duplicating an existing application

IMHO this shouldn't stop someone from developing an application if they want to. The more the merrier.

By KDE User at Sat, 2001/03/24 - 6:00am

>> make sure you aren't duplicating an existing application

> IMHO this shouldn't stop someone from developing an application if they want to. The more the merrier.

I think that this is intended more as a guideline... I've only come across two projects that I felt I could finish (being involved in work and the local Rocky Horror eat my time), and finding that one was done (a weather applet) gave me a direction to go in. Now I'm working on using low cost ( US$5 to $10 ) Dex Drives to store GPG keys to create a system by which a file (or later a directory tree) is encrypted unless the unlock media is inserted (a normal PlayStation memory cartridge, which is very inexpensive). Unfortunantly, I can't find specs on the Dex drive, and now I'm slogging through trying to reverse engineer it.

Okay... this reply got a bit off track; but you get the idea - keeping duplication of effort in mind at the start of a project will at *least* make you research what others have done. If you don't like what has already been done, by all means go ahead. Otherwise, you might have another "itch" to address first.


By Evan "JabberWok... at Sat, 2001/03/24 - 6:00am

This is because Linux users are socialist, why have competition when you can have a single unified force all working for a common goal(like Microsoft windows).

By Lee at Sat, 2001/03/24 - 6:00am

Only in the USA is socialism a four-letter word.
(Sarcasm implied ;-)

By me at Sun, 2001/03/25 - 6:00am

> > make sure you aren't duplicating an existing application
> IMHO this shouldn't stop someone from developing an application if they want to. The more the merrier.

So much for a well versed opinion. It is hardly ever so simple. One of the biggest problems in open source is not the projects that get started... it's the ones that never reach maturity. And the idea of checking has a mysterious connection with the concept of open source... you know the one. That you will build a better mouse trap and everyone will jump on your wagon. All too often we find that the simple little project is far more consuming.

If there is something that should be considered it's this. Before you build something see if someone else is building the same thing. Now... if after you check out their project and objectives if you cannot come up with anything that distinguishes what you want to do from them then it is plain foolish not to see if you can team up. OTOH if you have distinct difference in how you see things working it makes more sense to do your own.

Even if you are doing your own project you may still want to share code or information. What bothers me is reading that someone is starting a project, I check out their web site and it's barely useful but does have a thumbnail description. Then I think of several other projects that are relatively identical except farther along. Let's be real people Think about this...

Closed source takes a group of people and squeezes product out of them. So does open source more like a splinter of that group all alone, or a mass movement? Very few open source projects are at critical mass. That being that they would continue just fine if their authors walked away. Many more project would be more mature and more rewarding if people followed the advice here instead of just glibly launching another project that shadows several others with no distinctive purpose.

Ask yourself this. If all the core KDE developers had set out to build their own desktops which one would you be using? Probobly none.

By Eric Laffoon at Sat, 2001/03/24 - 6:00am

Time your self doing these things:

Read 1K lines of code and understand it.
Write 1K lines of code and understand it.

Compare the times. Then ask yourself which was more fun, reading code or designing and writing it.

The reason that KDE can't be made by one person is because it does ALOT of stuff. People code peices of KDE, the peices get rewritten alot. So even in the case of the KDE core people rewrite stuff. The guy who wrote the checklist is probably just a socialist.

By Lee at Sat, 2001/03/24 - 6:00am

I think it's still useful to point out that you might want to look if the application you wish to make already exists. KDE is a desktop environment so there are a huge number of different applications that can be written for it. People want to write their own program, but they also might wish to contribute in a useful way. It might just be possible to find something you would enjoy to make, and isn't already there.

Of course people should make whatever they want to make, but it doesn't hurt to point out what's already there.


By Matthijs at Sat, 2001/03/24 - 6:00am

> make sure you aren't unknowingly duplicating an existing application

NOTE: unknowingly. You're of course free to develop what you want.

By per at Mon, 2001/03/26 - 6:00am

What exactly is a Linux Software Map file? What does it do? How does it work?

By not me at Sat, 2001/03/24 - 6:00am

AFAIK the .lsm is useed to build a description of the project, and when you upload it somewhere it can create an anouncement. Like when you upload to it will post an announcement to kde-announce. I assume it was meant for the official Linux Software Map.

By Jono Bacon at Sat, 2001/03/24 - 6:00am

put some links in there. Most people are too lazy to go find the style guides, etc.

By Tim at Sat, 2001/03/24 - 6:00am

As a humble user, I'd like to add this suggestion:

If your application should only be run by root, make sure it brings up the root password dialog when it's launched by a normal user.

There's one very useful (non-core) KDE utility that doesn't do this. It's not harmful ultimately because the lack of appropriate permissions prevents it from completing its task -- but it is incovenient.

By Michael O'Henly at Sat, 2001/03/24 - 6:00am

Care to tell us which it is so we can fix it? ;-)


By Richard Moore at Sun, 2001/03/25 - 6:00am

KPackage used to do that, but I think it's mostly fixed now (I haven't needed KPackage much since switching to Debian, so I don't know anymore). The KDE SysV init editor does it too. When you start it as a non-root user, it brings up an informative dialog that tells you that you cannot change anything, only look. This is fine, but it doesn't give you the option to run it as root. You have to start up the menu editor, look to see what command starts it (ksysvinit), go into a Konsole, su, and then start it, just to use the program the way it was intended!

IMHO, the way all KDE programs should handle a situation like this (a program has extended capabilities when run as root) is to use kdesu, because a user can always hit the "ignore" button in the (unlikely) case that he/she doesn't really want the program running as root. Also, that "ignore" button in kdesu should be renamed to something that describes what it does, like "run without root priveleges." And, the text "requires root priveleges" should be modifiable by a command line option or something to say "has extended capabilities when run as root" or something.

Of course, the best solution to a situation like this would be a way to change the priveleges of an already-running program, so you only have to enter the root password if you actually do something that requires root priveleges. I don't know if such a thing is possible.

By not me at Sun, 2001/03/25 - 6:00am