Been listening to http://us.regmedia.co.uk/2007/10/04/ope ... eworth.mp3 and one point that stuck for me were the comments about modularity and how good modularity helps developers get involved in OSS projects more easily.

Why? well the feeling I get as I start to get into the KDE code base is that KDE is very monolithic. You need to checkout and build a lot of code to contribute to a single koffice app for example. Or to work on a kwin extension even. This makes getting into the code more difficult just because there is so much code to navigate and get your head around (though I admit the code itself is pretty well organised once you do have is).

I sense that this is also felt by potential KDE users. You have to pull in a whole package of apps rather than a single app. This can make it feel like you have to pull in a whole bunch of stuff you don't want to get the one thing you do want. I understand the issues with kparts and in particular koffice being based on parts but I sense that this is still a problem for both users and developers.

Any pointers?

I think KDE developer try to utilize there restricted time by reuse the code. More shared code, less time to write new code.

Sure... don't we all?

But it is also important to manage the complexity of our code by minimising inter-module dependencies.

It is also important, for somebody trying to get into a code base for the first time to not have to look at more code than they need to.

One of the points in the interview I cited was that to contribute a firefox extension you may not even need the firefox code. This low barrier to entry makes for a large community of contributors. Now I'm not saying KDE should be like firefox! Just making the point that the monolithic groupings and dependencies in KDE do present as a barrier to entry.... and I'd certainly like it to be easier for people to use and develop KDE.

Actually KDE is very modular, which is why one has to get so many different parts if one wants a full setup from trunk.

For application development, especially those with their own release cycle, this is mostly unecessary overhead, since they are based on one of the recent released versions of KDE and thus let developers use their distributor's development packages of the dependencies rather than building all dependencies themselves.

The modules themselves, e.g. koffice, are usually also organized into a shared base and independent applications, allowing to selectively build only the application a developer intends to work on.

This is also nicely reflected into the organization of binary packages, where each individual application has its own package which depends on the shared base package. For convenience the whole module is then mapped as a meta package, i.e. it does not contain anything itself but rather depends on all the single application packages.

Cheers,
_

andre_orwell wrote:One of the points in the interview I cited was that to contribute a firefox extension you may not even need the firefox code. This low barrier to entry makes for a large community of contributors. Now I'm not saying KDE should be like firefox! Just making the point that the monolithic groupings and dependencies in KDE do present as a barrier to entry.... and I'd certainly like it to be easier for people to use and develop KDE.

Oh, I'd say that would depend. I wouldn't be able to understand C++ code to save my life, but not everything needs to be written in C++ either. Depending on what you want to do, PyKDE or something similar might be sufficient. And for that, I don't think you need the entire source-tree. An API-documentation and examples may be enough.

Besides, I think it's more suitable to start with python, ruby, or something similar in order to get the basic ideas of programming rather than diving in at the deep end.

Well, first of all, let's establish a fact: Software have dependencies. Some programs have fewer dependencies, some have more. That's a fact of life in the software world. There's no working around it without having to rewrite all those dependencies as built-ins in each program. And that would be suicide.

Since you did not give much details on what you had to compile to get KOffice, I cannot deny or affirm your comment about having to build to get that single KOffice app. Usually, the only real hard dependency of any KDE app is kdelibs, and in KDE 4, kdebase/runtime (to get icons and styles), as well as the other dependencies of those. Other than that, different KDE modules, or different apps within those modules, can have optional or hard dependencies on other parts of KDE. For example, the optional KGet plasmoid, you need to have kdebase/workspace, which includes Plasma (not sure how the setup is now, since libplasma was just moved to kdelibs).

Do you need to actually build all of those? Not really. That depends on what KDE version you are trying to develop for. If you are developing for a released KDE version (branch, 4.1.x), you only need to have headers and libraries for that version installed. These are provided by distros as separate packages. If you're developing for trunk, then you really do need to build them, because trunk and branch will be very different and distros usually don't provide packages for trunk, although some do.

Now you make a comparison about developing extensions for Firefox and developing for KDE. That is not a proportionate comparison, nor is it a fair one. First of all, despite all the power of Firefox, it is just a web browser. To compare it to a full blown desktop environment and application development framework is like comparing grapes to watermelons. Also, developing extensions for an existing, stable release is not the same as developing for a yet-to-be-released version. If you're going to create an extension for a version of Firefox that's in development, you will undoubtedly still have build that development version. But it might be easier because of the second point.

Secondly, developing a Firefox extension is not the same as hacking something on, say, KOffice. An extension just extends the app, as the name suggests. It doesn't change anything in the core of Firefox. That allows the Firefox devs to offer a way for non-developers to create extensions without having to code them. That's why the used XUL. Firefox is written in C++ I believe. Yet to create extensions, you don't write anything in C++. This is analogous to writing python or ruby scripts that extend Amarok, Konversation, or maybe using Kross to extend Krita. Sure, KDE developers could probably follow something similar and provide an easy way to create extensions for apps (that's what Kross tries to do btw). But this has nothing to do with modularity at all. When making a Firefox extension, you don't have to know the Firefox source code, not because it is modular, but because you don't need to see the source code. It's just a plugin.

You say that you have to navigate through a lot of code to develop? Not unless you're planning to develop for all of KDE or for kdelibs. Most of the time, when starting, you only need to focus on the particular area you are working on. Creating KWin or KStyle plugins (window decorations and widget styles respectively) don't require an in-depth knowledge of KDE's code base. You only need to know the relevant API. Sure, we might not have up-to-date or complete guides on how to do that, but it's not entirely difficult. The amount of styles and windeco's in KDE-Look, made by people who don't have an in-depth knowledge of KDE's code base, is proof enough. Similarly, developing Plasmoids, which to some extent is like developing Firefox extensions, only requires you to know the necessary stuff about Plasma. Unless you start adding features found in other places. And, depending on what version you are working on (trunk or branch), you can even just focus on a particular app's source code only. I've done that before (Dolphin and Konversation), without having to muck around much in source code from other modules.

Of course, if you decide to learn the nitty gritty of KDE's source code, then you will definitely have to go through a lot of code. But that's normal in any program, big or small. It just so happens that KDE is a lot lot larger than most programs.

Hey... sorry if I hit a nerve... it was a question more than an accusation It is fair to say though that my experience with KDE has been as a monolithic system. It's rare just to grab a single app from the KDe suite.

Thanks for those who have clarrified some of the ways KDE partitions code and what the dependencies actually are. I'm new to this codebase and still trying to get a mental map so this helps. The instructions for setting up for KDE development are what I have been following. There's a bit of code involved and to be fair I didn't realise I could get away with checking out less. But that is what forums like this are for.

Anda_skoa pointed out that the binary packages are much more separate than I had realised. I'll have to follow up on this (look them up). It will be nice to be able to cherry pick single apps from the various KDE groupings.

I certainly understand the differences between a browser and a DE, extendability vs modularity, so I'm not going to go further on that except to say the key point of that comment was about having a low barrier for entry. Plasmoid dev is indeed a good example. If I want to work on a kwin extension (C++) how much code do I need to checkout?

andre_orwell wrote:If I want to work on a kwin extension (C++) how much code do I need to checkout?

http://lists.kde.org/?l=kwin&m=122590205029757&w=2

Seli wrote:

andre_orwell wrote:If I want to work on a kwin extension (C++) how much code do I need to checkout?

http://lists.kde.org/?l=kwin&m=122590205029757&w=2

thanks... some good info there. will follow up

Don't worry, you didn't strike a nerve. If my post seemed to reflect that, I apologize. I just wanted to give the best response I could.

Sure, a low barrier for entry is always good, but entry to what? What I was trying to point out was that developing a Firefox extension isn't on the same level as, say, developing on Gecko. There are various entry points in development and some will necessarily have higher entry point than others. Some areas might require more knowledge than others. The comparison is not proportional (it's probably the better term than "unfair").

How much code do you need to checkout? As I have mentioned, that depends. If the kwin extension your are developing is for the current KDE release (4.1.x for example), you could simply download your distro's -devel packages, which contains the headers and libraries required to build software. However, if you are developing for an unreleased version, it would be best to build the necessary modules (but not necessarily everything) since the development version is a moving target and you'd want to be able to keep up to date as much as possible.