Bonjour,
J'ai développé un logiciel, et je pense qu'il pourrait être utile à certains.
Historique
Je travaille dans une équipe de recherche qui développe un simulateur de croissance de plantes: digiplante. Ce simulateur pour fonctionner à besoin de paramètres complexes en entrée. La liste et le type des paramètres sont amenés à être modifiés assez fréquemment (au cours des développements et des travaux de recherche). Nos paramètres sont stockés dans un fichier XML, or comme tout le monde le sait XML c'est pas très pratique à éditer à la main (particulièrement lorsque on s'adresse à des non-informaticiens). Il nous fallait donc une solution souple permettant de saisir les paramètres et donc de créer le fichier XML.
Le logiciel exxEditor
Pour résoudre se problème, nous avons développé exxEditor, un "éditeur" XML, qui génère une interface en lisant un fichier XML Schema. On a ainsi une interface qui affiche l'arbre des paramètres, et permet de les modifier. Bien entendu, exxEditor fait en sorte que l'utilisateur ne puisse pas entrer des valeurs non valides. Pour ce rendre compte de quoi il s'agit, rien de mieux qu'une copie d'écran.
Vous pouvez télécharger exxEditor sur le site du projet.
La gestion du projet ce fait sur la Gforge INRIA.
Licence
exxEditor est sous licence CeCILL-C (type LGPL).
Technique
exxEditor est développé en C++ avec Xerces pour la "décomposition analytique" XML, Qt pour l'interface et Boost pour un peu tout le reste. On utilise CMake comme système de configuration. ExxEditor est multi-plateforme (Linux - Windows - MacOs).
ExxEditor est conçu de manière à pouvoir s'intégrer facilement dans une application Qt.
Avancement et version
exxEditor est maintenant en version 0.9 (comprendre en Beta), et lorsqu'il sera un peu mieux testé et débogué, il passera en version 1.0. Bien que le logiciel ne soit pas capable d'interpréter l'ensemble de la norme XML Schema, je ne compte pas ajouter de nouvelles fonctionnalités avant la version 1.0. En effet, il répond déjà parfaitement à mes besoins, et presque toutes les fonctionnalités basiques de XML Schema sont supportées.
Liens
Captures d'écran [http://dgp-public.gforge.inria.fr/fr/capture_ecran.html].
Téléchargements [http://dgp-public.gforge.inria.fr/fr/telechargement.html].
Site officiel [http://dgp-public.gforge.inria.fr/fr/index.html].
Licence CeCILL-C [http://www.cecill.info/licences/Licence_CeCILL-C_V1-fr.html]
Journal Sortie de exxEditor - version 0.9
17
août
2010
# Qt mais pas complètement ?
Posté par steckdenis (site web personnel) . Évalué à 8.
Je n'ai pas encore lu le code de ce logiciel, mais ça m'étonne un tout petit peu de le voir utiliser Qt, ainsi que deux autres dépendances qui ont de beaux modules Qt qui les remplacent.
Par exemple, QtXml propose un arbre DOM mais aussi une interface en flux. QtXmlPatterns propose tout ce qu'il faut pour gérer les schémas XML. Je ne sais pas quelles parties de Boost sont utilisées, mais les regexp, les signaux et les slots sont proposés par Qt.
Pour ceux qui disent que Qt est trop lent, c'est son DOM qui est lent (instanciation de QObject en série), pas l'interface par flux, qui est très rapide.
Ce n'est absolument pas une critique, je suis juste un peu étonné.
[^] # Re: Qt mais pas complètement ?
Posté par Thomas Guyard . Évalué à 10.
La première est "historique". Quand j'ai commencé à développé exxEditor, je ne connaissais pas suffisamment Qt et surtout j'ai commencé le développement avant d'avoir choisi quelle bibliothèque j'allais utiliser pour la GUI.
Ensuite la deuxième raison est une question d'organisation du code. Le code est organisé en packages et je voulais être sûr que les basses couches ne dépendaient pas du toolkit graphique.
Je reconnais que ça peu être limite comme argument, comparé à avoir 2 dépendances supplémentaires.
En fait j'utilise Qt comme un toolkit graphique uniquement, et non pas comme une plateforme complète de développement d'application.
[^] # Re: Qt mais pas complètement ?
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Qt mais pas complètement ?
Posté par zebra3 . Évalué à -1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Qt mais pas complètement ?
Posté par Thomas Guyard . Évalué à 1.
Merci.
[^] # Re: Qt mais pas complètement ?
Posté par steckdenis (site web personnel) . Évalué à 4.
C'est dommage, d'une part pour les distributions qui ont des dépendances en plus à gérer (ce programme semble très bon, il y a des chances qu'il soit empaqueté au moins par Debian), et pour le développeur, qui a plusieurs bibliothèques à apprendre.
Je vais me prendre comme exemple : je connais une bonne partie de Qt, et sait me servir de sa doc. Je n'ai jamais utilisé ses flux XML (uniquement le DOM), mais la doc est là et je la comprend. Je serais capable de contribuer à exxEditor. Par contre, je ne connais pas Xerces, ni Boost, donc je ne peux que difficilement aider.
> toolkit graphique
Tout à fait d'accord, j'évite absolument d'utiliser des parties de QtGui dans la libpackage de Setup, qui doit servir au client console. Pas de GUI là-bas.
N'empêche, j'utilise QtCore, QtXml, QtScript et QtSql dans cette bibliothèque. Le gros morceau de Qt est QtGui (et QtWebkit si on le sépare de QtGui). Le reste n'est pas graphique. La plupart des distributions font de bons paquets et séparent les composants de Qt, mais les distributions "en block", comme ArchLinux ou Gentoo, gardent le paquet en un gros morceau, donc je peux comprendre le refus d'utiliser Qt pour une partie console.
Mais bon, je comprends l'argument historique et vais cesser de chipoter avec Qt. Je n'aime pas qu'on me dise que j'ai utilisé les mauvaises libs, donc je ne le fais pas moi-même (ce message est avant-tout un anti-FUD des GTKistes qui réduisent Qt à une lib graphique lourde et liée à KDE).
Beau travail en tous cas, ça pourrait me servir un de ces jour si je dois faire éditer des fichiers XML par madame michu.
[^] # Re: Qt mais pas complètement ?
Posté par defmonkey . Évalué à 3.
Entre nous soit dit, c'est un peu de la mauvaise foi car :
- Xerces est *the* implementation XML/DOM utilisée en C++
- C++ sans boost, c'est un peu les spagetthis sans la bolognaise ...
[^] # Re: Qt mais pas complètement ?
Posté par claudex . Évalué à 7.
Sauf que je ne vois pas bien l'intérêt de boost quand on utilise Qt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Qt mais pas complètement ?
Posté par dj_ (site web personnel) . Évalué à 3.
Comme il le dit plus haut, il n'était pas certain de garder QT donc il n'allait pas s'emprisonner avec une technologie et devoir recoder tout s'il voulait passer en TCL/TK, GTK etc
[^] # Re: Qt mais pas complètement ?
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Qt mais pas complètement ?
Posté par defmonkey . Évalué à 2.
Je pense qu'il y a plus de dev c++ à connaitre/pratiquer boost que Qt. Donc pour la partie core, je ne trouve pas ça illogique d'utiliser boost, surtout s'il y a une bonne séparation core/gui.
[^] # Re: Qt mais pas complètement ?
Posté par Kévin Guilloy . Évalué à 8.
[^] # Re: Qt mais pas complètement ?
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Qt mais pas complètement ?
Posté par zebra3 . Évalué à 2.
Chacun ses goûts, certains aiment la sauce carbonara...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Qt mais pas complètement ?
Posté par Gniarf . Évalué à 3.
[^] # Re: Qt mais pas complètement ?
Posté par zebra3 . Évalué à 3.
Merci pour ce moment de nostalgie.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Qt mais pas complètement ?
Posté par monsieurmoche . Évalué à 6.
C'est la meilleure solution pour un bon découplage. Si un jour il veut se passer de Qt, ou si Qt évolue et casse son API, ou encore si quelqu'un souhaite faire un front-end s'intégrant mieux à Gnome (avec GTKmm et autres libs C++ de Gnome) ou autre environnement de bureau, il aura beaucoup moins de problèmes.
Si être à la fois dépendant de Qt et de Boost est considéré comme stupide, alors qu'en serait-il d'une double dépendance Qt/GTKmm…
Après, c'est peut-être un peu plus personnel, mais je trouve que Qt en fait trop. Non seulement ça fait doublon avec Boost, mais c'est également le cas avec la STL (pour des raisons historiques).
Un truc qui manque à l'écosystème C++, c'est une bonne lib GUI qui se contente d'être une lib GUI et qui ne cherche pas à faire en prime le café et la mayonnaise. Bref, en d'autres termes, j'aime bien les libs, mais pas les frameworks intrusifs.
À mon avis, dans l'état actuel des choses, la combinaison [C++, SL, Boost, autres libs métier, lib GUI] est ce qu'il y a de plus propre. Et si en plus c'est buildé avec CMake, c'est juste parfait ;).
[^] # Re: Qt mais pas complètement ?
Posté par tanguy_k (site web personnel) . Évalué à 9.
Et si Boost et Xerces cassent leurs API ? cet argument est ridicule. Pour info Qt n'a pas cassé son API source et binaire depuis plus de 5 ans.
> un front-end s'intégrant mieux à Gnome
Et ? QtCore, QtXML ect... sont des librairies comme les autres. Rien n'empêche de faire une GUI GTK+ par dessus. QtCore s'intègre parfaitement avec la boucle d'événement de la GLib. L'inverse existe également : le modèle en GLib et la vue en Qt.
Au passage désormais (depuis 2 ans déjà) l'intérêt de développer une GUI GTK+ par dessus un modèle qui utilise QtCore n'est plus franchement intéressant grâce à l'utilisation de QGtkStyle http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-par(...) qui permet d'avoir une intégration parfaite dans GNOME. QGtkStyle est intégré dans toutes les distribs modernes et fonctionne vraiment très bien.
> je trouve que Qt en fait trop. Non seulement ça fait doublon avec Boost,
> mais c'est également le cas avec la STL
Pour avoir utilisé Boost pendant 3 ans, Qt est bien supérieur en terme de fonctionnalités, de cohérence et de documentation. Pour la STL j'en parle même pas.
> Un truc qui manque à l'écosystème C++, c'est une bonne lib GUI qui se contente d'être une lib GUI
Et en quoi QtGui ne répond pas a cette problématique ?
Pour info ca fait plus de 5 ans que Qt est découpé en modules indépendants simples et cohérents...
> j'aime bien les libs, mais pas les frameworks intrusifs
Comment peut on avoir une vision aussi archaïque !
Vraiment utilise Qt, ou meme C# ou Java et ensuite compare a tes méthodes de développement qui utilisent 15 libs différentes pour afficher hello world.
> la combinaison [C++, STL, Boost, autres libs métier, lib GUI] est ce qu'il y a de plus propre
C'est ce que je pensais (il y a très longtemps) et finalement dans la pratique on se rend compte que c'est compliqué pour rien : ça crée des problèmes sans rien apporter de plus.
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Qt n'a pas d'équivalent à bind, multi_index, graph et autres, asio et thread sont bien mieux fait que QtThread et QtNetwork...
Certains composants de Qt dépendent d'une boucle d'évènement et de variables globales (l'instance de QCoreApplication) : c'est pas terrible pour faire une bibliothèque réutilisation hors des applications Qt...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par Gof (site web personnel) . Évalué à 3.
Par contre, je trouve que la programation avec des thread Qt et QtConcurrent très bien. En quoi boost thread est il mieux fait? (peut être plus bas niveau?)
Je ne connais pas asio, qu'y a t il de mieux dans asio ?
> Certains composants de Qt dépendent d'une boucle d'évènement
> et de variables globales
Oui, et ? Quel est le problème ?
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le simple fait que tu poses la question montre que tu n'as jamais eu affaire au problème :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par tanguy_k (site web personnel) . Évalué à 2.
Effectivement dans certains cas t'es obligé de fournir une fonction init() (et même exec() et close() qui encapsule QApplication::exec()) que l'utilisateur devra appeler avant d'utiliser ta librairie basée sur Qt.
Ceci n'est pas spécifique à Qt, cURL par exemple fonctionne sur des mécanismes similaires (curl_init(), curl_exec(), curl_close())
> asio et thread sont bien mieux fait que QtThread et QtNetwork
Ce que je retiens de Boost c'est son coté API bas niveau comparée à celle de Qt qui est beaucoup plus simple et cohérente.
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Mais pas à boost! Par exemple pas besoin de boucle d'évènements pour utiliser faire du réseau ou pour gérer des signals/slots. Tiens à propos de ces derniers, la version boost est plus puissante et plus simple, puisqu'il n'y a besoin d'un précompilateur...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par Gof (site web personnel) . Évalué à 3.
Par ailleurs, la boucle d'événement de Qt s'intègre très bien dans une autre boucle d'événements d'une autre lib.
Il suffit d'apellet Q(Core)Application::processEvents() à chaque iterations.
Et les signaux de boost ne permettent pas de passer d'un thread à l'autre. Ou de mettre en queue des signaux.
En plus, il est impossible de rajouter des signaux boost a une classe sans casser la compatibilité binaire, alors que c'est pas un probème avec Qt.
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca ne marche que pour les "direct connections", cad pas entre plusieurs threads...
Donc encore une fois dans un cas particulier... Le cas général reste intrusif!
Tes connaissances doivent dater de quelques années. Lis la doc de boost, tu verras que tout ça est possible!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par monsieurmoche . Évalué à 1.
Je pensais que Qt était un conglomérat de libs interdépendantes, mais si ce n'est pas le cas, tant mieux. J'aime avant tout le C++.
Par contre, le point qui me rebutera toujours autant, c'est le fait que ça fasse doublon avec la STL (et à moins forte raison avec Boost). C'est regrettable pour l'écosystème C++, qui aurait l'air beaucoup plus cohérent et cohésif si la hiérarchie S(T)L -> Boost -> Qt était respectée.
Bon, encore pour Boost… après tout ils se font pas partie du standard (bien que certaines libs de Boost y aient été incluses, mais passons sur ce détail). Mais vraiment, le doublon avec la STL, je trouve que ça fait tache.
Pour finir, la raison pour laquelle je n'aime pas les frameworks (dans leur aspect bloc monolithique, ce que Qt n'est pas si j'en crois ton argumentaire) s'explique par mon attachement au principe KISS d'Unix : chaque entité fait une chose et une seule, et le fait bien.
J'ai eu l'occasion de travailler avec Java, et vraiment non merci. Je m'en sors bien mieux avec mon C++ et les multitudes de dépendances qui peuvent en découler.
[^] # Re: Qt mais pas complètement ?
Posté par Gof (site web personnel) . Évalué à 4.
Qt essaye de fournir une API facile d'utilisation, cohérente, multi-platformes, intuitive.
Alors que la STL est plus bas niveau.
Par example, les conteneurs de Qt sont "implictly shared" ce qui permet de pouvoir passer des listes ou des chaîne de caractère d'une classe à l'autre de manière performante, très facilement et intuitivement.
Les conteneur STL ne le sont pas car cela veux dire que le la copie à lieu a des moment non déterministique, ce qui est une horreur pour la programmation temps réel.
La STL fait un usage important des templates, ce qui la rends plus difficile d'utilisation pour les novice. Un programmeur Qt peut s'en tirer sans connaître cette partie compliquée du C++.
Exemple, les conteneur STL permettent d'avoir un "allocateur" personalisé. Mais qui a vraiment besoin de ça ? Et ce n'est pas transparent pour l'utilisateur si on ne les utilise pas (les messages d'erreurs sont imbitables, ça apparaît dans l'auto-completion, impossible de forward-déclarer certaine classes, ...)
[^] # Re: Qt mais pas complètement ?
Posté par monsieurmoche . Évalué à 1.
Alors que la STL est plus bas niveau.
Hum… cette phrase sonne très « Qt, c'est le plus beau et le plus fort et pis c'est tout » !
Dire que la STL n'est ni intuitive, ni facile d'utilisation, c'est très subjectif… Personnellement, je ne vois pas ce qu'elle a de contre-intuitive ou de difficile d'accès.
La STL pas cohérente ? Tu peux développer ?
La STL pas multi-plateforme… euh faut peut-être pas déconner, là !
Par example, les conteneurs de Qt sont "implictly shared" ce qui permet de pouvoir passer des listes ou des chaîne de caractère d'une classe à l'autre de manière performante, très facilement et intuitivement.
Un peu comme un vector de shared_ptr, c'est ça ?
Si oui, quel avantage sur ce dernier ?
Les conteneur STL ne le sont pas car cela veux dire que le la copie à lieu a des moment non déterministique, ce qui est une horreur pour la programmation temps réel.
En quoi la copie des conteneurs de la STL n'est pas déterministe ?
La STL fait un usage important des templates, ce qui la rends plus difficile d'utilisation pour les novice. Un programmeur Qt peut s'en tirer sans connaître cette partie compliquée du C++.
Ben, c'est du C++, quoi…
Se passer des templates, je trouve ça idiot. Franchement.
Mais bon, admettons que ce soit trop compliqué… Si un template est peut-être compliqué à coder, je ne vois pas en quoi il l'est à l'utilisation.
On crée un std::vector, on met des ints dedans… bon… c'est pas bien sorcier, si ?
Exemple, les conteneur STL permettent d'avoir un "allocateur" personalisé. Mais qui a vraiment besoin de ça ? Et ce n'est pas transparent pour l'utilisateur si on ne les utilise pas (les messages d'erreurs sont imbitables, ça apparaît dans l'auto-completion, impossible de forward-déclarer certaine classes, ...)
Je n'ai jamais codé d'allocateur, mais je n'ai jamais souffert du fait qu'il soit possible d'en utiliser un.
Les messages d'erreur des templates sont parfois à rallonge, ça je te l'accorde. Mais c'est plus un problème inhérent au couple langage/compilateur. De plus, il existe un outil nommé STLFilt permettant de fournir des messages d'erreur plus clairs que ceux des compilateurs.
Que ça apparaisse dans l'auto-complétion, je vois pas bien ce que ça a de dramatique.
Quelle classe souhaites-tu forward-déclarer ? Et pourquoi ? De toute façon il est possible d'écrire des forward declarations pour n'importe quelle classe ou template de classe.
[^] # Re: Qt mais pas complètement ?
Posté par Gof (site web personnel) . Évalué à 2.
La STL pas cohérente avec le reste de Qt. (Bon, c'est la faute de Qt)
> Un peu comme un vector de shared_ptr, c'est ça ?
c'est plus simple de faire
QString maString("foo");
que string_ptr maString(new string("foo"));
> En quoi la copie des conteneurs de la STL n'est pas déterministe ?
Tu m'a mal compris. Je disais justement que la STL voulais que ce soit déterministe et que c'est une des raisons pour laquelle rien n'est partagé par défaut.
> Se passer des templates, je trouve ça idiot. Franchement.
Qt ne se passe pas des template, ils sont juste utilisé modérément. std::vector ça va.
[^] # Re: Qt mais pas complètement ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Les devs qui ont peur des templates n'ont rien à faire en C++ :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par lasher . Évalué à 2.
Le problème de C++ ce n'est pas les templates, ni la partie objet, ni le C, ni la STL. Le problème, c'est que c'est comme le C mais en pire : c'est un langage multi-paradigmes pour gens qui savent ce qu'ils font. Qu'on soit bien d'accord, j'adore le C. Je code quasiment uniquement dans ce langage (je fais des trucs assez bas-niveau).
Ce que je veux dire, c'est que
- faire du « C en C++ » en profitant de la STL mais sans écrire de templates, c'est bien;
- faire du « C avec classes » pour faire de la POO, c'est bien;
- faire des templates de fonctions pour obtenir de meilleures perfs, et faire du C tout court, c'est bien;
- faire du « C avec classes » et utiliser des templates de fonctions, c'est bien;
- faire du « C avec classes » et utiliser la STL, c'est bien;
...
Par contre, à partir du moment où tu commences à sérieusement mélanger tout ça (et je te parle pas des templates de classes), que tu rajoutes la surcharge d'opérateurs (et de tous les pièges induits, genre quand et où faut-il mettre des const...), etc., oui là j'ai tendance à y aller à reculons...
Du coup je comprends les réticences de certaines personnes vis-à-vis du C++ et des templates quand on voit certaines horreurs qui sont commises. Et on peut parfaitement faire du C++ sans templates (par contre, sans un truc type STL ou assimilé, c'est un peu se faire mal pour rien).
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Non, pourquoi? Il y a écrit "les templates sai pas lol, qt sa roxe" dedans?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Qt mais pas complètement ?
Posté par lasher . Évalué à 2.
[^] # Re: Qt mais pas complètement ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Le problème de C++, c'est que pour y faire quelque chose de correct, il faut lire, beaucoup (Stroustrup, Sutter, Herbs, Meyers, etc).
[^] # Re: Qt mais pas complètement ?
Posté par auve . Évalué à 3.
... et Alexandrescu alors ? /o/
[^] # Re: Qt mais pas complètement ?
Posté par shbrol . Évalué à 1.
Après, quand on a épuisé le tout venant, on peut s'attaquer au bizarre.
[^] # Re: Qt mais pas complètement ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Qt mais pas complètement ?
Posté par monsieurmoche . Évalué à 2.
D'accord, ça facilite probablement la tâche du programmeur en rendant le code plus concis… mais ces « public signals: » non-standards, y'a rien à faire, ça me sort par les yeux.
Je développe une lib d'analyse de code source C++ et j'aime pas trop l'idée d'avoir à faire du dev spécifique pour supporter les excentricités de tous les frameworks qui peuvent exister, même si l'un d'eux s'appelle Qt.
[^] # Re: Qt mais pas complètement ?
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Qt mais pas complètement ?
Posté par monsieurmoche . Évalué à 1.
Par contre, ne le prends pas mal mais je reste dubitatif…
Selon ce bout de code :
class Foo : public QObject
{
Q_OBJECT
public:
Foo();
int value() const { return val; }
public slots:
void setValue( int );
signals:
void valueChanged( int );
private:
int val;
};
… on aurait donc une macro « slots » et une autre « signals » ?
Par quoi peut bien être remplacé « slots », si ce n'est du vide, pour que le code soit standard ?
[^] # Re: Qt mais pas complètement ?
Posté par Thomas Guyard . Évalué à 1.
Pour être plus précis voila ce qu'on trouve dans le code Qt
#define slots
#define signals protected
[^] # Re: Qt mais pas complètement ?
Posté par monsieurmoche . Évalué à 1.
Et donc moc va rajouter des variables et fonctions membres à la classe en question, avant de passer le code à la chaine de compilation standard (préprocesseur compris) ?
Bon bah c'est chouette, ça reste bon pour mes affaire ;).
[^] # Re: Qt mais pas complètement ?
Posté par sanao . Évalué à 0.
Ce fichier est généré par le MOC pour chaque classe ayant la macro Q_OBJECT.
Le MOC, c'est juste un préprocesseur fournissant des trucs très cool comme les signaux/slots (façon compréhensible par un jeune développeur C++ et non façon boost), l'instrospection et quelques mots clés (toujours via des macros).
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'était très cool au millénaire dernier. Aujourd'hui, personne ne ferait un framework sérieux avec une bouse pareille.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par sanao . Évalué à 2.
Je ne te demande pas d'aimer Qt (c'est très personnel ce genre de truc). Juste de comprendre comment ça fonctionne et d'essayer de voir pourquoi certains développeurs trouvent cela bien.
[^] # Re: Qt mais pas complètement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
La GUI?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt mais pas complètement ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
# grrr, et la dépêche ? ;)
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: grrr, et la dépêche ? ;)
Posté par Thomas Guyard . Évalué à 8.
[^] # Re: grrr, et la dépêche ? ;)
Posté par claudex . Évalué à 7.
Moins qu'un journal, vu que les éventuelles fôte peuvent être corrigées.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: grrr, et la dépêche ? ;)
Posté par Davy Defaud . Évalué à 3.
Il faudra corriger cette vilaine faute avant d'en faire une dépêche.
Sinon, bravo pour ta contribution communautaire qui comble un vide en la matière.
# juste ce qu'il me fallait ...
Posté par Amber . Évalué à 3.
Je dois (devoir moral diront nous) coder un petit soft de lecture pour un fichier xml généré par une appli métier avant la fin de la semaine prochaine, que je n'ai bien évidemment pas commencé puisque je n'ai pas fini le reste de mon travail.
Ca tombe donc à pic. Merci beaucoup :-)
Je n'en dit pas plus... les corporations ont des oreilles !
[^] # Re: juste ce qu'il me fallait ...
Posté par Maxime (site web personnel) . Évalué à 4.
Bon par contre j'ai essayé de compiler l'appli tout à l'heure au boulot et ça n'a pas marché. Je n'ai pas insisté, je vais réessayer là pour voir si ça marche mieux.
[^] # Re: juste ce qu'il me fallait ...
Posté par lolop (site web personnel) . Évalué à 4.
Il est pas bien votre fichier de conf éditable avec n'importe quel éditeur ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: juste ce qu'il me fallait ...
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: juste ce qu'il me fallait ...
Posté par Maxime (site web personnel) . Évalué à 2.
element1_propriete_a = 42
element1_propriete_b = "bla"
element1_propriete_c = 4
element2_propriete_a = 2
element2_propriete_b = "ooops"
element2_propriete_c = 8
etc.
En plus d'être un peu lourd à écrire (au risque de faire une faute en plus), quand tu veux supprimer l'un des éléments, t'es obligé de tout renuméroter.
(enfin, je suppose un peu car ce n'est ni moi moi qui l'utilise ou le code mais lors de la réunion ils ont évoqué rapidement le problème)
[^] # Re: juste ce qu'il me fallait ...
Posté par lolop (site web personnel) . Évalué à 3.
Pour un problème similaire, j'avais utilisé qq chose du genre (en utilisant les sections):
[global]
les_elements=x,y
[proprietes x]
a = 42
b = "bla"
c = 4
[proprietes y]
a = 2
b = "ooops"
c = 8
Tu conserves un ordre si besoin dans les_elements (y'a qu'à découper sur la virgule), et tu fais une association simple élément/propriétés via les sections.
Sinon, Yaml (toujours éditable avec un simple éditeur) ?
Bon, c'est juste que je trouve moyen les fichiers de conf en XML - sauf s'il y a un éditeur dans l'application et que l'on n'a pas à voir l'XML. Ça oblige avoir un éditeur spécifique pour ce format (exxEditor par exemple :-).
XML permet de rattraper des choses à la main, d'éditer rapidement un petit contenu pour démarrer... mais ça reste un format d'échange entre applications, on ne devrais quasiment pas avoir à le lire/l'écrire nous même, c'est pas "human friendly" même si c'est "human usable".
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: juste ce qu'il me fallait ...
Posté par Maxime (site web personnel) . Évalué à 4.
<element a="42" b="bla" c="4"/>
<element a="2" b="ooops" c="8"/>
En tout cas, merci pour l'exemple, c'est intéressant. Par contre je ne sais pas comment ils ont géré la lecture de fichier ini, je ne sais pas si les sections sont prises en compte.
[^] # Re: juste ce qu'il me fallait ...
Posté par tesiruna . Évalué à 1.
Pourquoi ne pas utiliser quelque chose de plus simple comme le yaml ?
[^] # Re: juste ce qu'il me fallait ...
Posté par yellowiscool . Évalué à 4.
C'est beaucoup plus facile de faire du xml lisible que du json lisible.
Je n'accroche pas du tout au yaml, surtout quand il y a une erreur de syntaxe.
Envoyé depuis mon lapin.
# Concurrence
Posté par koxinga . Évalué à 1.
[^] # Re: Concurrence
Posté par GnunuX (site web personnel) . Évalué à 1.
[^] # Re: Concurrence
Posté par Phil Actaire . Évalué à 2.
Ici, on a la partie éditer un XML selon un schéma.
Il ne me manque que l'édition du schéma.
[^] # Re: Concurrence
Posté par Thomas Guyard . Évalué à 2.
Techniquement, c'est un éditeur XML, mais pour l'utilisateur c'est juste une application qui permet de rentrer des paramètres pour ensuite lancer son application.
Je n'ai pas trouvé de logiciel qui fasse ça "correctement". J'ai bien vu une application java (je ne me rappelle plus le nom) qui fonctionne sous le même principe, mais qui n'est pas utilisable dès lors que le XML fait plus de quelques lignes.
[^] # Re: Concurrence
Posté par Narmer . Évalué à 1.
il y a Serna Editor qui est passé en libre dernièrement qui a des fonctionnalités ressemblantes
http://www.syntext.com/downloads/serna-free/
Il y a une version free et une version commerciale
les fonctionnalités sont exprimées ici
http://www.syntext.com/products/serna-feature-matrix/
Vala.
# Pourquoi pas Jaxe?
Posté par cc . Évalué à 1.
Pourquoi ne pas avoir utilisé Jaxe?
cc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.