Codé en main GUI contre Qt Designer GUI

Question

Je passe ces jours fériés, à apprendre à écrire des applications Qt. Je lisais à propos de Qt Designer il y a quelques heures, ce qui m'a fait me demander : que faire des gens qui écrivent des applications du monde réel dans Qt utiliser pour la conception de leurs Interfaces graphiques? En fait, comment font les gens de la conception d'Interfaces graphiques en général?

Pour ma part, je trouve que le fait d'écrire le code à la main était conceptuellement plus simple que d'utiliser Qt Designer, bien que complexe, Gui Designer peut faire sens. Grand Interfaces graphiques pourrait être possible à l'aide de Designer, mais avec le temps, ils peuvent devenir très difficile à gérer que la complexité augmente (c'est juste mon avis). J'ai aussi téléchargé l'AmaroK code source afin de prendre un coup d'oeil à ce que ces gens faisaient, et a trouvé de nombreux appels à addWidget() et ses amis, mais aucun de ces fichiers XML créés par le Designer (côté: AmaroK doit être mon application favorite jamais sur n'importe quelle plateforme).

Alors, quelle est la "bonne" façon de créer une interface graphique? Le concepteur ou le code? Laissez-nous, pour cette discussion, voici les types d'Interfaces :

1. De simples boîtes de dialogue qui a juste besoin de prendre une entrée, d'afficher un résultat et de sortie. Imaginons 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 un débutant est susceptible de commencer avec.
2. Niveau intermédiaire d'Interfaces graphiques, comme, par exemple, une des notes de l'éditeur avec un peu de barre d'outils/menu. Prenons xPad par exemple (http://getxpad.com/). Je dirais que la plupart des applications de tomber dans la catégorie des "utilities".
3. Très complexe des Interfaces graphiques, comme AmaroK ou OpenOffice. Vous savez 'em quand tu vois parce qu'ils font de vos yeux saignent.

Answer 1

Notre expérience avec le Designer a commencé en Qt3.

Qt3

À ce stade, le Concepteur est utile principalement pour générer le code que vous serait alors compiler dans votre application. Nous avons commencé à utiliser, mais avec tout le code généré, une fois que vous la modifiez, vous ne pouvez plus revenir en arrière et de se régénérer sans perdre vos modifications. Nous avons terminé juste de prendre le code généré et tout faire à la main désormais.

Qt4

Qt4 s'est améliorée sur le Concepteur de façon significative. Elle n'est plus seulement de générer du code, mais vous pouvez charger dynamiquement dans votre Concepteur de fichiers (au format xml) et de se connecter dynamiquement à l'exécution des objets dans votre programme -- pas de code généré cependant, vous ne devez citer les éléments dans le Concepteur et le bâton avec les noms pour ne pas casser votre code.

Mon évaluation est que c'est nulle part près aussi utile qu'une Interface Builder sur Mac OS X, mais à ce point, j'ai pu voir en utilisant le Concepteur de fichiers directement dans un programme.

Nous n'avons pas déplacé de retour de Designer depuis Qt3, mais toujours l'utiliser pour réaliser des prototypes, et de déboguer des mises en page.

Pour vos problèmes de:

1. Vous pourriez probablement vous en sortir avec l'aide des boîtes de dialogue standard que Qt propose. QInputDialog ou si vous sous-classe QDialog, assurez-vous d'utiliser QButtonDialogBox assurez-vous que vos boutons ont la bonne plate-forme de mise en page.

2. Vous pourriez probablement faire quelque chose de plus limité comme xPad avec peu de Concepteur de fonctionnalité.

3. Je ne pense pas que vous pourriez écrire quelque chose comme OpenOffice uniquement avec le Designer, mais peut-être que ce n'est pas le point.

J'avais utilisez le Designer comme un autre outil, tout comme votre éditeur de texte. Une fois que vous trouver les limites, essayez un autre outil pour ce nouveau problème. Je suis totalement d'accord avec Steve S que l'un des avantages de Concepteur, c'est que quelqu'un d'autre qui n'est pas un programmeur peut faire la mise en page.

Answer 2

Dans mon expérience avec Qt Designer et autres boîtes à outils/UI-outils:

• L'INTERFACE utilisateur des outils d'accélérer le travail.
• L'INTERFACE utilisateur des outils de rendre plus facile d'ajuster la mise en page plus tard.
• L'INTERFACE utilisateur des outils de rendre plus facile/possible pour les non-programmeurs de travailler sur la conception de l'INTERFACE utilisateur.

La complexité peut souvent être traitée dans une INTERFACE utilisateur de l'outil en brisant la conception de l'INTERFACE utilisateur en plusieurs fichiers. De petits groupes logiques de composants dans chaque fichier et de traiter chaque groupe comme un simple widget qui est utilisé pour construire l'INTERFACE utilisateur complet. Qt Designer du concept de promu widgets peut vous aider avec ceci.

Je n'ai pas trouvé que l'échelle du projet, qui fait toute la différence. Votre expérience peut varier.

Les fichiers créés avec les outils de l'INTERFACE utilisateur (je suppose que vous pouvez les écrire à la main si vous avez vraiment voulu) peut souvent être chargés dynamiquement au moment de l'exécution (Qt et GTK+ à la fois de fournir cette fonctionnalité). Cela signifie que vous pouvez apporter des modifications de mise en page et de les tester sans avoir à recompiler.

En fin de compte, je pense que les deux premières code de l'INTERFACE et les outils peuvent être efficaces. Probablement qu'elle dépend beaucoup de l'environnement, de la trousse d'outils/de l'INTERFACE utilisateur de l'outil, et bien sûr de préférence personnelle. J'aime l'INTERFACE utilisateur d'outils car ils me lever et de courir vite, et de faciliter des changements plus tard.

Answer 3

Juste pour dire que j'ai écrit et maintenu complexe d'Interfaces graphiques avec Qt sans l'aide de 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 l'intervalle Qt, j'avais eu des expériences horribles de Dreamweaver et Frontpage et autres visuels outils HTML,et de loin préféré l'écriture de code avec HomeSite et le recours à Photoshop pour les délicats problèmes de mise en page.

Il y a un danger avec le code visuel IDEs que vous essayez de rester dans les outils visuels, mais à la fin d'avoir à bidouiller le code -- dans les moyens qui ne sont pas bien comprises.

Apprentissage, développement iPhone, par exemple, j'ai trouvé ça frustrant de frapper la "magie" des choses plus visuelles ('faites glisser le cercle vide dans les Connexions inspecteur de l'objet dans l'Interface du Générateur de fenêtre...") qui serait plus simple (pour moi) de comprendre dans la plaine de l'ancien code.

Bonne chance avec Qt, c'est une grande trousse, cependant vous l'utilisez, et Qt Creator ressemble à une grande IDE.

Answer 4

L’un des principaux avantages d’utiliser le concepteur pour créer des interfaces graphiques est qu’autres programmeurs peuvent modifier ou maintenir les formes et les widgets facilement sans avoir à se plonger dans un code complexe.

Answer 5

Je voudrais ajouter que l'une des raisons pour l'utilisation d'un concepteur graphique a été le manque de gestionnaires de disposition dans Win32, par exemple. Seul le positionnement absolu est possible, et le faire à la main, ont vient de sucer.

Depuis je suis passé à partir de Delphi Java pour les applications à interface graphique (en 2002), je n'ai jamais utilisé les concepteurs de plus. J'aime les gestionnaires de disposition beaucoup plus. Et oui, vous obtenez un code standard, mais les objets en mouvement sur un concepteur d'INTERFACE utilisateur peut prendre autant de temps que de changer le passe-partout. De Plus, je serais coincé avec une faible IDE; c'est pour le Java/C# cas, OK, alors que pour Qt (surtout Qt4) il ne s'applique pas. Pour Qt3, je me demande pourquoi on devrait modifier le code généré - n'était-il pas possible d'ajouter du code dans d'autres fichiers? Pour quelle raison?

À propos de l'examen des cas: 1) la Main Codé de l'interface utilisateur graphique est probablement plus rapide à écrire, au moins si vous savez vos bibliothèques. Si vous êtes un débutant et vous ne savez pas, vous pouvez gagner du temps et d'apprendre moins avec un designer, puisque vous n'avez pas besoin d'apprendre l'Api que vous utilisez. Mais "en savoir moins" est le facteur clé, donc dans les deux cas, je dirais que la Main Codé de l'interface graphique.

2) les barres de Menus sont assez ennuyeux à écrire du code. Aussi, pensez à des détails comme des accélérateurs et ainsi de suite. Encore, cela dépend de ce que vous êtes habitué. Après un certain temps, il peut être plus rapide de type passe-partout que de pointer-et-cliquer dans le concepteur de fixer tous ces biens, mais seulement si vous pouvez réellement de type, comme dans une machine à écrire (comme ceux des admins pour laquelle tapant des commandes Unix est plus rapide que d'utiliser l'interface graphique).

3) j'élargirai la réponse pour le cas n ° 2 à la présente. Notez que, pour les plates-formes Win32, il peut être possible qu'à l'aide de designers qui génèrent des ressources Win32 pourrait être plus rapide à charger (aucune idée à ce sujet).

Cependant, je tiens à mentionner un problème potentiel avec l'aide de Qt Designer. Cas réel: il a fallu quelques secondes (10) pour charger un complexe de Java (la boîte de dialogue Préférences pour un programmeur de l'éditeur de texte) avec un grand nombre d'options. Le bon correctif aurait été à la charge de chacun des onglets uniquement lorsque le programmeur voulait les voir (j'ai réalisé qu'après), par l'ajout d'une méthode distincte pour chaque paramètre de préférence pour construire son interface graphique.

Si la conception de tous les onglets, l'onglet sélecteur de collaboration avec un designer, vous pouvez le faire aussi facilement? Je pense qu'il y a peut-être un exemple similaire où une main codé de l'interface graphique vous donne plus de flexibilité, et dans un grand app, vous êtes susceptibles d'avoir besoin de ça, même si ce n'est pour des fins d'optimisation.