Se siete dei fan di KDevelop, allora dovete sapere che i sorgenti non sono più in trunk/KDE, ma in trunk/extragear/sdk: stessa cosa vale per KDevPlatform e Quanta. Con questa mossa, gli sviluppatori non avranno più l’acqua alla gola riguardo scadenze ufficiali e quant’altro.

Questi annunciano inoltre che, il possibile rilascio di KDevelop 4.0, avverrà probabilmente verso la fine di marzo 2010.

Un altro spostamento di minore importanza riguarda il mitico plugin katepart denominato autobrace, che è stato incluso addirittura in kdelibs

Ammetto che questo post interesserà al massimo a 5-6 persone su 6G totali… :D

As we decided that we won’t make the KDE 4.4 schedule and drop out of it, we thought that we should also play by the KDE policy rules and move out of trunk/KDE.

That move has just happened and KDevelop, KDevPlatform and Quanta can now be found under trunk/extragear/sdk/.

Everybody who’s running svn now needs to adjust his url using

svn switch svn://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

And similar for kdevplatform or quanta.

The tentative release date for KDevelop4 has been moved to end of march now.

First note: This is a bit of a rant, so be prepared

It seems that Ubuntu has reached another sad milestone on their way to the worst distribution ever.

Someone there thought its a cool idea to ship KDevelop4 Beta5 with a stable Ubuntu release.

What angers me most about this is that this not only hurts Ubuntu – I couldn’t care less about that – it hurts KDevelop and it also hurts me and other people trying to get KDevelop’s bugs under control. I’ve closed the 20th or so duplicate right now about a bug thats been in beta5 and has been fixed since weeks. Its a bug that’ll not be in the final release of KDevelop4, but its a bug I’ll probably get to see again and again in bugzilla for quite some time.

I never liked Ubuntu, but this really is a new level of broken packaging.

As final word something constructive: If you are running Ubuntu 9.10 either consider compiling kdevelop and kdevplatform from sources or report bugs you encounter with the Ubuntu kdevelop package to Ubuntu, not to KDE’s bugzilla even if thats what the Crash dialog suggests to you.

제목을 “사랑스러운 KDevelop4″ 로 하려다가 너무 감성적이기도 하고
내용이 별로 없는데 많은 기대를 주는 낚시성이 있는 것으로 보여 바꿨다.
그만큼 맘에 들 것 이라는 의미로 받아 줬으면 좋겠다.

• 코드 색상이 맘에 든다. 흡사 맥의 MacVim, Aquamacs 를 보는 듯한…
• CMake 프로젝트를 지원한다. (“Project” – “Open / Import Project”), 겔러리 2, 3번째, 기존의 CMakeLists.txt 불러오는 화면
• 한글 조합 입력 중 글자가 사라지는 문제가 해결 되었다.
• KDevelop3에서 유용하게 자주 사용했던 전체 프로젝트에서 검색(grep)이 잘 된다. 겔러리 4번째
• UI가 KDE4에서 개선 되어서 인지 KDevelop3에서 지저분 했던 느낌이 없다.

아직 많은 것을 해보진 못 했다.
하지만, 내가 기대했던 중요한 부분은 맘에 들게 개발되어져 있는 것 같다.

- 끝 -

Actually this probably applies to any FOSS app out there.

This morning I saw in my irc backlog (lucky you that I keep that and usually at least skim it):

[07:41:33] –> firefly2442_ () has joined #kdevelop
[07:42:29] <firefly2442_> I found a bug in kdevelop 3.5.3, in the project options under run options
[07:42:50] <firefly2442_> I can navigate and specify my main program executable
[07:43:08] <firefly2442_> however, when I try to run it, it doesn’t work because the folders have spaces in them
[07:43:46] <firefly2442_> the actual command that gets executed and run in the bottom window should be modified to add quotes to allow for folders with spaces
[07:43:53] <firefly2442_> should be a simple fix
[07:44:04] <firefly2442_> cheers
[07:44:16] <– firefly2442_ () has quit (Client Quit)

This is a good example of how you should _never_ try to report bugs or problems with KDevelop. Unless of course you just wanted to do a braindump which nobody cares. Its fine to approach us on IRC, but please don’t just dump things and then leave immediately.

The right way of doing this is by either using our bugreporting wizard at KDE Bugzilla or by at least sending a mail to one of our mailing lists so we can reply to you.

I know this is a bit more effort than joining into an irc channel and dropping a few lines, but really there are far better chances of your problem being solved doing the few extra steps.

Sadly this means the above irc-report will not go anywhere, I don’t even have kdevelop3 around anymore, so I cannot test this and file the bug myself. Not to mention that 3.5.3 is rather old (3.5.5 is current) and KDevelop3 is not actively maintained anymore.

Unfortunately I suck, hence the originally uploaded kdevelop4 beta5 tarball didn’t include the version increasement (thats the only missing change, so the help->about KDevelop will show the wrong version). I’ve fixed that now and re-uploaded a new tarball for kdevelop, this should show up on the mirrors in a couple of hours.

To make sure that everybody has the right packages, these are the md5sum for the proper packages:

70064ad0e285d29242a90af3f3c2283f kdevelop-3.9.95.tar.bz2
2ee0d124682bb3cbc3f1068389749e0c kdevplatform-0.9.95.tar.bz2


So if the md5sum of your kdevelop-tarball doesn’t match, re-download it in a few hours.

Update!!!!
It seems like screwing up once wasn’t enough this time, the kdevplatform package also had a wrong version. I’ve uploaded a new one, but syncing will again take some time. Here are the latest md5sums:

70064ad0e285d29242a90af3f3c2283f kdevelop-3.9.95.tar.bz2
e38fd54ea9c16b41222e893c06ca3946 kdevplatform-0.9.95.tar.bz2


I’ve just released the fith beta of KDevelop4 into the wild, so go get it

We’ve fixed quite some crashes and also implemented a few new features, among them improvements in the refactorings and a new patchreview toolview (see Views->Add Toolview). That allows you to easily review patches inline in the Kate editor. This way we combine diff-viewing with the powerful semantic highlighting from the C++ support.

I’d also like to point out that this is the last beta that will be working with KDE 4.2.x, the next one (still at least 4 weeks away) will need KDE 4.3.0 or 4.3.1 (we’re not yet 100% sure about the patch-level). The reason is quite simply that for 4.2.x compatibility we need quite some extra code/ugly ifdef’s and you’re missing out on some features which are only possible with 4.3.x.

Update: You can find the source packages on the KDE mirrors.

I’ve just finished a rework of the GUI to configure launches. This is mostly based on feedback I gathered via bugreports, irc chats and mailinglists. Apparently a combobox to just add/remove tabs to an existing tabwidget isn’t working well and suggests to users a completely different thing to configure. Also people expected the selected combobox value (i.e. the launch mode) to be saved across invocations of the dialog.

So this was just confusing people that didn’t write the gui themselves and lead to me explaining how things work over and over again. With recent svn (and this will be in the next beta too) you’ll now get a bit different view:

As you can see for each launch mode supported by a launch configuration there’s a separate subitem under it to configure the specific things for that launch mode. This of course depends on the actual launcher used for the mode (i.e. which debugger is used for the Debug mode). The generic pages for a launch configuration are available from the launch-config item itself. In the example shot above you can see this includes the actual application to execute, configuration of the dependencies and so on. These settings are used by all the launch modes.

Feedback would be appreciated, preferably via our mailinglist or bugs.kde.org, but if you’re too lazy just add a comment

Hey!

Maybe you’ve been struggling in the past to get scripting into your application? Hard task isn’t it?

NO.. you get pretty good scripting capabilities using the qtscriptgenerator

They expose nearly 100% of the Qt api.. I hear you crying: “BUT THAT’S A SECURITY THREAT!” .. and I fully agree.. so it’s still up to you, to decide what you wanna do… maybe only allowing to use part of the qt modules, maybe just exporting some classes/functions.. it’s up to you to decide, which scripting capabilities you want to offer your developers and how you want to prevent scriptkiddies from taking over your machine

This whole stuff is still really new to me so forgive me if I told ya complete bull**** ^^

I’m also looking forward to the kdevelop bindingsgenerator getting ripped out and ported to be useful for normal bindings.. reason for this is that as far as I’ve heard recently the qtscriptgenerator is pretty out of date technologywise and the kdevelop bindingsgenerator is much better from the technical pov..

Hope we’ll be looking into a bright scripting future.. the possibilities are just too cute to resist

*me goes back to ripping apart amaroks scripting/khotnewstuff capabilities *
*me likes the approach they’ve taken *

Cya

Questa guida non ha la pretesa di insegnare a programmare in C++ (per questo ci sono tonnellate di manuali ed esempi disponibili) ma di introdurre rapidamente l’utente, che si avvicina per la prima volta alla programmazione nel mondo GNU/Linux, alla programmazione delle interfacce grafiche con le fantastiche librerie Qt4.
Un consiglio, abusate pure come volete della guida in linea delle Qt4 che è fatta veramente bene e diventa indispensabile se si decide di sviluppare applicazioni più complesse.

Allacciate le cinture… si comincia!

Creazione del progetto Qt 4

• Avviare KDevelop
• Selezionare dal menù Progetto la voce Nuovo progetto
• Selezionare dal ramo C++ la voce QMake project quindi, da quest’ultimo, scegliere Applicazione Qt4

• Nel campo Nome applicazione specificare un nome per il progetto (ad es. CiaoMondo_Qt4)
• Nel campo Posizione specificare il percorso all’interno del quale salvare il progetto (io ho creato la cartella Progetti all’interno della mia home directory), quindi cliccare su Avanti.
• Specificare il nome dell’autore del progetto, il vostro indirizzo e-mail, la versione del programma ed il tipo di licenza con cui intendete rilasciare il programma. Per adesso potete semplicemente accettare i valori proposti ed andare avanti ma, se intendete distribuire il vostro programma sarà bene inserire le informazioni con cura, queste infatti vi permetteranno di rivendicare sempre la paternità sul vostro magnifico software. Cliccare su Avanti.

• Selezionare il sistema di controllo della versione. Anche qui per ora possiamo sorvolare e cliccare con decisione sul pulsante Avanti ma, se un giorno decideste di scrivere un’applicazione più complessa, un sistema per il controllo della versione potrebbe aiutarvi molto. Cliccare su Avanti con noncuranza .

• In questa schermata è possibile modificare il template contenete le informazioni sull’autore del software e sul tipo di licenza con cui quest’ultimo viene distribuito (il software, non l’autore ). Da notare che quanto scritto in questa pagina verrà inserito all’inizio di ogni file header (.h) del vostro progetto. Cliccare su Avanti.

• In questa schermata è possibile modificare il template contenete le informazioni sull’autore del software e sul tipo di licenza con cui quest’ultimo viene distribuito. Da notare che quanto scritto in questa pagina verrà inserito all’inizio di ogni file sorgente (.cpp) del vostro progetto. Cliccare su Fine.

A questo punto KDevelop ha già creato un’applicazione Qt4 funzionante:

• Siccome lo so che siete curiosi come delle scimmie e non vedete l’ora di far girare il vostro programma, selezionare dal menù Compila la voce Compila progetto (oppure premere F8) e rispondere affermativamente alla richiesta di eseguire qmake. In questo modo verranno creati tutti i file intermedi (come Makefile, file moc e uic) necessari per compilare il software.

• Nella finestra Messaggi è possibile leggere quello che accade in fase di compilazione. Se tutto va come deve andare, alla fine apparirà la scritta:

*** successo ***

Se dovessero esserci problemi (errori di sintassi, librerie mancanti, ecc.) questa finestra sarà una delle nostre migliori alleate.

• Ci siamo, dal menù Compila selezionare la voce Esegui programma principale (oppure premere Shift+F9)

Creazione dell’interfaccia grafica

Prima di procedere è necessario capire come si usano le interfacce grafiche in Qt4:

Si crea il file di interfaccia grafica con il Qt Designer (come abbiamo appena fatto). Quindi si compila il file .ui ottenuto in modo che venga tradotto in un file sorgente (.h). Quest’ultimo conterrà una classe i cui metodi si occuperanno di creare tutti i controlli (pulsanti, label, ecc.) e di impostarne le proprietà. Si crea infine una nuova classe che, attraverso l’ereditarietà multipla erediterà da quella risultante dalla compilazione del file .ui (in modo che contenga tutti i controlli definiti) e, ad esempio, da QDialog (in modo che si comporti come una finestra di dialogo e ne abbia le stesse proprietà e funzioni).

Confusi? Proviamo a farlo

• Dal menù File selezionare la voce Nuovo.
• Specificare il nome per il file di interfaccia grafica (ad es. MioDialogoBase).
• Selezionare Qt4 Dialog (.ui) come tipo di file.
• Selezionare la casella Aggiungi al progetto, quindi cliccare su OK.

• Il file appena creato verrà aperto in automatico con l’editor di interfaccia Qt Designer, trascinare due controlli di tipo Push Button ed un controllo di tipo Label sulla finestra di dialogo che stiamo creando. Spostare e ridimensionare i controlli e la finestra di dialogo per ottenere un risultato simile a quello dell’immagine seguente:

• E’ buona norma dare dei nomi significati ai controlli, quindi modificare il valore della proprietà objectName nel Property Editor per ciascuno di essi in questo modo:

Oggetto         objectName
---------------------------------
Dialog          DlgMioDialogoBase
Label           lblCiaoMondo
pushButton      btnCiaoMondo
pushButton_2    btnChiudi

Da notare che il nome dell’oggetto Dialog (ad es. DlgMioDialogoBase) sarà anche il nome di una delle classi base per la classe dell’interfaccia grafica.

• Impostare anche le seguenti proprietà dei controlli:

Oggetto             Proprietà                 Valore
------------------------------------------------------------------------
DlgMioDialogoBase   windowTitle               Programma di prova
lblCiaoMondo        alignment.Horizontal      AlignHCenter
lblCiaoMondo        alignment.Vertical        AlignVCenter
lblCiaoMondo        font.Family               Sans Serif
lblCiaoMondo        font.PointSize            36
lblCiaoMondo        text                      Non impostare nessun testo
btnCiaoMondo        text                      Saluta
btnChiudi           text                      Chiudi

• Selezionare dal menù File la voce Save per salvare il layout dell’interfaccia grafica e chiudere il Qt Designer
• Selezionare dal menù Compila la voce Compila progetto (oppure premere F8) per ricompilare il programma e far si che vengano generati i file sorgente relativi all’interfaccia grafica. Come prima è possibile vedere nella finestra Messaggi il risultato della compilazione ed il nome dei file generati (ad es. ui_MioDialogo.h).

A questo punto è stato ottenuto il file che fungerà da classe base per la classe dell’interfaccia vera e propria. Adesso è necessario creare quet’ultima:

• Dal menù Progetto selezionare la voce Nuova classe.
• Nel campo Nome specificare il nome per la classe (ad es. MioDialogo)
• Nel riquadro Ereditarietà cliccare sul pulsante Aggiungi e specificare come classe base QDialog e specificando come file di itestazione QDialog (si senza il .h finale!)
• Ripetere l’operazione e specificare come classe base il nome della finestra di dialogo definita nel Qt Designer (ad es. DlgMioDialogoBase) in quanto questo è anche il nome della classe base risultato della compilazione del file .ui ed il file sorgente dove tale classe è contenuta (ad es. ui_MioDialogoBase.h)
• Per ora non preoccupiamoci di tutti gli altri settaggi che è possibile fare, limitiamoci a notare i nomi dei file di intestazione (ad es. miodialogo.h) e di implementazione (ad es. miodialogo.cpp) che verranno creati per la nuova classe. Cliccare su OK per creare la nuova classe.

• Cliccare sul pulsante Classi per vedere l’albero delle classi contenute nel progetto.
• Cliccare sul nome della classe (ad es. MioDialogo) per aprire il file di intestazione (.h)
• Espandere il ramo della classe e cliccare sul nome di un metodo (ad es. sul costruttore MioDialogo) per aprire il file di implementazione (.cpp)

Com’è possibile notare la classe eredita da QDialog e DlgMioDialogoBase e, pertanto, sono state aggiunte le direttive include necessarie. Notare anche che all’inizio di ogni file è stata aggiunta la nota di copyright in base al template ed alle informazioni inserite in fase di creazione del progetto.

• Fare clic con il pulsante destro sul nome della classe (ad es. MioDialogo) e selezionare la voce Aggiungi metodo.
• Nel campo Tipo da restituire specificare void.
• Nel campo Dichiaratore specificare il nome della fuzione (ad es. btnCiaoMondo_clicked())
• Nel campo Accesso selezionare Public Slots
• Nel campo Memoria selezionare Virtual, fare clic su OK
• Nel campo File implementazione verificare che il nome del file sia corretto (ad es. /home/crash/Progetti/CiaoMondo_Qt4/src/miodialogo.cpp) a me mancava il punto prima di cpp: dev’essere un bug di KDevelop

• Ripetere gli ultimi cinque passi specificando btnChiudi_clicked() come nome della funzione.

Alla fine controllando il file di intestazione (.h) si avrà:

class MioDialogo : public QDialog, public DlgMioDialogoBase
{
   public:
      MioDialogo();
      ~MioDialogo();
   public slots:
      virtual void btnCiaoMondo_clicked();
      virtual void btnChiudi_clicked();
};

• Aggiungere la macro Q_OBJECT e la definizione del namespace all’inizio della definizione della classe:

using namespace Ui;

class MioDialogo : public QDialog, public DlgMioDialogoBase
{
   Q_OBJECT
   public:
      MioDialogo();
      ~MioDialogo();
   public slots:
      virtual void btnCiaoMondo_clicked();
      virtual void btnChiudi_clicked();
};

senza di essa infatti gli slot non verrebbero riconosciuti in fase di esecuzione e non accadrebbe nulla quando si premono i pulsanti.

• Aprire il file di implementazione della classe creata (ad es. miodialogo.cpp) e modificarne il costruttore aggiungendo le seguenti istruzioni:

setupUi( this );
connect(btnCiaoMondo, SIGNAL( clicked() ), this, SLOT( btnCiaoMondo_clicked() ) );
connect(btnChiudi, SIGNAL( clicked() ), this, SLOT( btnChiudi_clicked() ) );

la prima istruzione è contenuta nella classe base DlgMioDialogoBase e serve per far si che vengano creati tutti i controlli, mentre le altre permettono di richiamare rispettivamente la funzione btnCiaoMondo_clicked quando viene premuto il pulsante btnCiaoMondo e la fuzione btnChiudi_clicked quando viene premuto il pulsante btnChiudi.

• Modificare il corpo delle due funzioni in questione:

/*!
   \fn MioDialogo::btnCiaoMondo_clicked()
*/
void MioDialogo::btnCiaoMondo_clicked()
{
   lblCiaoMondo->setText("Ciao mondo!");
}

/*!
   \fn MioDialogo::btnChiudi_clicked()
*/
void MioDialogo::btnChiudi_clicked()
{
   accept();
}

la funzione btnCiaoMondo_clicked, così modificata, imposta il testo della Label lblCiaoMondo uguale a “Ciao mondo!”, mentre la funzione btnChiudi_clicked causa la chiusura della finestra e la fine del programma.

Non resta che modificare il file main.cpp.

• Aprire il file main.cpp cliccando su main nell’albero delle classi
• Commentare o eliminare le righe:

#include "ciaomondo_qt4.h"
...
CiaoMondo_Qt4 * mw = new CiaoMondo_Qt4();
mw->show();

che servono per visualizzare la finestra di default creata dal wizard.

• Aggiungere la direttiva include per la classe dell’interfaccia che abbiamo creato, la dichiarazione dell’oggetto finestra di dialogo e la sua esecuzione:

#include "miodialogo.h"
...
MioDialogo dlg;
dlg.exec();

• Selezionare dal menù File la voce Salva
• Selezionare dal menù Compila la voce Progetto dist-clean
• Selezionare dal menù Compila la voce Compila progetto (oppure premere F8)
• Dal menù Compila, selezionare la voce Esegui programma principale (oppure premere Shift+F9), cliccare sul pulsante Saluta e su Chiudi per ammirare la propria creatura funzionare!

Se qualcosa dovesse andare storto, controllare bene la sintassi dei comandi, accertarsi che non manchino parentesi, punti e virgola, controllare di aver incluso tutti i file necessari, verificare di aver rispettato maiuscole e minuscole, ecc. ecc.

Il file del progetto completo si trova nel Forziere di Morg4n

Buona programmazione a tutti!!!

We’ve just released the 4th Beta of KDevelop4 and its coming along quite nicely.

This one even compiles on Windows (using MSVC9 aka MS VS 2008) and also is able to load projects. I haven’t been able to try out more things, like file-parsing or code-completion. One thing that won’t work for example for sure is building any cmake project as we don’t yet have any support for nmake.

So the Windows port is not ready for public consumption (as opposed to Beta4 on linux) but it does make progress again.

These are short and (hopefully) precise instructions what you need to do when you’ve built KDevelop4 from source and installed it somewhere other than your KDE libraries are (those are often from packages and then installed in /usr or /opt/kde).

I’m assuming here that you have the KDE libraries installed in /usr (i.e. from some packages) and that you’ve installed KDevelop4 into $HOME/kdevelop4 (by passing -DCMAKE_INSTALL_PREFIX=$HOME/kdevelop4 to cmake). If your paths are different just substitute them. Also I’m assuming you’re running KDevelop4 from a terminal and not via the run dialog or via a menu entry, if you want that to work you need to find out how to set environment for the whole X11 session – thats usually distro-specific.

So, first thing to do is setup the KDEDIRS magic environment variable. It tells KDE core components where to search for plugins and other data related to KDE apps and contains just a list of paths (aka prefixes) where KDE libraries and/or applications have been installed.

In my example I set KDEDIRS to point to /usr and $HOME/kdevelop4 as those are the two places where I have KDE4 apps:

export KDEDIRS=$HOME/kdevelop4:/usr


Next thing is to run a KDE tool called “kbuildsycoca4″, this reads various config files that describe which plugins are available and builds a cache from that information. This is necessary so KDevelop can find all its plugins.

And last but not least you can simply run KDevelop by typing “kdevelop” and hitting Enter.

- traduction de “Beta3 and Beta4” -

Ceux qui lisent le dot le savent déjà, mais pour les autres (c’est à dire vous) : la troisième beta de KDevelop4 est disponible. Nous avons fixé des tonnes de bugs, ajouté une nouvelle plateforme de lancement, des fonctionnalités C++ ainsi qu’une toute nouvelle manière de passer de la perspective de codage à celle de déboguage et vice-versa (seulement pour KDE 4.3).

Cependant depuis le tagging le dernier week-end, David est devenu d’une certaine façon fou en corrigeant toute sorte de crash et blocages (selon moi) mystérieux, ainsi que quelques améliorations de rapidité.  Par ailleurs Thomax McGuire – un fan de KDevelop et PIMster – c’est assis, fouillé dans notre IHM complexe pour corriger l’un des bugs les plus gênants jamais rencontrés dans ce nouveau code : https://bugs.kde.org/show_bug.cgi?id=170863 (celui qui maximisait la fenêtre principale à l’ouverture de la barre de recherche de Kate).

Donc nous sortirons prochainement une nouvelle beta (esperons-le avec d’autres corrections/améliorations pour Valgrind, le débogueur, la plate-forme de lancement et une nouvelle barre de progression). Je n’ai aucune date pour l’instant puisque cela dépend d’un certain truc administratif qu’il faut régler en premier, mais vous serez prévenus quand ça arrivera

General Progress
A lot is happening in KDevelop4 these days. Now it’s nearly already 2 Months ago that we had our developer meeting in Ukraine. We had a lot of fun, although for me the trip started two days late. I didn’t get my passport in time, damn. But once there, I got quite productive. Since I have limited time these days, that hack sprint motivated me to touch the one big outstanding architectural issue yet existent in the duchain. I knew it was a painful mammooth task, that’s why I kept my fingers off it for a long time.

I have implemented a special reference-counting mechanism for the duchain that uses the standard convenient C++ way of achieving the thing: In the constructor of an object, increase a counter, and in the destructor of an object, decrease it again. Now finally _everything_ in the duchain is reference-counted, even extreme light-weight objects like “IndexedString”, which is nothing more than a wrapper around an integer representing a string.

That object is used everywhere, and since the reference-counts are disk-persistent, increasing them is not as cheap as usually. So here’s the clue: It is only done when the memory-area the constructed/destructed object is in is actually marked as a “disk persistent” area, that will be stored to disk later, or is already on-disk. That means that it has near-zero runtime overhead for most of the object usages. During shutdown the objects are all sweeped, and the ones without a persistent reference-count are cleared away. The most complicated task was getting all the already existing duchain storage schemes work nicely together with such reference-counted containted objects.

I got it ready about 1 week after I was home again. Two weeks later it actually was stable. Anyway, it was worth it.

Apart from this architectural thing, the focus is mainly on polishing now. Tons and tons of bugs and crashes were fixed.

Apart from bug-fixing, I’m trying to use my limited time to move KDevelop4 forward in some of the other areas that need it most. After all, a good C++ support alone is not enough of a selling point for an IDE, and I have some ideas about how KDevelop 4.0 should look. Also, I sometimes feel the intense need to do something “creative”.

Areas
Now KDevelop4 has a feature called “Areas”. From what I know it’s comparable to the Eclipse “Perspectives” feature with some slight differences.

Each area contains a distinct set of tool-views, and toolbars, tailored for a specific task (Currently we have “Test”, “Debug”, and “Code”). In difference to Eclipe Perspectives, areas may also contain different sets of files. We actually thought about renaming them to “Perspective” for consistency, but then again “Perspective” implies looking at the same thing just from a different direction, while an “Area” is actually a different working-space, like a different table, where you use different tools to work on different items. So we’ll probably stick with this terminology for now.

Before the hack sprint, there was a little dropdown list in the toolbar to switch areas. But in our opinion this was not very usable, given that we want areas to be a central part of our UI concept. You could never see what other areas there was, and you always needed one click too much to switch them. So we discussed different mechanisms for area-switching. My initial idea was quite simple: Use tabs. It’s the concept that fits best. Just some additional non-removable tabs somewhere at the top, and areas would be totally intuitive and logical to use. The others were a bit more in favor of using separate toolbuttons, and after I wasted a few hours trying to hack something together with tabs, I gave it up. Alexander Dymo then created area-switcher toolbuttons, probably similar to the way Eclipse does perspective switching.

However a few weeks after being home again, I started feeling that these toolbuttons don’t work. How is it intuitive that you click a toolbutton, and suddenly you have completely different files open? And how could we automatically switch the area when we start debugging, without making the user crazy? Also, toolbars are generally “optional”. And if we want to make Areas a central concept, we cannot make the area-switching optional. We shouldn’t give the user a chance to break his UI.

So I started again doing mockups about how the UI could look, here’s the evolution:
http://zwabel.wordpress.com/files/2009/05/mockup.png
http://zwabel.wordpress.com/files/2009/05/mockup.png
http://zwabel.wordpress.com/files/2009/05/mockup3.png
Niko:
http://www.vivid-planet.com/upload/vertical-tabs2.png
Me again:
http://zwabel.wordpress.com/files/2009/05/vertical-tabs3.png
And the final version:

Just by the way you may be wondering why there suddenly is so few wasted space: On the hack sprint, Alexander Dymo removed both status-bars, moved the editor-information(line+column) into the file-tab line, and moved status indication in the bottom toolbar into the bottom dock switcher, so both status bars are gone.

If you’re wondering about the additional highlighting of the current area tab: We were a bit worried that tabs in the top-right would be somewhat out of user focus, the user might not notice when the area automatically changes, and that it might also be a bit confusing having multiple levels of tabs in the same user-interface. The highlighting moves the thing more into the user focus so changes are directly recognized, increases general awareness, and makes it generally look like a different widget then the document tabs, which reduces confusion.

Now after all the mocking, which I actually just did to start some discussion and gather some ideas+opinions, I suddenly found the hidden QMenuBar::setCornerWidget function, which actually allows implementing the last mockup in a relatively clean way. I sat down for an evening, and ended up with exactly what you see on the last mockup. It needed some additional hacking to get the added highlighting, to have the icons on the left side while having a general right-to-left layout, and to make the tab separator line fade out to the left, but it works, and it is solid. And at least my personal experience shows, that this is very usable and very intuitive, while not wasting a single pixel.

So far so good.

Working Sets
A few years ago, shortly after I joined the KDevelop project, there was a lengthy discussion about tabs in general, and whether/how they could be made useful. The problem: From a specific count of documents upwards, tabs are completely useless to get an overview. And due to the easy navigation in KDevelop, it easily happened (and still happens) that suddenly 20 documents were open, making tabs completely useless. At the beginning of KDevelop4, some developers were tired of the uselessness of tabs, and completely removed them in favor of a dropdown list. However me and some others couldn’t live with that. The problem: You replace something that sometimes becomes useless with something that is always useless. There has always also been a document list toolview, that shows all currently open documents. Those who don’t want tabs probably use that. However, as I know from using kate, even a document-list becomes nearly useless from a specific count of documents on.

So at that time, I had the idea that instead of trying to create an utopic widget that allows easily managing an infinite amount of open documents, just allowing the user better ways of managing the set of documents he is currently working on, so he can easily keep the count of open documents in a tab-manageable area. My idea of achieving this at that point was using working sets. A working set is a specific set of files, the files you really work on. For me, when the open document-count grows into an unmanageable area, that usually comes from either working on multiple problems at the same time, or from a lot of browsing through different documents. The core development activity is usually only focused on a relatively small set of documents. A working set allows grouping small lists of documents together, archiving and restoring them, easily merging, splitting, duplicating, and easy moving of files from one working-set into the other. Such a mechanism would allow keeping the count of files manageable: As soon as you start working on another task, just close the whole current working set, and start your new task with a clean list of documents. As soon as you want back one of the old files or the old working-set, just restore it. Paired with a good user-interface, this might well create a new and more efficient paradigm of working.

My idea was that each working-set would be represented by a unique icon somewhere in a permanently visible part of the UI, so you can easily access them.

However since I was very busy with C++ support, I never came back to this idea. But now suddenly, that I was doing that area-switching stuff, it came back into my mind:
- Areas have different sets of documents, so if they should be really easily usable, it should also be easy to transfer files from one area into the other.
- Due to the area-tabbar I have added, there suddenly is a perfect place where those working-sets could live: At the left side of it.
- KDevelop4 also supports multiple main-windows. How to synchronize or move documents between them? Working-sets would make it a breeze.

Combined with the advantages above, this just created too much temptation for me not to try it. So within the last weeks I piece by piece created full working-set support in KDevelop4.

The hardest part was adapting the background management part of KDevelop4’s UI framework, and until a few days ago it suffered from frequent crashes. But now it seems to finally be stable, so I can announce it for you to try out.

How the UI looks now:

At the left side of the area-switcher, you see the icons for all existing working-sets. Currently that is only two. The icons are taken from several other KDE Applications. In long term, we need a unique set of icons that are totally association-free in the software world for usage in the working-sets. But for now, the most important thing is that each set has a different icon. The area-switcher itself shows the currently active working-set within the switcher, so you see which working set is active in which area. Also there’s an additional working set icon left to the document tabs, to make clear that they belong to each other, and make it yet a bit clearer and easier to use.

When you click onto one of those icons, the clicked working set is loaded into the current area, or it is closed if it is the current set, allowing you to create a new one by opening a new document.

When you hover a working set icon, you get a very useful tooltip, showing you the contained documents, allowing you to load or unload single documents with one click, and to delete or close the entire working set.

This is how it looks when you’re in the debug area, with a different working set open than in the code area. Working-sets are fully synchronized, so if you activate the same working-set within both areas, the areas transform into Eclipse perspectives, as they both always contain the same documents.

KDevelop4 Beta4
On Monday KDevelop4 will go into a mini-freeze with only bugfixes allowed, before releasing the next beta middle of the week. We want to make sure to release a high-quality and stable beta. We have released beta3 just a week ago, but that was a bit premature, as it doesn’t contain some features that we want feedback about, and there were quite a few important last-minute bug-fixes that we would have liked to add, but the release process was already a bit too far at that point.

Anybody who reads the dot will already know, but for those who don’t (yes I mean you): KDevelop4 has released its third beta. We’ve fixed tons of bugs, added a new launch framework, new C++ features and added a whole new way of switching the perspective from code to debug and back (KDE4.3 only).

However since the tagging on the weekend a week ago, David somehow has gone crazy on fixing all kinds of mysterious (well to me at least) crashes and locks, as well as some speed improvements. Additionally Thomas McGuire – a KDevelop fan and PIMster – sat down, digged in our complex ui-library and fixed one of the most annoying bugs ever found in this still new codebase: https://bugs.kde.org/show_bug.cgi?id=170863 (the one that resizes the mainwindow even in maximized mode when opening the find-bar from kate).

Hence we’ll shortly be releasing another beta (hopefully with some more fixes/improvements for valgrind, the debugger, launch framework and a new progresswidget). I don’t have any date yet as it depends on some administration stuff to be setup first, but you’ll notice when it happens

Apparently some people tap into this pitfall, so I’ll kinda “announce” this here. KDevelop4 from trunk requires kdebase/workspace since this week. The reason is a much improved process-selection-widget for our gdb-plugin. This allows far better attach-to-process experience than the old widget. The new widget comes from a library thats so far used by ksysguard and is installed as part of the KDE workspace. For KDE 4.4 the library will move to kdelibs and then this requirement will be lifted again, but until then the best option we have is depending on kdebase/workspace.

Also I’d like to note that right now OpenSuSE and Gentoo packages for kdebase/workspace have a bug, which prevents automatic finding of the relevant cmake modules when building KDevelop. Amilcar posted a workaround to the kdevelop mailinglists, but I’m pretty sure the distro’s will catch up soon with fixed packages.

Finally, after about 3 weeks of work I’ve been able to merge back the new launch framework for KDevelop4.

The rework was needed because the existing gui and framework didn’t allow for enough flexibility for more complex cases like remote-gdb debugging, or debugging webpages. Also it forced the user to store its configurations inside a project.

I’m too tired right now to create screenshots, but there’s also not that much to see besides a new treeview in the relevant dialog that lists the configs.

If you want to try it out, just svn up. Please note that there are a few minor gui bugs that I need to fix in the next 2 days as well as dependencies not working at all. Everything else should work (oh yeah, valgrind plugin is currently not working either). If you find bugs I’d kindly ask you to report them on IRC or better the kdevelop-devel mailinglist and not yet on bugzilla so we’re not flooded with new bugs and need to do another 2 days triaging session just to find out what obvious ones we fixed already. Give me a week or two to hammer out the obvious bugs and then feel free to send all your wishes and bugs via bugzilla.