Comment programmer sur KDE ? - Page 1

Quelqu'un connaît un guide simple et en français pour débuter la programmation sous KDE, avec KDevelop ?

- Comment créer des interfaces avec l'Interface Designer ?
- Comment les exploiter ensuite dans un programme. Apparemment il faut écrire le code de l'appli à part, alors comment on mixe l'interface + le code ?
- J'ai entendu dire qu'il y avait deux manières de recevoir les évènements (les clics, les glissers-déposer, etc). Laquelle est la meilleure ?
- Quelles sont les fonctions de KDE qu'il vaut mieux utiliser à la place des fonctions standard ? Par exemple, j'imagine que open, write et close, d'assez bas niveau, sont déconseillées et qu'il vaut mieux passer par des fonctions de l'API de KDE.

etc...

Je suis en train de jouer avec Qt Designer. Mais Qt, c'est un niveau en-dessous de KDE, non ? Je voudrais le plus haut niveau possible, pour être sûr que l'intégration (notamment l'apparence) soit parfaite. Donc KDevelop est préférable ?

Mais bon, les deux se ressemblent... C'est exactement la même chose c'est ça ? Oh les feinteurs

Bon, avant de commencer, un aperçu global de la situation : http://www.ai.univ-paris8.fr/~fb/Cours/Exposes0405-1/qt_kdev.pdf

Ensuite, plein de tutos qui rentrent dans les détails : http://www.kdevelop.org/index.html?filename=tutorials.html&set_lang=fr


Mais bon, la plupart des guides qu'on trouve datent de 2001-2003... D'où cette nouvelle question : Cela vaut-il le coup de développer avec KDevelop 3.5 alors que KDE 4 va bientôt remplacer KDE 3.5 ? Il faut réécrire quel genre de choses pour porter une appli KDE3 sur KDE 4 ?

Ce n'est pas une bonne idée de commencer une application KDE 3 maintenant, tout le nouveau développement devrait être pour KDE 4. Programmer avec KDE 3 maintenant te fera du code à porter et t'apprendra certaines habitudes déjà dépassées. Et tu peux très bien développer et utiliser une application KDE 4 même si tu es toujours sous KDE 3.

KDevelop 3 a un support limité pour le développement KDE 4, mais si tu veux vraiment un environnement de développement optimisé pour KDE 4, il faudra attendre KDevelop 4 (qui est actuellement en alpha et qui sortira probablement avec KDE 4.2).

Et sinon, il y a évidemment aussi la possibilité de te débrouiller avec cmake et make en ligne de commande, un terminal (comme Konsole) et un simple éditeur de textes (par exemple Kate, qui propose aussi une KonsolePart embarquée).

déja quelques petits trucs Qt c'est une bonne base non?

D'après ce que je commence à comprendre, la communication avec l'interface passe par des slots et des signaux. Ca a l'air d'être un gros bidouillage d'ailleurs, mais KDevelop gère heureusement tout ça.

Est-ce qu'on retrouve ce principe de slots/signaux sur KDE 4 ? Si oui, apprendre à programmer sur KDE 3 me permettra de comprendre la quasi-totalité du fonctionnement de KDevelop 4 ?

L'API change beaucoup sur KDE 4 ?

oui on retrouve ça bien sur

heureusement la plupart des signaux sont connectés automatiquement si tu leur donnes le bon nom.

ie si avec qtdesigner t'as fait un bouton "btnMachin" alors la méthode (slot) on_btnMachin_clicked() sera appelée quand tu cliques dessus.

au début c'est un peu chiant mais quand t'as pigé c'est le bonheur c'est vraiment "aussi facile que du VB" à coder (pour le concept je parle)

l'idée c'est faire un fichier machin.ui avec designer, un fichier machin.h et un fichier machin.cpp

uic va générer machin_ui.h qui contient la déf. de l'ihm.

cked(); }

machin.h:#include <QtCore>
#include <QtGui>
#include "machin_ui.h"
class machin: public QWidget, private UI::machin //oué on fait un héritage multiple pour récupérer en même temps QWidget et la méthode setupUI() dans le fichier machin_ui.h
{
Q_OBJECT
//constructeur, méthodes, toussa
public:
machin(QWidget *parent=0);
private slots:
void on_btnMachin_cli

dans le cpp tu mets tes implémentations

machin::machin(QWidget *parent): QWidget(parent)
{
setupUI(this);
}
void on_btnMachin_clicked()
{
QMessageBox::information(this,"hello","clic sur btnMachin");
}

après il vaut mieux utiliser qmake
qmake -project (une seule fois) génèrera un fichier .pro que tu pourras retoucher
puis qmake fera le makefile
make transformera le cpp/moc (les slots machin truc) en vrai C++ puis compilera/linkera.

squalyl (./7) :
heureusement la plupart des signaux sont connectés automatiquement si tu leur donnes le bon nom.

Cette fonctionnalité est nouvelle avec Qt 4 (comme pas mal d'autres trucs, c'est bien pour ça que je dis qu'il faut commencer tout de suite avec Qt/KDE 4).

après il vaut mieux utiliser qmake

Ou cmake, qui est utilisé par KDE 4 et conseillé pour les applications KDE 4, entre autre.

Thibaut (./6) :
Est-ce qu'on retrouve ce principe de slots/signaux sur KDE 4 ?

Oui.

Si oui, apprendre à programmer sur KDE 3 me permettra de comprendre la quasi-totalité du fonctionnement de KDevelop 4 ?

Pas vraiment, non. C'est vraiment trop tard pour commencer sur du KDE 3 maintenant!

L'API change beaucoup sur KDE 4 ?

Oui.

cmake supporte les features de qmake?

Si je comprends bien ton exemple, squalyl, l'objet bouton appelle une méthode de son parent (machin) quand on clique dessus. C'est assez curieux comme fonctionnement. Ca parait même sale au premier abord, mais il y a certainement une excellente raison

qmake et cmake servent à quoi ? KDevelop me génère un fichier Makefile classique et ça marche très bien. J'ai fait ./configure puis make puis sudo make install, et tout a très bien marché.

squalyl (./10) :
cmake supporte les features de qmake?

Oui, et il supporte aussi des trucs que qmake ne gère pas.

Thibaut (./11) :
Si je comprends bien ton exemple, squalyl, l'objet bouton appelle une méthode de son parent (machin) quand on clique dessus.

C'est toi qui choisis quel slot est appelé, en le connectant au signal. Mais avec Qt 4, un slot nommé on_objet_signal est automatiquement connecté au signal signal de l'objet objet.

C'est assez curieux comme fonctionnement. Ca parait même sale au premier abord, mais il y a certainement une excellente raison

Ça s'appelle la programmation évènementielle. Les signaux sont des évènements, les slots sont des gestionnaires (handlers) d'évènements.

qmake et cmake servent à quoi ? KDevelop me génère un fichier Makefile classique et ça marche très bien. J'ai fait ./configure puis make puis sudo make install, et tout a très bien marché.

Si tu as ./configure à lancer, ce n'est pas un makefile classique, c'est un système à base de configure, en l'occurrence les autotools, le build system antique, lourd, excessivement complexe et obsolète utilisé par KDE 3. KDE 4 utilise CMake à la place, c'est plus facile à utiliser, plus rapide, plus joli (les messages pendant la compilation sont en couleurs), plus fonctionnel (par exemple tu as un pourcentage de complétion pendant la compilation) etc.

As-tu déjà essayé le template C++/KDE4 de KDevelop 3? C'est du KDE 4 avec CMake. En revanche, l'intégration à KDevelop n'est pas top parce qu'ils attendent qu'on ait besoin de configurer certaines variables de l'environnement à la main (cf. le fichier README que ce template t'affiche quand tu crées un projet avec), je ne sais pas si c'est effectivement le cas sous Kubuntu. Sous Fedora, ce n'est pas nécessaire et j'ai donc patché le template dans KDevelop sous Fedora pour une meilleure intégration du template KDE 4.

En effet, les tutoriels de kdevelop.org sont un peu vieux. Tu auras des infos plus récentes ici : http://techbase.kde.org/Development
Sinon, Qt est en-dessous de KDE mais quand tu développes une application KDE tu utilises à la fois l'API Qt et l'API KDE, donc c'est bien de connaître Qt, notamment le fonctionnement des signals/slots, la gestion des évènements et la façon de peindre les widgets.

Au fait, si tu n'as pa envie de trop t'emmerder avec du C++ (qui sux quand même, il bien le dire), tu peux coder en Python par exemple

honnêtement je vois pas trop à quoi sert KDevelop vu qu'on a qtassistant, qtdesigner, qtlinguist, et (c|q)make. A la limite pour éditer les fichiers, mais kate s'en sort bien non?

KDevelop fait le lien entre tous ces outils.

Thibaud> Pour exploiter les fichiers d'interfaces créées avec Qt-Designer, tu dois utiliser l'outil uic (mais je crois que qmake le fait automatiquement).

Ouai j'ai cru comprendre ça. J'irai à la fac cette après midi pour imprimer ce guide. Il a l'air bien pour débuter.

Il permet certainement d'y voir plus clair quand on vient de VisualC++ et C++Builder sous Windows. KDevelop a l'air un poil plus complexe. Il faut mettre les mains dans le cambouis, là où C++Builder et autres font tout à ta place. Ce guide est pour KDE 3, mais j'ai installé KDE 4 tout à l'heure et c'est pas la peine de s'y attarder pour l'instant : il bug de partout, il a même complètement freezé à un moment, et j'ai pas trouvé de KDevelop dédié dans Synaptic.

Tu peux dev pour KDE4 dans un environnement KDE3.

Ouai mais d'après Kevin il vaut mieux éviter ("KDevelop 3 a un support limité pour le développement KDE 4, mais si tu veux vraiment un environnement de développement optimisé pour KDE 4, il faudra attendre KDevelop 4 (qui est actuellement en alpha et qui sortira probablement avec KDE 4.2)").

C'est surtout histoire de bien comprendre les grands principes. Je ne compte pas sortir demain un logiciel de montage vidéo ou un traitement de texte

squalyl (./7) :
oui on retrouve ça bien sur

heureusement la plupart des signaux sont connectés automatiquement si tu leur donnes le bon nom.

ie si avec qtdesigner t'as fait un bouton "btnMachin" alors la méthode (slot) on_btnMachin_clicked() sera appelée quand tu cliques dessus.

au début c'est un peu chiant mais quand t'as pigé c'est le bonheur c'est vraiment "aussi facile que du VB" à coder (pour le concept je parle)

l'idée c'est faire un fichier machin.ui avec designer, un fichier machin.h et un fichier machin.cpp

uic va générer machin_ui.h qui contient la déf. de l'ihm.

cked(); }

machin.h:#include <QtCore>
#include <QtGui>
#include "machin_ui.h"
class machin: public QWidget, private UI::machin //oué on fait un héritage multiple pour récupérer en même temps QWidget et la méthode setupUI() dans le fichier machin_ui.h
{
Q_OBJECT
//constructeur, méthodes, toussa
public:
machin(QWidget *parent=0);
private slots:
void on_btnMachin_cli

dans le cpp tu mets tes implémentations

machin::machin(QWidget *parent): QWidget(parent)
{
setupUI(this);
}
void on_btnMachin_clicked()
{
QMessageBox::information(this,"hello","clic sur btnMachin");
}

après il vaut mieux utiliser qmake
qmake -project (une seule fois) génèrera un fichier .pro que tu pourras retoucher
puis qmake fera le makefile
make transformera le cpp/moc (les slots machin truc) en vrai C++ puis compilera/linkera.

Il sert a quoi ton heritage privé, tu peux pas agreger?

a appeler setupUI dans le constructeur, code généré par uic depuis le fichier .ui de qtdesigner

le reste je m'en tape.

Thibaut (./18) :
Ouai mais d'après Kevin il vaut mieux éviter ("KDevelop 3 a un support limité pour le développement KDE 4, mais si tu veux vraiment un environnement de développement optimisé pour KDE 4, il faudra attendre KDevelop 4 (qui est actuellement en alpha et qui sortira probablement avec KDE 4.2)").

Mais c'est toujours mieux que développer pour KDE 3, et ainsi créer des applications obsolètes dès le départ!

JackosKing (./19) :
Il sert a quoi ton heritage privé, tu peux pas agreger?

Évidemment qu'il peut, mais l'héritage est plus pratique.

Et pourquoi cela?

Je ne vois aucun intérêt de faire un héritage privé. Le coté pratique n'est pas un argument pour moi.

je sais pas si tu remarques mais là tu ramènes tes grands sabots dans un sujet dont tout le monde se fout.

j'ai fait un héritage privé PARCE QUE.

ça marche, mon code est pas public, point barre.

Du calme

oh mais je suis calme mais je connais JK qui va vouloir forcément sortir le mot "contrat", alors je l'arrête avant

non mais de toute maniere tu le sais que tu fais un truc pas bien, suffit de voir le commentaire de ton code

Bon sinon on va revenir au sujet

Bah, moi je fais la même chose partout dans KTIGCC sans ce commentaire. Et uic3 de Qt 4 utilise ça par défaut (ça fait partie de la compatibilité antérieure avec Qt 3 pour les .ui, mais ça reste pratique pour les nouveaux développements).

Cf. http://doc.trolltech.com/4.4/porting4-designer.html#uic-output et http://doc.trolltech.com/4.4/designer-using-a-component.html#compile-time-form-processing. Ce que tu proposes est le single-inheritance approach, squalyl utilise le multiple-inheritance approach qui, selon Trolltech, est "slightly cleaner than the single inheritance approach".

Et bien je ne suis pas d'accord avec eux, et je ne pense pas être le seul.
D'ailleurs pourquoi plus propre?
A continuer dans un nouveau topic si tu le souhaites

Vous pouvez ici si vous voulez.

JackosKing, il faudra comprendre que dans la vie réelle, l'héritage d'implémentation est un concept très utilisé et personne n'a rien à battre des principes théoriques que tu défends. D'autant plus que l'héritage est privé, donc ce n'est pas visible en dehors de la classe et donc ça ne va pas à l'encontre du principe de Liskov (parce qu'il n'y a pas d'abus du polymorphisme étant donné qu'il n'y a pas polymorphisme, l'héritage étant privé).