How to get started with Dolphin development

First of all, I would like to say thanks to everyone who provided help and support since I took over Dolphin’s maintainership. Two patches have been contributed already (1, 2 – the first one will be in 4.9.0, but the second one not due to string freeze issues), and some people helped to handle the incoming bug reports. I would like to mention Christoph Feck and Jekyll Wu here because they have triaged lots of bugs over a long period – thank you very much for that!

I am also quite happy about those who have expressed interest in getting involved with Dolphin development and have asked for some guidance about how to get started. As I said in my last post, I’m a bit busy at the moment, and from now on I will be away for a couple of weeks and cannot do any Dolphin-related work at all (I might be able to check mails from time to time though), but I would like to provide a few ideas about possible first steps at least.

How to keep in contact with other people working on Dolphin and how to find something to work on

  • Bugs are reported at bugs.kde.org. Here are some example queries: bugs (not wishes) reported in the last two months, all open Dolphin bugs.
  • The mailing list where Dolphin development is discussed is kfm-devel. Feel free to ask there if you have any questions concerning the code. Please do not use this list to report bugs.
  • Patches are submitted for review at Review Board. Use the ‘dolphin’ product, this makes sure that a notification email is sent to the kfm-devel list. You will need a KDE identity account to use Review Board and many more KDE-related services. If you want to work on something larger or if you are unsure if the approach you have in mind to fix a problem is the right one, please ask on the mailing list before you invest a lot of time.
  • We have a forum which can be used for support requests and Dolphin-related questions. If it turns out that something which is discussed at the forum is a bug, please make sure that it is reported at bugs.kde.org.

Building Dolphin from source

This is the first and maybe most important step that anyone willing to help out with development has to take. There is some information about building the entire KDE source at TechBase, including links to tools like kdesrc-build and build-tool which can be used to perform most of the steps automatically.

But it is also possible to build just kde-baseapps, which is the repository where Dolphin is located, provided the kdelibs development package provided by your distribution are installed. Finding the easiest way to do it and publishing it has been on my TODO list fore quite some time, but because I never got round to do it, I’ll just provide ideas how it can be done. Maybe you will find even better ways. If you find a way to build just Dolphin and think it is easy enough for others as well, please post a description as a comment or provide a link to a script, pastebin, etc. We can put the easiest way to build Dolphin on a wiki then.

6 thoughts on “How to get started with Dolphin development

  1. How i do development for any potential bug fix is a bit odd perhaps. Though it’s very fast to setup. I simply pull the package from my distribution (archlinux) which i then recompile first as the first initial step. Once that’s done i simply open QtCreator since it can handle CMake files to open the entire kde-baseapps package in there. I only use QtCreator for editing, code completion and such, i don’t use it for compilation!

    So, i make my edits in QtCreator and then use my distribution to recompile the package, make the package and install it.

    That’s the first step which allows me to fix a specific bug in my distribution package. Once that works i start the more complicated way of fixing the same issue in the kde-baseapps git repository. That is where things get more complicated but it sums up in the following.

    1. i clone kde baseapps
    2. compile everything (can sometimes be problematic. If it is, checkout the version your distribution uses as well which probably makes compiling easier)
    3. setting my LD_LIBRARY_PATH to the compiled libs and sometimes also setting my PATH variable to the new binaries. The PATH one isn’t always needed though for dolphin it’s best if you do it. If you for example end up in fixing something in kdelibs then just LD_LIBRARY_PATH is enough.
    4. running the app (dolphin) on the command line with –nofork So, “dolphin –nofork”. Please do close other dolphin instances before just to prevent you from looking at the wrong window :)

    That’s about how i do things in any KDE app.
    Kinda vague huh? ;)

  2. HI,

    I’ve set up my build enviroment as it is mentioned here: http://techbase.kde.org/Getting_Started/Build/Environment

    After that I just clone the git repository for kde baseapps (or pull if it is already cloned) and open the CMakeLists.txt in KDevelop.
    KDevelop is quite nice for investigating unknown code (which you have when you are new to the software you want to contribute to), and if set up correct you can compile and debug your software right in KDevelop which helps alot, the other option would be to use gdb right at the command line (not so good for new people in KDE and Linux development).

    Ok now I will go and fix my second bug (the first is mentioned in Frank’s post see the 1 of the mentioned patches).
    At the moment I’m working on https://bugs.kde.org/show_bug.cgi?id=255819

    Greetings

    Daniel

    • Thanks for your interest in helping out, and sorry for the late reply, I was away for some time. What aspect of design are you interested in? If you are interested in icons, for example, you could get in touch with the Oxygen team (I think we still have actions without icon in Dolphin). If you prefer working on something else, just let me know – the best way is to send a message to the mailing list.

Comments are closed.