Comment puis-je Retrofit une interface graphique à un programme C existant?
https://stackoverflow.com/questions/385156
-
23-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je travaille sur un projet de portage d'un ancien programme CL solaris pour fonctionner sur Linux, et sauf quelques problèmes matériels non liés, qui est fini. Maintenant, je veux une interface graphique pour elle, afin que l'utilisateur peut choisir parmi les différentes options avec menus déroulants et des cases à cocher, ainsi que des zones de saisie de texte pour les options qui ne sont pas si restreint, comme le nom du fichier. (Le programme est un outil interne pour exécuter certains spectroscanners et stocker les résultats sous forme de fichiers CSV Il gère toutes ces options, exécute les scanners et traite les informations et les stocke avec le nom de fichier spécifié,. Je veux juste quelque chose plus agréable à utiliser que CL. )
La seule fois que je l'ai vu quelque chose comme ça fait était une interface graphique PyGTK + avec les liaisons python pour le code C (je pense que ce qu'il était, ce fut mon premier semestre co-opping et je ne comprenais pas très bien! ). C'est un peu plus que ce que je veux en ce moment; est-il un moyen relativement facile de le faire? Quand je googlé j'ai trouvé SWIG ( http://www.swig.org/index.php ) ; est-ce une bonne façon d'aller?
La solution
Cela ressemble exactement le travail Tcl / Tk a été conçu pour. Il dispose d'une API C très simple qui vous permet d'enregistrer les commandes avec un rappel. Si vous utilisez la commande dans un programme Tcl, il appellera la fonction de rappel et de fournir un mécanisme permettant de convertir les arguments entre une liste Tcl (structure de données native) et un tableau de style argv char *.
Il a été spécialement conçu pour être facile à moderniser ce type d'emballage pour commander en ligne des programmes conduits C. Il existe également une variété d'autres modes que vous pouvez utiliser pour interfacer l'interprète ainsi, et il est facile d'intégrer dans les programmes comme un langage de script. De mémoire les mécanismes disponibles sont interfaçant:
- enregistrer les commandes dans le Tcl interprète
- Intégrer un interpréteur Tcl dans votre programme et utiliser Tcl comme embedded langage de script (éventuellement y compris l'enregistrement des commandes et callbacks à votre programme)
- lancer un processus avec un tuyau full-duplex et envoyer des commandes via stdin / stdout (vous pouvez également joindre un gestionnaire d'événements pour le tuyau qui est invoqué lorsque les données sont disponibles)
- Moins Tcl mécanismes spécifiques tels que Fourche / exec ou d'une connexion par l'intermédiaire des douilles.
Le livre de Ousterhout Tcl et TK Toolkit est un peu vieillot mais a un bon guide pour l'API C. Welch Programmation pratique Tcl / Tk est l'autre livre Tcl / Tk classique est mis à jour plus fréquemment. Il y a aussi plusieurs autres livres et beaucoup de ressources électroniques sur Internet. Quelques bons points de départ sont: Tcl tutoriel , tutoriel TK , Stackoverflow .
TK vous donnera une interface graphique simple et est très facile à apprendre à programmer - si un peu simpliste. Il n'est pas aussi laid comme il l'habitude d'être si vous prenez un peu de temps à < a href = "https://stackoverflow.com/questions/349409/why-are-tk-guis-considered-ugly#349792"> modifier apparence ou d'utiliser un moteur de thématisation comme Mosaïque.
Norman Ramsey souligne (1) , une autre alternative avec une API simple C est Lua. Les deux ont des avantages et désavantages. Les principaux points forts de Tcl sont la boîte à outils TK simple et proprement intégré et bon, le soutien de soutien des bibliothèques matures tiers (par exemple Tix ). La principale force de Lua est que la langue est beaucoup plus agréable, mais il n'y a pas de boîte à outils GUI standard, l'interface utilisateur est pas aussi bien intégré. Lua a également beaucoup meilleur soutien pour enfiler dans l'interpréteur, ayant été conçu pour cela à partir du sol. Cependant, si vous enroulant un héritage application C / unix, il est peu probable d'être une caractéristique importante.
wxwidgets est beaucoup plus complexe que TK et porte bagage plus d'exécution, mais a un jeu de fonctions plus riche.
Sivous avez une véritable raison de penser que votre projet de script se développera dans une application plus large que vous pourriez envisager Lua. Cependant, à plus grande échelle que vous êtes dans un projet de développement important et Python ou Ruby commencent à devenir des options viables. Comme le projet est plus enveloppant le C codebase sera une plus petite partie du support de bibliothèque de projet dans son ensemble et un tiers sera une plus grande considération.
Si vous allez avec Tcl et de découvrir votre projet obtient une vie propre, envisager d'intégrer l'interpréteur Tcl et Réaménager l'application comme une API de plug-in que les gens peuvent accrocher leurs propres scripts dans. Des fonctionnalités supplémentaires peuvent être réalisées sous forme de scripts et peut-être refilé à des tiers pour l'entretien. L'un des avantages d'un système avec un langage de script intégré est que vous ne personnellement pas nécessairement à mettre en œuvre des fonctions. Les gens peuvent écrire leurs propres extensions dans le langage de script ou d'obtenir des tiers de le faire pour eux.
SWIG est conçu pour générer des wrappers autour des bibliothèques. Il analyse les fichiers d'en-tête et génère une couche de colle qui présente une API native dans la langue cible. Pour l'utiliser, vous devez re-facteur votre programme dans une bibliothèque.
Autres conseils
Comme d'autres l'ont dit, Tcl / Tk est un bon choix. Il y a un risque réel vous dépasser la croissance du langage Tcl , mais ce risque est atténué par l'excellent puissance et la simplicité de la boîte à outils de fenêtrage Tk .
L'autre choix que je considérerais est wxlua . Les raisons sont que Lua est une langue que vous voulez pas trop grand pour . Vous pouvez aussi préférer wxlua parce qu'il est basé sur wxWidgets , qui vous donnera une interface graphique apparence native et se sentent . Le look original Tk avait un peu étrange et très non indigènes et sentir, mais les choses sont beaucoup mieux maintenant, cette raison ne peut pas porter beaucoup de force. Vous pouvez regarder au cours des deux boîtes à outils de l'interface graphique pour voir ce qui fait appel. Une dernière raison, vous préférerez peut-être Lua est que il est plus facile d'exposer les types de données définis par l'utilisateur à l'interface graphique et les scripts.
Je ne voudrais pas envisager d'autres solutions telles que Python et GTK +, en raison de toutes les alternatives là-bas, ne Tcl et Lua ont été conçus dès le départ pour se marier à des programmes C .
Vous aussi poser des questions sur SWIG . Bien qu'il soit superficiellement attrayante, je recommande l'éviter. Tcl et Lua ont très simples API C et vous en apprendrez plus, mieux comprendre, et être meilleur contrôle de votre application si vous apprendre à utiliser l'API native vous au lieu d'avoir le code générer SWIG pour vous.
Je l'ai utilisé tcl / tk pour envelopper les petits programmes CLI avant et il fonctionne souvent très bien pour commencer.
tcl / tk est un langage de script / package qui appellerez et analyse la sortie CLI afin que vous ne devez pas écrire un nouveau programme
Que diriez-vous Tcl / Tk .. beaucoup de ressources .. telles que cette
Je dois deuxième Tcl / Tk. Je l'ai fait exactement la même chose pour les programmes existants en Fortran / C / C ++. Comme il est très trivial d'écrire un DSL en Tcl / Tk, je fini par simple ajout d'une option pour que le programme DSL de sortie (essentiellement des commandes Tcl écrites dans procs) pour le programme de tk à eval. Je l'ai fait pour un programme pour faire des animations graphiques assez complexes sur une toile tk, qui a des options pour sauver la partie de l'animation en mpeg en 4 heures environ. Les gens ont été surpris. Il est tout à fait portable aussi bien. Tcl / Tk a événement simple, sophistiqué installations entraîné (qui est encore inégalée dans sa simplicité) pour écrire des applications GUI. Vous pouvez utiliser un tuyau simple à l'interface avec les programmes existants aussi longtemps qu'il peut lire sur l'entrée standard et écrire sur la sortie standard.
L'énorme avantage de cette approche est que vous n'avez pas besoin de lier une interface graphique ou des bibliothèques supplémentaires avec vos programmes existants, ce qui est parfois impossible. Le programme GUI et héritage peut être complètement découplé.
Et voilà il y a environ 10 ans. Tk a évolué / beaucoup amélioré depuis et a gagné apparence native et se sentent la capacité.
L'inconvénient majeur utilisé à des programmes d'emballage standard autonome Tcl / Tk, qui est en grande partie résolu maintenant aussi bien.
EDIT: DSL signifie 'Domain Specific Language' Extensions à l'interpréteur Tcl se manifestent en tant que nouveaux mots clés du langage. Tcl a une syntaxe assez basique, donc ce mécanisme permet beaucoup de possibilités d'extension de la langue. Un bon exemple d'une application qui fait avec Tcl est Expect.
Toute boîte à outils ou un cadre peut résoudre votre problème puisque vous demandez une interface utilisateur qui agit comme un wrapper pour votre exécutable en ligne de commande. Vous pouvez choisir C #, MFC, VB6, tout outil que vous voulez. Les langages .NET tels que C # sont assez faciles pour les emballages de l'interface utilisateur de ligne de commande. wxWidgets, Qt ou Édition Intégrale ++ peuvent vous aider si vous voulez le faire en C ++.
Si vous savez comment programmer en C, vous pouvez le faire dans l'API Win32 simple, barbante vous devez gérer certaines choses qui sont traitées automatiquement dans les cadres C +.
Vous pouvez utiliser une boîte à outils que vous aimez (tcl / tk ou tout autre langage de script que vous êtes à l'aise avec qui a une capacité de GUI), mais les conseils de garder l'original en tant que programme CLI (que votre interface exécute ensuite après avoir recueilli les options de l'utilisateur) est bon. Pas besoin d'entrer dans les liaisons C etc.
Sans entrer dans les bibliothèques ou recommander des boîtes à outils GUI spécifiques, ne soyez conscient que la plupart des interfaces graphiques fonctionnent sur un modèle « event driven ».
Cela signifie que la plupart du temps l'application est en train de faire quelque chose comme ceci:
- attendre un événement (par exemple d'entrée du clavier, minuterie d'expiration, etc.)
- appeler une fonction spécifiée par l'utilisateur en fonction de cet événement
- boucle de retour à l'étape 1.
Si la fonction est appelée prend beaucoup de temps, il rend votre programme ne répond pas.
Travailler autour de ce moyen soit d'avoir votre interface graphique traitée dans un autre thread, ou la capacité des fonctions à long terme pour produire de temps en temps pour vérifier si l'utilisateur a essayé de les abandonner.
Je pense que MGUI est une chose que vous pouvez aller avec!
MGui (MORELLO Graphic User Interface) est une interface utilisateur graphique multi-plateforme écrit en ANSI C, en fournissant également une API C ++ via une bibliothèque d'images. Il se compose d'une bibliothèque, y compris tous les objets GUI typiques comme menu, boutons, champs modifiables, listes, etc ... et un outil de génération de code (MGui Designer), qui permet à l'utilisateur de créer et de maintenir la disposition des fenêtres d'application à l'aide de la souris.
MGui permet de créer des applications pour Windows 3.1, Windows 95/98 / NT, Unix X-Window, DOS (Borland, Watcom et DJGPP) avec aucune connaissance sur l'API graphique du système hôte. Vous pouvez simplement utiliser le générateur de code Designer MGui pour créer la disposition des fenêtres, et écrivez votre code pour interagir avec les objets créés.
Pour ses caractéristiques, MGui est utile à tous ceux qui veulent réaliser des applications multiplateforme, sans aucun besoin de portage de l'interface graphique. Il est idéal pour une utilisation dans les systèmes embarqués DOS en mode réel et tant DPMI.
