Tu dis qu'on ne peut plus coder dedans, mais, j'imagine que ça implique que l'on peut lier "mécaniquement" une boîte de dialogue à un contrôle?
J'ai un peu de mal à comprendre ta question.
Le .cpp généré en fonction du .ui décrit une nouvelle classe qui contient autant de propriétés qu'il y a de widgets dans le formulaire et ces propriétés sont nommées en fonction du nom qu'on leur affecte dans Qt Designer.
Pour bien séparer les choses, cette classe générée appartient à un namespace Ui.
La liaison entre le code "IHM" généré (via le .cpp généré) et ton code à la main à toi est faite soit via de l'encapsulation en instanciant une propriété de type la classe générée, soit de l'héritage multiple en déclarant une classe de même type que le widget décrit sous designer et en seconde classe la classe Ui.
La seconde question porte sur le fait du travail supplémentaire impliqué par ce type d'outil.
J'ai constaté que régulièrement, quand on modifie un truc dans le code, soit ça pourrit le RAD, soit le RAD l'écrase ensuite, quand on y retourne pour modifier un truc. Même combat ici, ou …?
Du point de vue de la conception, tu ne peux rien écraser dans quel sens que ce soit : si tu modifies ton .ui avec Qt Designer, la seule chose que tu vas écraser, c'est le .cpp généré correspondant, mais celui-ci de toute façon, ne doit impérativement jamais être modifié à la main. Ton code ui "manuel" à toi est lui bien séparé dans d'autres fichiers cpp.
En bref, le système d'Ui de Qt intervient en amont et est généralement additif ; une fois utilisé au sein d'une application, la seule chose qui reste à faire au runtime une fois que la classe Ui est instanciée, c'est d'ajouter manuellement ce qui pourrait manquer (l'exemple de la grille de bouton de chiffres dans une calculatrice dont on aurait "qt désigné" tout le reste (boutons spéciaux, écran LCD, etc)), ou bien à la rigueur de cacher des objets issus des .ui. Il est très rare d'avoir à supprimer des composants d'une classe issue d'un .ui.
J'ai longtemps fait du Delphi au boulot et je peux te dire que la propreté de Qt à ce niveau là a vraiment été une bouffée d'oxygène pour moi.
[^] # Re: En ce qui concerne les applications...?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Enlightenment DR17 est enfin sorti !. Évalué à 5.
J'ai un peu de mal à comprendre ta question.
Le .cpp généré en fonction du .ui décrit une nouvelle classe qui contient autant de propriétés qu'il y a de widgets dans le formulaire et ces propriétés sont nommées en fonction du nom qu'on leur affecte dans Qt Designer.
Pour bien séparer les choses, cette classe générée appartient à un namespace Ui.
La liaison entre le code "IHM" généré (via le .cpp généré) et ton code à la main à toi est faite soit via de l'encapsulation en instanciant une propriété de type la classe générée, soit de l'héritage multiple en déclarant une classe de même type que le widget décrit sous designer et en seconde classe la classe Ui.
Du point de vue de la conception, tu ne peux rien écraser dans quel sens que ce soit : si tu modifies ton .ui avec Qt Designer, la seule chose que tu vas écraser, c'est le .cpp généré correspondant, mais celui-ci de toute façon, ne doit impérativement jamais être modifié à la main. Ton code ui "manuel" à toi est lui bien séparé dans d'autres fichiers cpp.
En bref, le système d'Ui de Qt intervient en amont et est généralement additif ; une fois utilisé au sein d'une application, la seule chose qui reste à faire au runtime une fois que la classe Ui est instanciée, c'est d'ajouter manuellement ce qui pourrait manquer (l'exemple de la grille de bouton de chiffres dans une calculatrice dont on aurait "qt désigné" tout le reste (boutons spéciaux, écran LCD, etc)), ou bien à la rigueur de cacher des objets issus des .ui. Il est très rare d'avoir à supprimer des composants d'une classe issue d'un .ui.
J'ai longtemps fait du Delphi au boulot et je peux te dire que la propreté de Qt à ce niveau là a vraiment été une bouffée d'oxygène pour moi.