Road to a better KDevelop newcomer experience

Hi fellow KDE!

Today I would like to talk a little about some work I’ve been doing recently in KDevelop in order to assure we have a good path for the new KDevelop user and KDE or free software Developer.

I think that KDevelop has been quite good at being adopted by people who know their way in the development process: in few words, people who already know the language they’re using and usually they can fill any lacking feature KDevelop might have, by doing some old-style terminal hacking :). No problem with that, but apparently not everyone is born with some wizard skills, so I’d like to improve this situation.

There are many aspects that can be improved and some have been lately. One of the most annoying things that we found (mostly in Randa, in the KDevelop team and some random spontaneous meeting) to be more annoying, was our “New Project” wizard, specially when it comes to start new technology based in KDE.

This is what it looked like before starting working on it:

There are some things I don’t like here: The tree view looks clumsy and doesn’t lead the user anywhere, so whenever I have considered to create a new project from this dialog, I’ve felt violated somehow. What I’m going to show here has to be taken as a first step towards where I want future KDE Developers experience to start (if they are starting a new project).

The idea here is that the user will select, first of all, what kind of application is going to be created, roughly: KDE Application, just a standard application, a web service or whatever it’s needed. Using KDE as an example, we’ll select if we want to create a console application, GUI application, Plasmoid, etc. Finally, we’ll select the language we want to use be C++, Python or whatever it’s available.

That last step change is important, because we’re adding more importance at what we are doing (a Plasmoid for example) than if we are going to do it in C++ or Python.

From this point there’s many things to be done:

  • Make it possible to create new applications from the KDE Examples
  • Add some category information, categories are not translatable right now and they can’t have an icon. I’d like to see this improved.
  • KNewStuff support to download new templates?
  • Make sure the KDE GUI application templates are equivalent for C++ or Python.
  • Improve the template’s description. Add links to techbase!
  • Think about the templates you always wanted as a kid and contribute them!
  • … many other things in your imagination 🙂

If someone is interested in helping, just ping me in IRC at #kdevelop in freenode, comment here or send me an e-mail, your call! 🙂

Oh! And last but not least, Big thanks to Àlex Fiestas for helping me sorting the templates and discussing the ideas, and Aurélien Gâteau for giving me a hand at making the GUI more usable.
After all this lonely KDE hacking, it feels great to sit down with someone else and try to take the best out of you on what you’re doing!

17 thoughts on “Road to a better KDevelop newcomer experience”

  1. I love it!

    Some additional suggestions:
    – more verbose names in some cases
    – grouping project types like dolphin can group files
    – column titles to make it clearer that the three columns represent a “drill-down” interface
    – adding the build system to the “programming language” drop-down list (e.g. some templates might exist for both C++/cmake and C++/qmake)

    To make it clearer, here’s a mockup based on your screenshot: http://img8.imageshack.us/img8/1032/kdevelopnewprojectmocku.png

  2. “Make it possible to create new applications from the KDE Examples”

    Does that really belong in this wizard? “Create new project from template” should give the user a minimal file structure with minimal file contents for the respective project type, on top of which he can start building his program.

    Cloning an existing project (even if if it’s just an example application) is something different imo, which is already handled by the “Fetch Project” dialog.

    “Make sure the KDE GUI application templates are equivalent for C++ or Python.”

    Why? Why not just let the description & screenshot change when another programming language is selected?

  3. I would horizontally split the right column. The Preview is not correlated with the programming language. And maybe I would would move the language up and the preview down.

  4. Have you talked to the Calligra developers? If I recall correctly, they had a very similar problem they needed to solve recently, and they did a lot of usability research to find out the best way to solve it. You should find out how they did it and see if it can be adapted to kdevelop as well.

  5. @uniq: I thought the same thing when I first saw the screenshot… After splitting, one could even remove the white background from the preview box, just draw a border around it or something, it would differentiate it even more. However, I don’t think this is such a big issue, and even with the way it is now, users will understand what’s goin on.

  6. #2 yes, i’ve been thinking about the changes on your mockup, we’ll see what we can do about it 🙂

    #3 KDE Examples is a different use case, but it’s good that they are together with these… in the end, we need some smart way to display Examples somewhere

  7. I think the Qt templates shouldn’t be in the KDE group. Either make a new group called KDE or rename it to eg. “Qt/KDE.” It took me a few moments to find where the Qt templates are, because I don’t do any KDE development, but I use Qt. Yes, it’s only a few seconds, but even those few seconds can improve the user experience.

  8. I think that to apriori (=before you write any actual code) decide whether you are going to end up implementing “KDE 4 GUI Application” or “KDE 4 KPart Application” or “Plasma Applet Template”, or whatever else, is an illogical approach. The problematic part of the apriori choice is that it fixes the project to a particular predetermined path. Predetermined is wrong.

    KDE applications are closed, which is bad and irrational. Developers cannot *freely* use an application’s sub-functionality, because the way applications are hard-wired makes such uses impossible. Take KCalc for example: KCalc is *not* something a developer could use in other projects. Obviously, KCalc can do math calculations. What if I want to use KCalc’s ability to do math calculations (without KCalc’s GUI in 1 case, with KCalc’s GUI in a second case) – can I do this easily (in 5 minutes)? No, I cannot. And it *is* completely irrational that I cannot do it easily.

    There is something fundamentally broken in the way KDE is architected.

    The ideal state would be: When a KDE developer is creating a new “application” such as KCalc (somebody had to create KCalc initially), he or she is AT THE SAME TIME (CONCURRENTLY) AND WITHOUT EVEN KNOWING ABOUT IT creating components for other developers to use. This of course assumes that applications are open. It is what I would call effective development process. Compared to this, the current way of KDE doing things is inferior (because having 1 strategy is always inferior to having 2 concurrent strategies (chess)) and cannot efficiently bring about new components for other people to use in their projects.

    What I described here is not a new technology. It has an age of at least 30 years. See Smalltalk and Squeak. For a somewhat newer installment, see the Go language (such as: why Go doesn’t have class hierarchies).

    Thanks.

  9. #10: KDE already splits off functionality into freely available shared libraries or reusable components (kpart’s, data engines, etc.) more than most other software collections in existence.

    If you have constructive ideas for how to further improve this (and make it more transparent to application developers, as you demand) without abandoning C++/Qt, feel free to express those ideas.

  10. For KDE application development this looks great.

    KDevelop is also a great general purpose IDE, and I wonder if the above approach might lead people to assume kdevelop only really targets KDE development; perhaps if you tried to balance the option trees (they still are trees) a bit?

    E.g. use the following categories:
    * KDE plugin (kpart, kate plugin, etc.)
    * KDE application (plasmoid, stand-alone QT/KDE program, etc.)
    * Non-KDE application (templates for QT and GTK-based programs)
    * C++ project
    * Python project
    * Ruby project

    The result is still slightly unclear of course (since (a) several of the application templates will use C++ or python and (b) a project needn’t use a single language), but I think this has the advantages that:
    * developers who know they want to write an application or plugin based on X can start from there
    * and developers who know they want to start with a basic C++ or python template can start from there

  11. IMO having language as the top-level choice would be better. Let me explain why.

    Assume that I decided to write a new KDE application using python. So I fire up the “New Project” wizard. Let’s see, there’s a KDE application. OK, let’s choose this one. Yeah, it will be GUI application, so select “Graphical”. But hey, there’s no Python available! Hmm, now I see there’s “Python” too. So let’s select it instead of KDE. I guess “Simple Python Application would suffice.” Wohoo, finally I have a python project.

    See the problem? The language plugins may not provide templates for all categories. However if any other plugin provide such template it may confuse the user so that they check this category first but they find nothing so they need to check other categories.

    Having language as the top level choice is not perfect, because many projects use more than one language. I understand that. But you can’t (if you can, you’re my hero) write in two languages at once (I mean something like that you write python with your left hand and C++ with your right hand using two keyboards). You’ll probably decide what you will implement first and what language you’ll use for that. So you have a clear choice here. The rest depends on which templates are available.

  12. My point of entry as a newbie is trying to get a fairly large project running. Bullet physics to be precise. Things build and compile quite nicely, but when it comes to debugging, nothing seems intuitive. Debug and Execute buttons don’t launch anything and there are no messages just silence. I presume they can’t find the executables, but i can’t find any dialog to adjust them. The only help i can find is online and the GUI has changed too much for them to be useful. I think, at least, there should be some standard output if you press a button and the action fails.

    I’m able to get to some dialogs, like “add custom library path” by hovering over red-underlined #include statements, but i can’t figure out how to open those dialogs from the menu.

    It’s frustrating not to have any debug windows – step over, step into etc. anywhere in the menus or toolbars But i presume they will magically pop up once i learn how to build a debug target?

    Run -> Configure Launches seems really like Select Project to Launch, since i’m not allowed to configure anything
    Project -> Configure Selection seems more like “Run Configuration” to me

    generally though, it’s a pretty nice system.

  13. I’ve made some progress.
    My problems were 2 fold.

    1. When i clicked Run->Launch, I was confused because i was presented with three projects and clicking on them does nothing. There are + and – buttons, but i presumed they were to add more projects or delete them. It wasn’t until i read the bug report below that it was clear this + icon was needed to expand the folder and get the options. I think having expansion arrow beside the folder would be more consistent with the KDevelop environment.

    https://bugs.kde.org/show_bug.cgi?id=251343

    Once i configured my launch to point at my executable, my problems weren’t over. It has been reported in a bug i cant locate now, that KDevelop may have problems debugn or executing because of root permission issues. At least now i get a pop-up window saying something is wrong:

    GDB cannot use the tty* or pty* devices.
    Check the settings on /dev/tty* and /dev/pty*
    As root you may need to “chmod ug+rw” tty* and pty* devices and/or add the user to the tty group using “usermod -G tty username”

    I followed the instructions, but on my ubuntu 11.10 asus laptop I don’t have any pty* files in /dev.
    I still get the errors even after restarting KDev4

    any clues?

  14. [SOLVED]

    Debug
    GDB cannot use the tty* or pty* devices.
    Check the settings on /dev/tty* and /dev/pty*
    As root you may need to “chmod ug+rw” tty* and pty* devices and/or add the user to the tty group using “usermod -G tty username”

    Execute
    Could not start program ‘konsole –noclose –workdir /home/kesten/VersionControlProjects/Bazaar/Engines/Bullet/cmake-build-2.79/Demos/SerializeDemo -e /home/kesten/projects/SimpleCmakeKdevelopApp/build/simplecmakekdevelopapp’. Make sure that the path is specified correctly.

    On a hunch, i guessed that the path was right but konsole was not installed.

    *******************************************
    *****Suggest that the error message “Make sure that the path is specified correctly.” is appended with “and that konsole is installed – type konsole at terminal” *****
    *******************************************

    Now execute runs hello world with no complaints (window named kesten )
    while debug makes a kesten:sh window and says
    “warning: GDB: Failed to set controlling terminal: Operation not permitted\n”
    Hello, world!

    Good nough.

Leave a Reply

Your email address will not be published. Required fields are marked *