Quels sont les inconvénients du module Perl Tk?

Question

Quels sont les inconvénients du module Tk par rapport aux autres solutions pour créer une interface graphique en Perl?

Answer 1

J'ai récemment visité les différents modules de gui pour Perl, et voici mon résumé (avertissement: finalement, aucun des modules existants ne répondait à mes besoins, j'ai donc commencé à écrire ma propre boîte à outils gui).

Tk - Décent de travailler avec et l'interface est très perlish. Le gui lui-même est un peu daté, et ne tire parti d'aucun des widgets natifs du système d'exploitation (comme les fichiers). Sur la plupart des systèmes, il faudra installer un compilateur C.

Wx - Difficile de travailler avec, interface non-perlish. Les grands programmes exigent presque un constructeur de gui pour garder la trace de tout. La prise en charge des widgets au niveau de l'os est mixte. Plus beau que Tk IMO. Compilation est impliqué, nécessite l'installation de plusieurs bibliothèques, peut être difficile à exécuter sur les fenêtres. L'assemblage de programmes est très procédural et ne correspond pas exactement à ce à quoi ressemblera le programme. Qt - dernier que j'ai regardé ce module a été plus ou moins abandonné et ne supporte que Qt3. Je n'ai pas essayé de l'installer, mais j'imagine qu'il a besoin d'un compilateur.

Prima - Similaire à Tk il a une apparence datée. Nécessite un compilateur.

W32 :: GUI - Je l'ai écarté tôt car il n'est pas multi-plateforme. XUL :: Node/POE :: XUL :: Node - arbre de dépendances plutôt lourd qui inclut le code C. Semble pas maintenu et j'ai eu des expériences mélangées pour l'installer. Windows était un pas, OSX était un non, il avait des fonctionnalités limitées sur OpenSUSE. Il ne prend également en charge qu'un sous-ensemble du langage XUL.

J'ai constaté qu'aucun des kits d'outils graphiques existants ne permettait de distribuer facilement votre application aux utilisateurs finaux. Il est permis de s'attendre à ce que les programmeurs sautent entre les étapes de la résolution des dépendances de la bibliothèque et de la compilation du code, mais les utilisateurs finaux ne le feront pas. Donc, la première exigence que j'avais était d'être pur Perl. Deuxièmement, presque tous les outils graphiques existants vous obligent à travailler de manière très procédurale: Créez un conteneur. Créez un packer pour le conteneur. Créer un objet Définissez les propriétés sur cet objet. Ajouter l'objet à l'emballeur. Exécutez le packer pour remplir l'objet conteneur. Répéter. Au lieu de cela, je trouve que la conception imbriquée (comme HTML) est plus facile à suivre pour deux raisons. Tout d'abord, puisque les objets sont imbriqués, il n'est pas nécessaire de tout nommer (label_456, label_457 ...). Deuxièmement, la structure du programme reflète la structure de ce qui est affiché.

J'ai donc commencé à travailler sur XUL::Gui, et ça a plutôt bien marché. C'est un Perl pur, et ne dépend que des modules de base pour faciliter l'installation. Il a une exigence externe, à savoir qu'une copie récente (3+) de Firefox est installée. Il utilise le modèle de conception familier du développement web avec des balises imbriquées avec CSS. Il est certainement à un niveau où vous pouvez écrire des applications à guichet unique entièrement équipées avec elle.

Espérons que cela vous aide à déterminer quelle boîte à outils est la meilleure pour votre projet.

Answer 2

Tk n'a pas été développé depuis très longtemps. ActiveState recommande maintenant le développement avec leur boîte à outils Tkx, qui fournit une couche mince sur TclTk. Cela signifie que les widgets à thème sont possibles. Mais, TclTk est encore assez primitif par rapport à de nombreux autres toolkits GUI.

Je n'ai pas essayé XUL: Gui mais il me semble que c'est le chemin à parcourir.