Existe-t-il une tendance pour les boîtes à outils GUI multiplateformes? [fermé]
12
Quelle est la tendance actuelle de l'utilisation des frameworks GUI multiplateformes ? Y a-t-il plus de gens qui commencent à utiliser des frameworks multiplateformes (tels que GTK +, Qt et wxWidgets) ou y en a-t-il plus qui utilisent plus de frameworks liés à la plateforme (par exemple Cocoa ou WPF)? Est-il plus ou moins stagnant? Est-ce comme une montagne russe? À votre avis, à quoi ressemblera la tendance dans 5 ans?
Le paysage du système d'exploitation évolue avec moins de personnes utilisant Windows (observation personnelle). Cela devrait augmenter la demande de boîtes à outils multiplateformes, n'est-ce pas?
Edit: De plus, quelles boîtes à outils (multiplateforme) se développent le plus, si oui?
Il semble presque qu'il y ait une tendance contre les kits multiplateformes. Si les gens veulent écrire une fois, courir n'importe où, ils ont tendance à utiliser HTML - créer un site Web. Les gens n'utilisent les boîtes à outils de la plate-forme que lorsqu'une apparence et une convivialité natives sont très demandées, par exemple sur l'iPhone. Donc, si la raison pour laquelle vous vous souciez de l'application non Web est d'obtenir une apparence et une convivialité natives, il n'est pas très logique d'utiliser un kit multiplateforme.
Les boîtes à outils multiplateformes n'ont jamais si bien fonctionné; les plates-formes de bureau ne sont pas si similaires, et il est difficile de les abstraire vraiment. L'ajout de téléphones et de tablettes au mélange rend la tâche encore plus difficile. Vous vous retrouvez avec une abstraction très fuyante (voir http://www.joelonsoftware.com/articles/LeakyAbstractions.html ). Il est souvent plus facile de bien séparer votre "moteur" de votre interface utilisateur et d'écrire l'interface séparément par plate-forme.
La tendance de Mac à être plus populaire pourrait rendre les kits multiplateformes moins populaires que plus. Je pense que souvent, les gens utilisaient un kit multiplateforme plus pour cocher théoriquement la case multiplateforme que pour obtenir de véritables bons résultats sur toutes les plates-formes. Une fois que vous vous souciez réellement de plusieurs plates-formes ... vous commencez à voir comment les kits multiplates-formes ont des inconvénients.
Je pense qu'il est révélateur que la plupart des grandes applications multiplateformes populaires inventent leur propre approche multiplateforme (Firefox, Chrome, Eclipse, OpenOffice.org sont des exemples qui me viennent à l'esprit). En étant propriétaire du cadre, ils peuvent pénétrer dans l'abstraction si nécessaire. De plus, ces applications ont toutes tendance à être identiques (et pas spécialement natives) sur toutes les plateformes.
Cela dit, je n'ai pas de statistiques réelles ou quoi que ce soit. Mais j'ai fait beaucoup de travail sur GTK + et je me suis familiarisé avec les bases de code, notamment Firefox, Chrome et Eclipse. J'ai donc vu les défis techniques ici de première main.
J'aurais formulé ceci simplement comme "La tendance pour les boîtes à outils multiplateformes est vers l'échec."
ohmantics
14
En fait, il y a eu une tendance vers une boîte à outils d'interface utilisateur multiplateforme au cours des dernières années. Cette boîte à outils est HTML / CSS / JavaScript.
Il est tellement plus simple de le développer une fois et de le voir fonctionner presque à l'identique partout.
Et oui, les développements s'éloignent massivement du bureau vers le Web. Vous le voyez vous-même.
+1 Pour le Web en tant que tendance croissante de l'interface utilisateur, mais je ne pense pas que cela réponde à la question du PO.
Entièrement d'accord. Nous développons notre application IPTV sur la box Settop entièrement en utilisant HTML5 / CSS3 / JavaScript. C'est l'avenir, pas encore un autre cadre C / C ++ massif et complet
Ernelli
1
Bonne mention, mais je suis en fait intéressé par les boîtes à outils de bureau multiplateformes . Toujours voté.
Anto
@Anto - voudrez peut-être ajouter cela à votre question. De lecture, je n'ai pas du tout ramassé sur "bureau". Bien sûr, je suis un programmeur web et je n'ai pas reconnu la plupart des frameworks que vous avez mentionnés :)
Marcie
@Anto, vous voudrez peut-être mentionner le bureau dans votre question.
JBRWilkinson
7
J'ai tendance à utiliser des kits d'outils multiplateformes parce qu'ils ont une meilleure conception, pas parce que j'essaie d'être multiplateforme. Par exemple, je travaille sur des projets écrits en C ++ ciblant uniquement la plateforme Windows. Dois-je utiliser win32 ou MFC, à peu près les seules options disponibles pour la boîte à outils native?
Saint fsck non! Ce sont à peu près les pires tas de déchets de spaghetti que j'ai jamais vus! Le couplage direct du système d'événements au système de "messages" du système d'exploitation sous-jacent est incroyablement peu intuitif et manque de l'expressivité nécessaire pour créer rapidement des programmes d'interface utilisateur. Les abstractions de niveau supérieur, actuellement uniquement fournies par des boîtes à outils multiplateformes, sont absolument essentielles à la tâche.
Ce n'est qu'un exemple aussi. Je pourrais m'attarder sur et sur la liste des choses qui sont mieux faites par les boîtes à outils multiplateformes. Le fait est que les interfaces graphiques sont plus similaires entre elles que distinctes. Il y a très peu de différence entre un programme Windows sous Windows et un sous Linux par exemple. Le genre de choses que vous faites lorsque vous créez des programmes d'interface utilisateur sont presque toujours exactement les mêmes quel que soit le système d'exploitation que vous ciblez ... et seulement des différences mineures entre les architectures comme le téléphone / palmier par rapport au bureau. Le domaine s'est tout simplement concentré sur les méthodologies multiplateformes car a) c'est nécessaire pour beaucoup de gens et b) c'est tout de même sh! T.
Un argument contre la production d'un framework multiplateforme est qu'il sera toujours ciblé sur le plus petit dénominateur commun - les clients du framework veulent écrire du code une seule fois et il s'exécute «partout» pris en charge. Donc, une plate-forme matérielle impressionnante ressemblerait à n'importe quelle autre plate-forme qui exécute ce cadre, car vous ne pouvez pas tirer parti des fonctionnalités spécifiques à la plate-forme.
Au fil du temps, cela se traduit malheureusement par des cadres se penchant vers leur plate-forme la plus populaire et piratant ensemble le support des autres plates-formes, ou tout simplement les interrompant lorsque le budget / la popularité s'épuise.
Une façon de capitaliser sur les capacités spécifiques à la plate-forme est d'avoir quelque chose comme une #if PLATFORM_FEATURE_Xconstruction autour de tout le code spécifique ou des vérifications d'exécution équivalentes, ce qui entraîne une surcharge de code. Cela devient assez fastidieux, car les variantes de la même plate-forme nécessiteront une manipulation spécifique. Par exemple, certains XBox v1 n'avaient pas de disque dur, donc les jeux utilisant des outils multiplates-formes ne pouvaient pas l'utiliser pour la mise en cache, par rapport à une version PC où vous pouvez garantir un disque dur.
Pour les applications de bureau / productivité, l'aspect et la convivialité de la plate-forme semblent être importants, mais de nombreuses applications ont leur propre style, il n'est donc pas difficile de se ressembler sur toutes les plates-formes, par exemple les applications conçues avec AIR.
Les fournisseurs de matériel comme Apple, Sony, Nintendo et Toshiba voudront s'assurer que leurs produits se démarquent de la concurrence, par exemple tactile, accéléromètres / gryoscopes, Blu-Ray, écran 3D. Il est peu probable qu'il y ait jamais une plate-forme avec toutes les fonctionnalités de tous les concurrents réunies en une seule (en raison du coût et de la complexité), donc une gagnera.
En fait, il y a eu une tendance vers une boîte à outils d'interface utilisateur multiplateforme au cours des dernières années. Cette boîte à outils est HTML / CSS / JavaScript.
Il est tellement plus simple de le développer une fois et de le voir fonctionner presque à l'identique partout.
Et oui, les développements s'éloignent massivement du bureau vers le Web. Vous le voyez vous-même.
la source
J'ai tendance à utiliser des kits d'outils multiplateformes parce qu'ils ont une meilleure conception, pas parce que j'essaie d'être multiplateforme. Par exemple, je travaille sur des projets écrits en C ++ ciblant uniquement la plateforme Windows. Dois-je utiliser win32 ou MFC, à peu près les seules options disponibles pour la boîte à outils native?
Saint fsck non! Ce sont à peu près les pires tas de déchets de spaghetti que j'ai jamais vus! Le couplage direct du système d'événements au système de "messages" du système d'exploitation sous-jacent est incroyablement peu intuitif et manque de l'expressivité nécessaire pour créer rapidement des programmes d'interface utilisateur. Les abstractions de niveau supérieur, actuellement uniquement fournies par des boîtes à outils multiplateformes, sont absolument essentielles à la tâche.
Ce n'est qu'un exemple aussi. Je pourrais m'attarder sur et sur la liste des choses qui sont mieux faites par les boîtes à outils multiplateformes. Le fait est que les interfaces graphiques sont plus similaires entre elles que distinctes. Il y a très peu de différence entre un programme Windows sous Windows et un sous Linux par exemple. Le genre de choses que vous faites lorsque vous créez des programmes d'interface utilisateur sont presque toujours exactement les mêmes quel que soit le système d'exploitation que vous ciblez ... et seulement des différences mineures entre les architectures comme le téléphone / palmier par rapport au bureau. Le domaine s'est tout simplement concentré sur les méthodologies multiplateformes car a) c'est nécessaire pour beaucoup de gens et b) c'est tout de même sh! T.
la source
Un argument contre la production d'un framework multiplateforme est qu'il sera toujours ciblé sur le plus petit dénominateur commun - les clients du framework veulent écrire du code une seule fois et il s'exécute «partout» pris en charge. Donc, une plate-forme matérielle impressionnante ressemblerait à n'importe quelle autre plate-forme qui exécute ce cadre, car vous ne pouvez pas tirer parti des fonctionnalités spécifiques à la plate-forme.
Au fil du temps, cela se traduit malheureusement par des cadres se penchant vers leur plate-forme la plus populaire et piratant ensemble le support des autres plates-formes, ou tout simplement les interrompant lorsque le budget / la popularité s'épuise.
Une façon de capitaliser sur les capacités spécifiques à la plate-forme est d'avoir quelque chose comme une
#if PLATFORM_FEATURE_Xconstruction autour de tout le code spécifique ou des vérifications d'exécution équivalentes, ce qui entraîne une surcharge de code. Cela devient assez fastidieux, car les variantes de la même plate-forme nécessiteront une manipulation spécifique. Par exemple, certains XBox v1 n'avaient pas de disque dur, donc les jeux utilisant des outils multiplates-formes ne pouvaient pas l'utiliser pour la mise en cache, par rapport à une version PC où vous pouvez garantir un disque dur.Pour les applications de bureau / productivité, l'aspect et la convivialité de la plate-forme semblent être importants, mais de nombreuses applications ont leur propre style, il n'est donc pas difficile de se ressembler sur toutes les plates-formes, par exemple les applications conçues avec AIR.
Les fournisseurs de matériel comme Apple, Sony, Nintendo et Toshiba voudront s'assurer que leurs produits se démarquent de la concurrence, par exemple tactile, accéléromètres / gryoscopes, Blu-Ray, écran 3D. Il est peu probable qu'il y ait jamais une plate-forme avec toutes les fonctionnalités de tous les concurrents réunies en une seule (en raison du coût et de la complexité), donc une gagnera.
la source