Pourquoi est-il difficile de faire apparaître un programme Java natif)?
La plupart des applications Java Java ne ressemblent pas aux applications C/C++. Swing a peut-être été conçu exprès pour avoir un aspect distinctif, mais d'après ce que j'ai lu, SWT a par exemple essayé à "paraître natif", et ne réussit pas complètement.
Ma question est:
Pourquoi est-il difficile pour les développeurs du langage Java Java de concevoir un système d'interface graphique qui copie exactement l'apparence des interfaces graphiques natives? Qu'est-ce qui est différent dans les interfaces graphiques natives? N'est-ce pas il s'agit simplement de concevoir des boutons qui ressemblent à des boutons "natifs"? Ou est-ce que ça va plus loin que ça?
Ne s'agit-il pas seulement de concevoir des boutons qui ressemblent à des boutons "natifs"?
Eh bien, en quelque sorte, pour les boutons. Mais cela pourrait être plus difficile que vous ne l'imaginez. De nos jours, les graphiques utilisés pour représenter les composants de l'interface graphique ne sont pas aussi simples que des bitmaps aléatoires qui sont étirés (car ils ne sont pas très bien mis à l'échelle) - ce sont souvent des graphiques vectoriels avec de nombreux cas d'angle programmés ( ainsi, lorsque le bouton atteint le bord de l'écran, il peut sembler légèrement différent, par exemple.) Et bien sûr, vous aurez besoin de graphiques différents lorsqu'un bouton est cliqué. Pour des raisons de droits d'auteur, les développeurs ne peuvent souvent pas simplement utiliser ces graphiques existants, ils doivent donc être recréés - et bien qu'ils fassent du bon travail pour la plupart, inévitablement certaines choses sont manquées compte tenu de la vaste gamme de composants graphiques disponibles. C'est beaucoup moins grave qu'auparavant - de nos jours, si je définis l'apparence et la convivialité de la plate-forme par défaut dans Swing, je remarque très peu de choses qui semblent étranges.
Je dis tout ce qui précède basé sur Swing, qui est bien sûr une boîte à outils GUI légère et non native. Vous mentionnez spécifiquement SWT qui ne semble pas natif, ce qui est un peu étrange, car SWT est natif. C'est une boîte à outils qui utilise JNI en dessous pour appeler des composants natifs - donc si quelque chose ne semble pas juste là, ce n'est pas va être à cause de l'apparence.
Il existe littéralement une demi-douzaine de boîtes à outils qui pourraient être considérées comme "natives" sur certains systèmes. Certains d'entre eux ont des concepts ou des capacités plutôt uniques, et les reproduire dans une boîte à outils multiplateforme est fastidieux. L'aspect et la convivialité d'une application ne sont pas seulement déterminés par un "habillage", mais également par la mise en page et son comportement. Quelques considérations:
- Dans une boîte de dialogue, de quel côté appartient le bouton "OK" - à gauche ou à droite? Assez juste, construisons une boîte de dialogue distincte pour chaque système.
- Comment marquer le bouton par défaut sur un écran? Teinte de couleur, police en gras, agrandissement du bouton? Très bien, mettons cela dans une feuille de style.
- Sous Windows, le concept de "ruban" est plutôt natif. Comment cela serait-il traduit sur Mac, où le ruban n'est pas courant? Assez juste, oublions la disposition au pixel près et fournissons une implémentation de barre d'outils différente pour chaque système.
- La barre de menus fait-elle partie de la fenêtre (Windows, éventuellement KDE) ou est-elle située en haut de l'écran (Mac, Unity)? Assez juste, écrivons une implémentation différente pour chaque système, car nous avons déjà jeté la disposition exacte en pixels
- Comment les polices sont-elles rendues? Aussi net que possible, ou lisse et anti-crénelé? Et quelle police utiliser? Notez que les polices différentes ont des mesures différentes, donc le même paragraphe rendu à la même largeur peut avoir un nombre différent de lignes selon la police.
- L'arrière-plan d'une fenêtre est-il une seule couleur, une image ou un dégradé? Mettons cela aussi dans une feuille de style.
- À quoi ressemblent les barres de défilement? Où sont les boutons - s'ils en ont? Quelle est leur largeur, ou ne sont-ils révélés que lorsque le pointeur se déplace dans une certaine région?
- Comment incorporons-nous d'autres schémas de couleurs?
- Qu'est-ce qui devrait être déplaçable? Où les menus contextuels sont-ils attendus?
Ces problèmes ne peuvent pas être résolus via une simple feuille de style lorsqu'ils concernent le comportement ou la disposition générale de l'application. La seule vraie solution consiste à réécrire l'application pour chaque système (ignorant ainsi les avantages multiplateformes de Java). La seule solution réaliste consiste à oublier la disposition exacte en pixels et à écrire dans une interface commune qui résume par-dessus des boîtes à outils spécifiques au système. La solution adoptée par Swing consiste à émuler divers systèmes, ce qui échoue de façon spectaculaire.
Et puis il y a la cohérence multiplateforme, l'idée que votre application peut être exactement la même sur tous les systèmes (souvent choisis par les jeux, où cela augmente l'immersion). Sur les applications de bureau, cela est juste ennuyeux et brise les attentes des utilisateurs.
Oui, cela va plus loin.
Construire un bouton qui ressemble à un bouton Windows ou OS X est facile, lorsque vous créez uniquement ce bouton. Mais le bouton doit "se comporter" comme les originaux, ce qui n'est peut-être pas facile: peut-être qu'il y a plus d'espace dans une version disponible, mais pas dans l'autre, peut-être que la couleur est plus adaptée à votre conception dans la version Windows, etc.
Ceci est exagéré lorsque vous avez une interface graphique entière: un programme OS X présente son contenu différemment d'un programme Windows. C'est presque impossible à capturer dans une seule interface graphique - vous auriez besoin de deux interfaces graphiques, mais peu d'applications font autant de bruit. Au lieu de cela, ils visent "un aspect correct sur la plupart des systèmes" - cela semble toujours un peu étranger, mais est utilisable et beaucoup plus facile à développer.
Il n'est pas difficile de créer un bouton qui ressemble à un bouton OSX, ou à un bouton Windows, ou à celui de toute autre boîte à outils. Mais les directives de l'interface utilisateur pour la plupart des environnements ne sont pas aussi simples que les bases de "voici à quoi ressemble un bouton". Il existe de nombreuses différences plus subtiles, de l'espacement entre les éléments de l'interface utilisateur à l'ordre dans lequel certaines actions bien connues doivent apparaître dans une liste jusqu'à la position exacte de la boîte de dialogue Préférences/Options dans le système de menus. On peut automatiser les cas les plus courants pour des interfaces utilisateur très simples, mais beaucoup, sinon la plupart des tâches d'interface utilisateur nécessitent une touche beaucoup plus fine.
SWT a essayé d'automatiser cela dans une certaine mesure, et encore une fois, il le fait pour les tâches d'interface utilisateur simples. Mais il n'y a pas de solution universelle, et donc lorsque les interfaces utilisateur deviennent plus complexes, les méthodes de base qu'elles utilisent commencent à s'effondrer. Il est généralement possible de le remettre en conformité avec un travail manuel minutieux de l'interface utilisateur, mais ce n'est pas quelque chose que la plupart des programmeurs sont capables ou désireux de faire pour toutes les plates-formes.
L'approche de Swing à cet égard consistait simplement à éviter les boîtes à outils natives dans la mesure du possible. Ce n'est pas natif, et il n'essaie pas de l'être: au lieu de cela, il essaie de créer quelque chose qui aura (presque) la même apparence, peu importe où il est exécuté. Plutôt que d'essayer (vainement) de plaire à tout le monde, il a essayé de se plaire, et même s'il a réussi dans la mesure du possible, on peut se demander dans quelle mesure le résultat est efficace pour la communauté plus large d'utilisateurs.
Il existe un compromis entre le fait d'attendre que votre application soit aussi naturelle que possible sur chaque système et de vous attendre à ce que votre application fonctionne de la même manière sur chaque système. Il n'y a pas de "bon" choix.
De plus, même si vous choisissez le côté "naturel", vous souhaiterez peut-être protéger les utilisateurs de votre boîte à outils graphique contre les "améliorations" des composants natifs sous-jacents et de l'API qui pourraient interrompre leur application de manière inattendue.
C'est pourquoi certains développeurs de boîtes à outils GUI préfèrent fournir leurs propres composants qui imitent les composants natifs, mais fournissent leur propre implémentation. D'autre part, le développement d'une boîte à outils GUI fonctionnellement complète est un effort important et des considérations économiques peuvent conduire à couper quelques bords.
Notez que ce problème n'est pas Java spécifique, mais il est rencontré par toutes les sociétés produisant des boîtes à outils indépendantes de la plate-forme.
Tout est dû à l'histoire.
Sun souhaitait que tous les logiciels [Java fonctionnent de la même manière sur toutes les machines.
Pour que le logiciel "apparaisse natif", il doit fonctionner de la même manière que les autres logiciels sur le système d'exploitation donné.
Sun a fait tout ce qui était en son pouvoir pour rendre difficile l'écriture de Java logiciels intégrés dans un système d'exploitation, car toute intégration avec un système d'exploitation ferait fonctionner le logiciel différemment sur chaque système d'exploitation.
De nos jours, très peu de programmeurs Java se soucient d'autre chose que des logiciels basés sur un serveur Web.
Sun a tué Java sur le bureau en dérivant tous les programmeurs qui utilisaient les systèmes basés sur Microsoft Java, rendant ainsi mauvais tout programmeur qui choisissait Java au début.
Quiconque écrit un logiciel de bureau qui se soucie de "paraître natif" a appris il y a longtemps à ne pas utiliser Java et voit sa position renforcée à chaque fois qu'il utilise un logiciel Oracle.
Par conséquent, de nos jours, les programmeurs Java ne demandent pas "d'apparaître natif" sur le logiciel de bureau.
Ce que vous pensez est que native est en fait des applications natives qui font leur propre chose tandis que des kits d'outils comme SWT suivent les normes publiées pour l'interface utilisateur de ce système d'exploitation. Le problème est que personne ne crée des applications suivant ces normes, donc lorsque vous lancez une application Java. Elle ne semble pas native. Par exemple, presque tous les projets de Microsoft (Office, Outlook, etc.) ne peut pas être reproduit visuellement à l'aide des commandes standard de Windows.
Cela va encore empirer car Microsoft et Apple ajoutent des fonctionnalités d'interface utilisateur dynamique à leurs plates-formes de système d'exploitation.
Java sur la plate-forme Android suit ce chemin. Création des éléments d'interface utilisateur pour Android définis en XML avec des styles skinnables).
Java n'a jamais été très populaire comme plate-forme de bureau. En conséquence, ces changements dans l'industrie ne se propagent pas aux runtimes de bureau. Il n'y a tout simplement pas assez de développeurs prêts à consacrer du temps à résoudre le problème.