Pourquoi est-il difficile de faire apparaître un programme Java "natif"?

98

La plupart des applications Java ne ressemblent pas aux applications C / C ++. Swing a peut-être été conçu exprès pour avoir un look distinctif, mais sur la base de ce que j'ai lu, SWT, par exemple, a essayé de «paraître natif» et n'a pas réussi.

Ma question est:

Pourquoi est-il difficile pour les développeurs du langage Java de concevoir un système d’interface graphique qui copie exactement l’aspect des interfaces graphiques natives? Qu'est-ce qui est différent dans les interfaces graphiques natives? N’est-ce pas seulement une question de concevoir des boutons qui ressemblent à des boutons «natifs»? Ou va-t-il plus profond que cela?

utilisateur3150201
la source
31
parce que swing écrit ses propres composants d'interface graphique qui tentent d'imiter le natif, au lieu de créer une liaison avec les composants natifs, dans l'idée de la portabilité
fratchet freak
5
Je ne suis pas un expert en la matière, mais j’imagine que c’est une question de savoir combien d’efforts les fournisseurs de la boîte à outils de l’interface graphique sont prêts à investir pour obtenir tous les détails sanglants. Voir, par exemple, le cadre C ++ "Qt" et cette question SO: stackoverflow.com/questions/7298441/…
Doc Brown du
4
Il y a beaucoup de détails à prendre en compte. Par exemple, la manière dont l'auto-complétion fonctionne dans une boîte de dialogue d'ouverture de fichier est l'un des points où une application Java d'apparence native est tombée en panne.
CodesInChaos
4
Swing a un aspect similaire à celui que vous pouvez vous connecter au lieu de celui par défaut. En outre, Java a d’abord essayé d’utiliser les éléments natifs disponibles avec AWT, mais cela ne fonctionnait pas très bien, autant que je sache, en raison des différences inhérentes entre les plateformes. C'est pourquoi ils ont créé Swing, de sorte qu'une application Java fonctionne exactement de la même manière partout.
Marczellm
5
Ne négligez pas JavaFX. Il s'agit du remplacement de SWING et se trouve dans le JDK / JRE par défaut à partir de Java 8. Il est beaucoup plus moderne que SWING et AWT et semble beaucoup plus natif sur à peu près toutes les plates-formes (il est très étroitement lié au Plate-forme). Cela dit, comme d’autres l’ont déjà mentionné, pour obtenir une application exactement native à partir d’un langage "one-size-fits-all" comme Java, vous devrez travailler un peu. L'interface utilisateur de Java était / était / toujours-sont destinés à être un "meilleur ajustement pour toutes les plates-formes" out-of-the-box.
SnakeDoc

Réponses:

56

N’est-ce pas seulement une question de concevoir des boutons qui ressemblent à des boutons «natifs»?

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 d'interface graphique ne sont pas aussi simples que des bitmaps aléatoires qui sont étirés (car ceux-ci ne s'adaptent pas du tout très bien). Ce sont souvent des graphiques vectoriels avec beaucoup de casse 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 lorsque vous cliquez sur un bouton. 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. Bien qu'ils fassent du bon travail dans la plupart des cas, il y a inévitablement des choses qui manquent à cause du grand nombre de composants graphiques disponibles.

Je dis tout ce qui précède, basé sur Swing, qui est bien sûr une boîte à outils graphique non native et légère. Vous mentionnez spécifiquement que SWT 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 se présente pas comme il se doit, ce ne sera pas à cause de l'apparence.

berry120
la source
1
Merci. Que veut dire "poids léger" exactement? Et que signifie réellement "natif"? Je suppose que cela signifie quelque chose qui utilise les ressources du système d'exploitation de l'ordinateur ou interagit directement avec lui. Est-ce vrai?
user3150201
1
@ user3150201 Bien sûr, le système d'exploitation sous-jacent aura un nombre défini de boutons et de widgets pouvant être placés en mode natif, mais il est évident que ces boutons diffèrent d'un système à un autre et d'une plate-forme à l'autre. Il s'agit des composants natifs, lourds. Les composants légers ne sont pas les composants dictés par le système d'exploitation, ils sont dessinés par Java (dans ce cas) pour ressembler et se comporter comme des composants d'interface graphique - afin qu'ils puissent ressembler à tout ce que vous voulez si vous mettez le travail (mais vous devez émuler la plate-forme ressemble si vous le souhaitez, vous ne l'obtiendrez pas gratuitement.)
berry120
14
L'emplacement des boutons, les tailles exactes et les styles d'interface graphique préférés varient en fonction de la plate-forme. Java nécessite de les imiter. Swing peut vous donner le bouton natif, mais si sa hauteur est de 10 pixels, l’utilisateur pensera toujours que quelque chose ne va pas. Apple dispose des « Human Interface Guidelines» et Microsoft, des « User Interface Guidelines», qui vous aident à obtenir l’apparence native correcte. Vous aurez besoin de changer légèrement l'interface utilisateur entre les plates-formes.
Michael Shopsin
4
JavaFX apparaît beaucoup plus "natif" que SWING et AWT. Il a des fenêtres transparentes natives, etc. Beaucoup plus moderne, avec une apparence originale.
SnakeDoc
2
@ SnakeDoc Cela semble plus moderne, bien sûr, mais je ne dirais pas qu'il apparaît "natif" - il n'utilise certainement pas les composants de l'interface graphique sous-jacente de la plate-forme, tout est traité en CSS.
Berry120
71

Il existe littéralement une demi-douzaine de boîtes à outils pouvant être considérées comme «natives» sur un système donné. Certains d'entre eux ont des concepts ou des capacités plutôt uniques, et les répliquer dans une boîte à outils multiplateformes est fastidieux. Le look & feel d'une application n'est pas seulement déterminé par un "skin", mais aussi 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? Très bien, construisons un dialogue séparé 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? Très bien, 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 de KDE) ou se trouve-t-elle en haut de l'écran (Mac, Unity)? Très bien, écrivons une implémentation différente pour chaque système, car nous avons déjà jeté la disposition exacte au pixel près.
  • Comment les polices sont-elles rendues? Aussi net que possible, ou lisse et anti-crénelé? Et quelle police faut-il utiliser? Notez que différentes polices ont des métriques différentes, de sorte qu'un même paragraphe rendu avec la même largeur peut avoir un nombre de lignes différent selon la police.
  • L'arrière-plan d'une fenêtre est-il d'une seule couleur, d'une image ou d'un dégradé? Mettons simplement cela dans une feuille de style également.
  • A quoi ressemblent les barres de défilement? Où sont les boutons - s'ils en ont? Quelle est leur largeur ou sont-ils seulement révélés lorsque le pointeur se déplace dans une région donnée?
  • Comment incorporons-nous d'autres jeux de couleurs?
  • Qu'est-ce qui devrait être déplaçable? Où sont les menus contextuels attendus?

Ces problèmes ne peuvent pas être résolus avec une simple feuille de style lorsqu'ils abordent le comportement ou la présentation générale de l'application. La seule solution réelle consiste à ré-écrire l'application pour chaque système (en ignorant ainsi les avantages multi-plateformes de Java). La seule solution réaliste consiste à oublier la disposition au pixel près et à écrire sur une interface commune qui résume des boîtes à outils spécifiques au système. La solution adoptée par Swing consiste à émuler divers systèmes qui échouent de manière spectaculaire.

Et puis, il y a la cohérence entre les plates-formes, l'idée que votre application peut être exactement la même sur tous les systèmes (souvent choisis par les jeux, ce qui augmente l'immersion). Sur les applications de bureau, cela est simplement ennuyeux et répond aux attentes des utilisateurs.

Amon
la source
1
+1 J'aimerais ajouter une seule chose: qu’en est-il des éléments que le système permet à l’utilisateur de configurer, à partir de détails «simples» tels que l’ouverture des menus contextuels? (Et je préférerais de beaucoup que les programmes Windows ne comportent pas de rubans ni d'applications Mac, merci. Oui, il est nécessaire de concevoir de bonnes interfaces graphiques par système d'exploitation.)
Christopher Creutzig
@ChristopherCreutzig C'est de là que vient mon expérience: sur mon bureau principal, j'utilise KDE sous Linux (les deux étant très configurables) et j'utilise QtCurve pour ajuster l'apparence des applications. Ces styles spéciaux fonctionnent parfaitement dans les applications KDE phares. Les applications GTK bien écrites peuvent utiliser un calque de compatibilité, mais les dégradés d'arrière-plan sont manquants, la barre de menus reste dans la fenêtre, etc. , mais en ignorant d' autres (comme le rendu des polices, ou les ombres autour de menus)
amon
+1 car cette réponse contient des points forts, mais également des points faibles. Tout problème "Comment ce gestionnaire de fenêtres dessine-t-il X" est traité à l'aide de l'API native. Par exemple, X11 sur OS X peut dessiner des fenêtres, des boutons, des barres de défilement, des boîtes de dialogue, etc. natifs d'OS X. Ainsi, bon nombre de ces problèmes disparaissent. La vraie réponse est ce que @TheSpooniest a déclaré ci-dessous: UX est bien plus que simplement dessiner des widgets. Espacement, minutage, animation, accélération de la souris, entrées tactiles… tout un monde de détails subtils est très coûteux à reproduire avec une boîte à outils multiplateformes.
Mark E. Haase
13

Oui, ça va plus loin.

Il est facile de créer un bouton ressemblant à un bouton Windows ou OS X lorsque vous ne créez que ce bouton. Mais le bouton doit "se comporter" comme les boutons originaux, ce qui pourrait ne pas être simple: peut-être qu'il y a plus d'espace disponible dans une version, mais pas dans l'autre, peut-être que la couleur est plus adaptée à votre conception dans la version Windows, etc.

Ceci est plus important lorsque vous avez une interface graphique complète: un programme OS X présente son contenu différemment d’un programme Windows. Cela est presque impossible à capturer dans une interface graphique - vous auriez besoin de deux interfaces graphiques, mais peu d'applications font autant d'histoires. Au lieu de cela, ils cherchent à obtenir un "look ok sur la plupart des systèmes" - cela a toujours l’air quelque peu étrange, mais est utilisable et beaucoup plus facile à développer.

Christian Sauer
la source
9

Il n’est pas difficile de créer un bouton qui ressemble à un bouton OSX, à un bouton Windows ou à un autre toolkit. Toutefois, les consignes d'utilisation de l'interface utilisateur pour la plupart des environnements ne sont pas aussi simples que les principes de base "voici à quoi ressemble un bouton". Il existe de nombreuses différences plus subtiles, allant 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 la plupart des tâches d'interface utilisateur, sinon la plupart, nécessitent une intervention beaucoup plus fine.

SWT a essayé d'automatiser cela dans une certaine mesure et, encore une fois, il convient parfaitement aux tâches simples de l'interface utilisateur. Mais il n'y a pas de solution unique, et donc, lorsque les interfaces utilisateur deviennent plus complexes, les méthodes de base qu'elle utilise commencent à s'effriter. Il est généralement possible de le ramener au travail manuel fastidieux de l'interface utilisateur, mais ce n'est pas quelque chose que la plupart des programmeurs sont capables ou disposés à faire pour toutes les plateformes.

La démarche de Swing visait simplement à éviter les boîtes à outils natives chaque fois que cela était possible. Ce n'est pas natif, et il n'essaye pas de l'être: il essaie plutôt de créer quelque chose qui aura l'air (presque) le même, peu importe où il est exécuté. Plutôt que d'essayer (en vain) de plaire à tout le monde, il a essayé de se faire plaisir et, même s'il a réussi dans la mesure du possible, on peut s'interroger sur l'efficacité du résultat pour la communauté d'utilisateurs dans son ensemble.

Le Spooniest
la source
7

Vous devez vous attendre à ce que votre application soit aussi naturelle que possible sur chaque système et à 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 voudrez peut-être protéger les utilisateurs de votre boîte à outils graphiques contre les "améliorations" des composants natifs et de l'API sous-jacents qui pourraient endommager inopinément leur application.

C'est pourquoi certains développeurs de kits d'outils graphiques préfèrent fournir leurs propres composants qui imitent ceux d'origine, mais fournissent leur propre implémentation. D'autre part, développer une boîte à outils d'interface graphique entièrement fonctionnelle représente un effort important, et des considérations économiques peuvent conduire à couper quelques bords.

Notez que ce problème n'est pas spécifique à Java, mais que chaque entreprise produisant des kits d'outils indépendants de la plate-forme est confrontée.

Nicola Musatti
la source
Plutôt que de voter en silence, vous rendriez un meilleur service à la communauté en expliquant ce que vous pensez être faux avec une réponse. A moins que ce ne soit juste une question personnelle ...
Nicola Musatti
4

Tout est dû à l'histoire.

Sun a souhaité que tous les logiciels Java fonctionnent de la même manière sur toutes les machines.

Pour qu'un logiciel apparaisse comme natif, il doit fonctionner de la même manière que les autres logiciels du système d'exploitation donné.

Sun a tout mis en œuvre pour rendre difficile l’écriture de logiciels Java intégrés à un système d’exploitation, car toute intégration avec un système d’exploitation rendrait le logiciel différent sur chaque système d’exploitation.

De nos jours, très peu de programmeurs Java s'intéressent à autre chose qu'aux logiciels basés sur un serveur Web.

Sun a tué Java sur le bureau en utilisant tous les programmeurs utilisant les systèmes Microsoft Java, ce qui rendrait tout programmeur qui choisissait Java jadis de mal paraître.

Toute personne qui écrit un logiciel de bureau soucieux d’être «apparemment native» a appris il ya longtemps à ne pas utiliser Java et voit sa vision renforcée chaque fois qu’elle utilise un logiciel Oracle.

Par conséquent, de nos jours, les programmeurs Java n’exigent aucune «apparence native» pour les logiciels de bureau.

Ian
la source
5
"Sun a tout mis en oeuvre pour rendre difficile la rédaction d'un logiciel Java intégré à un système d'exploitation", mais c'est faux. Ils ne font tout simplement pas de gros efforts pour faciliter les choses. "Sun a tué Java sur le bureau en manipulant tous les programmeurs utilisant les systèmes Microsoft java", l'inimitié réciproque entre Microsoft et Sun a amené Microsoft à créer une version des bibliothèques AWT non compatible avec la configuration requise par Sun, Procès Sun / MS.
Jwenting
1
@jwenting, Sun se souciait davantage de créer des problèmes pour Microsoft que des programmeurs qui avaient choisi d'utiliser le système java de Microsoft. J'ai donc abandonné Jave et gardé avec MFC jusqu'à ce que C # sorte.
Ian
3
peut-être certaines personnes chez Sun, mais ce sentiment était mutuel. Si vous développez exclusivement pour une plate-forme unique, un outil natif pour cette plate-forme est TOUJOURS l'option préférée, cela n'a rien à voir avec la politique d'entreprise. Si vous choisissez vos outils basés sur "je déteste Sun" ou "je déteste Microsoft", cela reflète très mal votre attitude professionnelle. J'ai principalement utilisé Java, mais parallèlement, j'ai également utilisé Delphi, C #, Ruby, C ++, C, Progress, tout ce qui était le mieux pour le travail à accomplir. Et le plus souvent, cela finira par être une solution hybride.
Jwenting
3

Ce que vous pensez, en nativeréalité, est que les applications natives agissent de leur côté alors que des kits tels que SWT respectent les normes publiées pour l'interface utilisateur de ce système d'exploitation. Le problème est que personne ne crée d'applications qui respectent ces normes, donc lorsque vous lancez une application Java. Il semble ne pas être natif. Par exemple, presque tous les projets de Microsoft (Office, Outlook, etc.) ne peuvent pas être reproduits visuellement à l'aide des contrôles standard Windows.

La situation ne fera qu'empirer, car Microsoft et Apple ajouteront des fonctionnalités d'interface utilisateur dynamiques à leurs plates-formes de système d'exploitation. Permettre aux développeurs de personnaliser / habiller leurs applications de la même manière que les conceptions Web créent des styles pour les sites Web.

Java sur la plate-forme Android suit ce chemin. Définition des éléments d'interface utilisateur pour Android en XML avec des styles personnalisables.

Java n'a jamais été très populaire en tant que plate-forme de bureau. En conséquence, ces changements dans l'industrie ne se propagent pas jusqu'aux exécutions de postes de travail. Il n’ya tout simplement pas assez de développeurs prêts à consacrer du temps à résoudre le problème.

Réactionnel
la source
1
+1, à l'époque de Windows 95, il existait un aspect «standard» des contrôles Windows. Maintenant, pas tellement.
Grandmasterb
Oui, cela fait quelques années que je n'ai pas programmé d'ordinateur de bureau, mais j'ai été surpris de constater que .NET n'était pas livré avec un contrôle de style ruban alors qu'il est devenu partie intégrante du logiciel de productivité construit par MS.
Rig
@Rig Depuis NET 4.0, il existe un bon contrôle de ruban natif dans .NET. Voici un bon article: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5
Christian Sauer le
1
@Rig Vous aurez besoin de .NET 4.5 et non de .NET 4. Visual Studio 2010 ne peut cibler que 4 personnes maximum; vous aurez besoin de VS2012 ou plus récent pour cibler la 4.5. Je peux le voir lorsque je cible 4.5 dans VS2013, mais pas lorsque je change la version cible en 4.
Bob
1
@Rig Il est possible d’utiliser le ruban dans Net 4.0 - vous pouvez le télécharger à partir de Microsoft, puis il apparaîtra: 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Vous ne savez pas si cela est la dernière version). Mieux vaut le télécharger à partir de Nuget. Je devais le faire pour un programme qui devait fonctionner sous Windows XP - fonctionne bien et est principalement compatible avec la variante Net 4.5. Vous pouvez donc extraire la version 4.0 lorsque XP se retire enfin.
Christian Sauer
-1

Quel système d'exploitation voulez-vous aussi avoir l'air "natif"?

Vous ne pouvez tout simplement pas être natif de tous à 100% du temps.

Les SWT, etc. constituent la meilleure approche possible pour donner l’impression d’être native pour chacun d’entre eux lorsque vous avez besoin de parvenir à un compromis .

Et en fait, ce compromis commence à devenir de plus en plus difficile à atteindre; pas tellement à cause des systèmes d'exploitation, mais à cause des périphériques d'entrée. Pour les écrans tactiles, vous devez réellement concevoir différemment, car il n’ya pas de bouton droit de la souris. Par conséquent, vous devez sinon utiliser la même fonctionnalité.

Il n’existera jamais de bouton magique permettant de déplacer "intuitivement" les fonctionnalités du bouton droit de la souris aux invités, sans que vous spécifiiez chaque aspect détaillé pour chaque périphérique d’entrée (à quel point vous êtes natif de chaque -natif à tout ce que vous n'avez pas considéré).

Anony-Mousse
la source
-2

Très bonne question. Je me suis toujours posé des questions moi-même au cours des années suivantes, je pensais qu'il y avait une raison légitime à cela, mais ce n'est pas le cas.

Je pense que la réponse est assez simple, et beaucoup de réponses ne creusent pas vraiment la question.

Si votre langue permet de dessiner piexel à l'écran, il est alors 100% possible de créer un framework d'interface graphique basé sur celui-ci, qui imitera précisément les contrôles de formulaire Windows.

Étant donné que Java est une plate-forme croisée, il est également tout à fait possible de s’assurer que, en fonction du type de système en cours d’exécution (Mac / Windows), l’UI choisira d’avoir une apparence différente sur les deux plates-formes, correspondant au style de plate-forme d’exécution.

Comme vous pouvez le voir dans XAML par exemple, l'interface utilisateur peut être facilement présentée sous une forme et un langage très structurés. Le choix des comportements "natifs" est également possible si on prend le temps de le faire.

Il serait donc possible de créer une infrastructure graphique permettant aux développeurs Java d’obtenir des applications ayant un aspect natif sur Mac et Windows.

Nous arrivons donc à Swing, qui n’est qu’un framework GUI sur une infinité potentielle de frameworks GUI pouvant être créés pour Java. Il se comporte comme il a été programmé, ce qui ne suit pas le processus ci-dessus et vous obtenez des applications étranges à la recherche sur les deux systèmes. C’est le choix des développeurs Swing, personne ne les a forcés à le faire et à se comporter de la sorte.

Valentin Kuzub
la source
2
cela ne répond pas à la question, le demandeur a déjà couvert ce point: "Swing aurait peut-être été conçu exprès pour donner un aspect distinctif"
jeudi
Je ne suis pas d'accord, mais merci d'avoir commenté votre point négatif (?)
Valentin Kuzub le