Je passe ces vacances à apprendre à écrire des applications Qt. Je lisais à propos de Qt Designer il y a quelques heures à peine, ce qui m'a fait me demander: qu'est-ce que les gens qui écrivent des applications du monde réel dans Qt utilisent pour concevoir leurs interfaces graphiques? En fait, comment les gens conçoivent-ils les interfaces graphiques en général?
Pour ma part, j'ai trouvé que l'écriture du code à la main était conceptuellement plus simple que l'utilisation de Qt Designer, bien que pour les interfaces graphiques complexes, Designer puisse avoir du sens. De grandes interfaces graphiques peuvent être possibles en utilisant Designer, mais avec le temps, elles peuvent devenir très difficiles à gérer à mesure que la complexité augmente (ce n'est que mon avis). J'ai également téléchargé le code source d'AmaroK pour jeter un coup d'œil à ce que faisaient ces gars-là, et j'ai trouvé de nombreux appels à addWidget () et à des amis, mais aucun de ces fichiers XML créés par Designer (à part: AmaroK doit être mon application préférée sur n'importe quelle plateforme).
Quelle est alors la «bonne» façon de créer une interface graphique? Concepteur ou code? Prenons, pour cette discussion, les types d'interfaces graphiques suivants:
- Des dialogues simples qui ont juste besoin de prendre des entrées, d'afficher des résultats et de quitter. Supposons une application qui prend une URL YouTube et télécharge la vidéo sur le disque dur de l'utilisateur. Le type d'applications avec lesquelles un débutant est susceptible de commencer.
- Les interfaces graphiques de niveau intermédiaire comme, par exemple, un éditeur de notes autocollantes avec quelques éléments de barre d'outils / menu. Prenons xPad par exemple ( http://getxpad.com/ ). Je dirais que la plupart des applications tombent dans la catégorie des "utilitaires".
- Des interfaces graphiques très complexes, comme AmaroK ou OpenOffice. Vous les connaissez quand vous les voyez parce qu'ils vous font saigner les yeux.
la source
D'après mon expérience avec Qt Designer et d'autres boîtes à outils / outils d'interface utilisateur:
La complexité peut souvent être traitée dans un outil d'interface utilisateur en divisant la conception en plusieurs fichiers d'interface utilisateur. Incluez de petits groupes logiques de composants dans chaque fichier et traitez chaque groupe comme un widget unique utilisé pour créer l'interface utilisateur complète. Le concept de widgets promus par Qt Designer peut vous aider.
Je n'ai pas trouvé que l'échelle du projet fasse une différence. Votre expérience peut varier.
Les fichiers créés avec les outils d'interface utilisateur (je suppose que vous pouvez les écrire à la main si vous le souhaitez vraiment) peuvent souvent être chargés dynamiquement au moment de l'exécution (Qt et GTK + fournissent tous deux cette fonctionnalité). Cela signifie que vous pouvez apporter des modifications de mise en page et les tester sans recompiler.
En fin de compte, je pense que le code brut et les outils d'interface utilisateur peuvent être efficaces. Cela dépend probablement beaucoup de l'environnement, de la boîte à outils / de l'outil d'interface utilisateur et bien sûr des préférences personnelles. J'aime les outils d'interface utilisateur car ils me permettent d'être opérationnel rapidement et de permettre des modifications faciles plus tard.
la source
L'organisation pour laquelle je travaille a porté son application GUI sur Qt il y a plusieurs années. Je pense qu'il y a plusieurs aspects qui méritent d'être mentionnés:
Ma propre expérience, qui remonte à env. 4 ans, en utilisant Qt3.3, c'est que le comportement dynamique dans les dialogues n'était pas possible à réaliser dans Designer.
la source
Juste pour dire que j'ai écrit et maintenu des interfaces graphiques complexes dans Qt sans utiliser Qt Designer - non pas parce que je n'aime pas Qt Designer, mais parce que je n'ai jamais eu l'occasion de travailler de cette façon.
C'est en partie une question de style et d'où vous venez: quand j'ai commencé sur Qt, j'avais eu des expériences horribles de Dreamweaver et Frontpage et d'autres outils HTML visuels, et je préférais de loin écrire du code avec HomeSite et recourir à Photoshop pour une mise en page délicate problèmes.
Il y a un danger avec les IDE de code visuel que vous essayez de conserver dans les outils visuels, mais que vous deviez également modifier le code - d'une manière qui n'est pas bien comprise.
En apprenant le développement de l'iPhone, par exemple, j'ai trouvé frustrant de frapper des éléments visuels `` magiques '' (`` faire glisser du cercle vide dans l'inspecteur de connexions vers l'objet dans la fenêtre Interface Builder ... '') qui serait plus simple (pour moi) pour comprendre dans l'ancien code.
Bonne chance avec Qt - c'est une excellente boîte à outils, quelle que soit la façon dont vous l'utilisez, et Qt Creator semble être un excellent IDE.
la source
J'ajouterais que l'une des raisons d'utiliser le concepteur graphique était le manque de gestionnaires de mise en page dans Win32, par exemple. Seul le positionnement absolu était possible, et le faire à la main aurait été nul.
Depuis que je suis passé de Delphi à Java pour les applications GUI (en 2002), je n'ai plus jamais utilisé de concepteurs. J'aime beaucoup plus les gestionnaires de mise en page. Et oui, vous obtenez un code standard, mais le déplacement d'objets sur un concepteur d'interface utilisateur peut prendre autant de temps que de changer le passe-partout. De plus, je serais coincé avec un IDE lent; c'est pour le cas Java / C #, OK, alors que pour Qt (en particulier Qt4) cela ne s'applique pas. Pour Qt3, je me demande pourquoi on devrait éditer le code généré - n'était-il pas possible d'ajouter du code dans d'autres fichiers? Pour quelle raison?
À propos des cas discutés: 1) L'interface graphique codée à la main est probablement plus rapide à écrire, du moins si vous connaissez vos bibliothèques. Si vous êtes un débutant et que vous ne les connaissez pas, vous pouvez gagner du temps et en apprendre moins avec un concepteur, car vous n'avez pas besoin d'apprendre les API que vous utilisez. Mais "apprendre moins" est le facteur clé, donc dans les deux cas, je dirais une interface graphique codée à la main.
2) Les barres de menus sont assez ennuyeuses pour écrire du code. Pensez également aux détails tels que les accélérateurs, etc. Pourtant, cela dépend de ce à quoi vous êtes habitué. Après un certain temps, il peut être plus rapide de taper ce passe-partout que de pointer et cliquer dans le concepteur pour corriger toutes ces propriétés, mais juste si vous pouvez vraiment taper comme dans une machine à écrire (comme ces administrateurs pour lesquels taper des commandes Unix est plus rapide que en utilisant n'importe quelle interface graphique).
3) J'étendrais la réponse du cas n ° 2 à celui-ci. Notez que, pour les plates-formes Win32, il est possible que l'utilisation de concepteurs qui génèrent des ressources Win32 soit plus rapide à charger (aucune idée à ce sujet).
Cependant, j'aimerais mentionner un problème potentiel lié à l'utilisation de Qt Designer. Cas réel: il a fallu quelques secondes (disons 10) pour charger une boîte de dialogue Java complexe (la boîte de dialogue Préférences pour l'éditeur de texte d'un programmeur) avec beaucoup d'options. Le correctif correct aurait été de charger chacun des onglets uniquement lorsque le programmeur voulait les voir (j'ai réalisé cela après), en ajoutant une méthode distincte à chaque jeu de préférences pour construire son interface graphique.
Si vous concevez tous les onglets et le sélecteur d'onglets avec un concepteur, pouvez-vous le faire aussi facilement? Je suppose qu'il pourrait y avoir un exemple similaire où une interface graphique codée à la main vous donne plus de flexibilité, et dans une application aussi grande, vous en aurez probablement besoin, même si ce n'est qu'à des fins d'optimisation.
la source
L'un des principaux avantages de l'utilisation du concepteur pour créer des interfaces graphiques est que d'autres programmeurs peuvent facilement modifier ou gérer des formulaires et des widgets sans avoir besoin de se plonger dans un code complexe.
la source
C'est étrange que vous disiez que l'écriture du code est plus simple que la manipulation d'objets dans un environnement graphique. C'est une évidence.
Le concepteur est là pour vous faciliter la vie et à long terme, il rend votre code plus maintenable. Il est plus facile de regarder dans le concepteur pour voir à quoi ressemble votre interface utilisateur, puis de lire le code et d'essayer d'imaginer à quoi cela pourrait ressembler.
Avec Qt actuel, vous pouvez presque tout faire depuis le concepteur et les très peu de choses que vous ne pouvez pas faire, vous pouvez résoudre avec très peu de lignes de code dans le constructeur. Prenez par exemple l'exemple le plus simple - l'ajout d'une connexion signal-slot. Utiliser le concepteur c'est aussi simple qu'un double clic. Sans le concepteur, vous devez aller chercher la signature correcte du signal, éditer le fichier .h puis éditer écrire votre code dans le fichier .cpp. Le concepteur vous permet d'être au-dessus de ces détails et de vous concentrer sur ce qui compte vraiment: la fonctionnalité de votre application.
la source
J'aime d'abord me tourner vers le concepteur pour développer des widgets GUI. Comme mentionné dans les autres articles, c'est plus rapide. Vous obtenez également une rétroaction immédiate pour voir si cela "semble correct" et ne dérange pas l'utilisateur. Le concepteur est l'une des principales raisons pour lesquelles je choisis Qt plutôt que d'autres boîtes à outils. J'utilise principalement le designer pour créer les dialogues ponctuels.
Cela dit, je fais la fenêtre principale et tous les widgets complexes à la main. Je pense que c'est ce que voulait Trolltech. QFormLayout est une classe qu'ils fournissent pour créer facilement par programme une boîte de dialogue d'entrée.
Au fait, le concepteur de Qt 4 n'est pas un IDE comme celui qu'il avait dans Qt 3. C'est juste un éditeur pour éditer des fichiers .ui. Je l'aime comme ça. Le nouvel IDE multiplateforme s'appellera Qt Creator.
la source
C'est un vieux post mais je vous conseillerais de regarder Clementine - un lecteur de musique qui (je pense) dérive d'Amarok. Ils utilisent Qt4 et d'après ce que je peux voir, il y a un dossier ui dans le dossier src du projet. Dans le dossier ui , comme on peut s'y attendre, ils ont toutes sortes de fichiers .ui. Si vous compilez et démarrez Clementine, vous verrez que l'interface graphique est assez complexe et assez agréable.
la source
Pour moi, cela dépend de combien logique encapsulée dans le widget / GUI. S'il ne s'agit que de formulaires simples, je préfère utiliser QtDesigner.
S'il contient des contrôles ou des interactions complexes, j'ai tendance à le programmer.
la source
Nous utilisons le Qt Designer si quelqu'un a besoin de créer une interface graphique.
Le truc est de créer juste de petits Widgets pour certaines tâches (comme vous le feriez dans une conception de classe) et ensuite de les rassembler dans une "interface-mère".
De cette façon, vos widgets sont hautement réutilisables et peuvent être utilisés pour Guis de manière modulaire. Il vous suffit de spécifier les signaux envoyés par chaque widget et les emplacements qu'ils fournissent.
Nous créons également des fichiers .ui qui pourraient être générés pendant le processus de construction. Jusqu'à présent, il n'était pas nécessaire de modifier ces fichiers à la main.
la source
Créez différentes parties de votre interface utilisateur
dans différents fichiers .ui à l'aide de QtDesigner,
puis rassemblez-les (et ajoutez des complications) dans le code.
Il y a des choses que vous ne pouvez pas faire dans Qt Designer, vous ne pouvez faire que dans le code,
donc Qt Designer n'est qu'une (grande) partie de la chaîne d'outils .
la source