Java Swing - Page 3

Oui, aussi, mais bon, ça aide déjà pas mal (parce que l'inverse est vrai : Office 2007 n'a pas le look'n feel natif mais offre une intégration inter-applications).

Bof je préfère largement qu'une appli ait ses propres couleurs et utilise les boîtes de dialogue classique quand on veut ouvrir un fichier, par exemple

Kevin Kofler (./54) :
@squalyl: Si, justement une application avec un look&feel non-natif pète le design de la plateforme! Mais c'est bien ça le problème, Java se prend pour une plateforme alors que c'est seulement un langage de programmation.

En effet c'est un choix entre péter le design de l'appli et celui de la plateforme. JAVA tient à une compatibilité maximale par défaut, donc préfère casser le look de la plateforme que de prendre de risque de casser celui de l'appli, contrairement à Qt.

Kevin Kofler (./54) :
@Nil: Qt s'en sort très bien avec le look&feel natif (par défaut)!

Tu as de la chance alors parce qu'il m'est arrivé de devoir corriger dans deux de mes applis Qt quelque petit problèmes de dimensionnement entre Linux, MacOS et Win32.
Je ne regrette pas de les avoir corrigé et gardé un l&f natif, et avec Java je fais de même.
Toujours est il que c'est bon d'avoir le choix surtout quand on a pas forcément accès à la plateforme pour tester. Sous Qt, ce problème ne se pose pas vu qu'il faut de toute façon avoir accès à la plateforme pour compiler.

Kevin Kofler (./54) :
@squalyl: Si, justement une application avec un look&feel non-natif pète le design de la plateforme!
Mais c'est bien ça le problème, Java se prend pour une plateforme alors que c'est seulement un langage de programmation.

Ne confond pas ce que Java est et ce que tu voudrais qu'il soit. Java sans être un OS est quand même bien plus qu'un simple langage de programmation.

Flanker (./62) :
je préfère largement qu'une appli [...] utilise les boîtes de dialogue classique quand on veut ouvrir un fichier, par exemple

Une application Qt ou même KDE 4 fait ça, hein.

Uther (./63) :
Tu as de la chance alors parce qu'il m'est arrivé de devoir corriger dans deux de mes applis Qt quelque petit problèmes de dimensionnement entre Linux, MacOS et Win32.

Tu n'as pas utilisé les layouts correctement alors.

Toujours est il que c'est bon d'avoir le choix surtout quand on a pas forcément accès à la plateforme pour tester.

Qt te permet de tester avec plusieurs styles pour voir ce que ça donne. Certains (QWindowsXPStyle, QWindowsVistaStyle, QMacStyle) ne sont disponibles que sous la plateforme de destination (parce qu'ils utilisent les fonctions d'affichage natives, justement), mais d'autres (QWindowsStyle, QPlastiqueStyle, QCleanlooksStyle, le style Oxygen de KDE 4 etc.) sont disponibles partout, donc peuvent être testés partout. (Et il y a des cas entre les deux, comme QGtkStyle qui peut probablement en principe être compilé partout, mais qui nécessite GTK+, donc normalement il n'est disponible que sous Qt/X11.) Qt Designer a même un menu pour faire une prévisualisation rapide avec plusieurs styles.

Sous Qt, ce problème ne se pose pas vu qu'il faut de toute façon avoir accès à la plateforme pour compiler.

Pas forcément, on peut aussi distribuer les sources et laisser quelqu'un sur la plateforme visée le packager (le modèle de distribution de la plupart des logiciels libres). Et on peut aussi cross-compiler (cf. cross-MinGW).

Ne confond pas ce que Java est et ce que tu voudrais qu'il soit. Java sans être un OS est quand même bien plus qu'un simple langage de programmation.

Pourtant, techniquement, c'est bien ce qu'il est, et effectivement je lui reproche de vouloir être autre chose que ce qu'il est en réalité.

techniquement, il est la définition de Sun, pas de gcj ni la tienne.

Kevin Kofler (./65) :

Uther (./63) :
Tu as de la chance alors parce qu'il m'est arrivé de devoir corriger dans deux de mes applis Qt quelque petit problèmes de dimensionnement entre Linux, MacOS et Win32.

Tu n'as pas utilisé les layouts correctement alors.

Une grosse partie était due en effet à une mauvaise utilisation des layout. Cependant les layout ne suffisent pas forcément à régler 100% des problèmes. Toujours est-il que en JAVA que l'on utilise les Layouts correctement, mal ou même pas du tout, le rendu est quasi identique avec le cross-platform l&f .

Kevin Kofler (./65) :
Qt te permet de tester avec plusieurs styles pour voir ce que ça donne. Certains (QWindowsXPStyle, QWindowsVistaStyle, QMacStyle) ne sont disponibles que sous la plateforme de destination (parce qu'ils utilisent les fonctions d'affichage natives, justement)

C'est bien pour cela que je disais que c'est impossible de s'assurer vraiment que le rendu natif d'une autre plateforme est bon, sans la posséder. Les look cross plateforme permettent d'y remédier aussi bien sous Qt que Java. La seule différence est que QT utilise un l&f natif par défaut et Java un l&f cross-plateforme, et dans les deux cas on peut passer de l'un a l'autre en une ligne de code qu'est sensé connaitre un développeur qui a dépassé le stade du "hello world".

C'est au développeur de choisir lequel il préfère, c'est très bien ainsi et ne vaut vraiment pas la peine de troller sur ces détails insignifiants.

Kevin Kofler (./65) :
Pas forcément, on peut aussi distribuer les sources et laisser quelqu'un sur la plateforme visée le packager (le modèle de distribution de la plupart des logiciels libres). Et on peut aussi cross-compiler (cf. cross-MinGW).

Certes mais les contributeurs ça court pas forcement les rues. Et j'attends toujours un cross compiler pour MacOS X qui m'évitera de recourir à un hackintoch bancal.

Kevin Kofler (./65) :
Pourtant, techniquement, c'est bien ce qu'il est, et effectivement je lui reproche de vouloir être autre chose que ce qu'il est en réalité.

Non ce n'est pas que un langage de programmation. N'importe qui ayant un minimum de connaissance sur le sujet le sait.
Il suffit de regarder la première page de la doc de JavaSE pour se rendre compte que le langage n'est que la surface. Et encore, là je ne parle que de JavaSE. Si on ajoute JavaEE, ça va encore bien au delà. Bien sur si tu choisis de compiler en natif via GCJ et d'utiliser uniquement les lib natives en effet tu n'utiliseras quasiment que le langage, il n'empêche que ce n'est qu'une petite partie de la plateforme Java.
Il y a d'ailleurs plusieurs langages autre que Java qui utilisent également la plateforme Java comme Groovy, Scala ou JRuby pour ne citer que les plus connus.

faut faire attention à son look&feel avant d'aller danser le swing

surtout quand on aime faire la java

awwwt...

Twindruff (./12) :
T'as un élément de comparaison ? parce c'est jamais un gros bonheur à décrire en code les interfaces

Si, avec lablgtk ; mais quand on code dans un langage hyper verbeux comme java c'est sûr que c'est vite chiant

squalyl (./66) :
techniquement, il est la définition de Sun, pas de gcj ni la tienne.

Non, techniquement, il y a ce que le Java est objectivement, c'est un langage de programmation et une librarie de classes.

Sun peut "définir" que Java est une plateforme tout comme tu peux définir que 2+2=5, ça ne le rend pas plus vrai.

Uther (./67) :
Toujours est-il que en JAVA que l'on utilise les Layouts correctement, mal ou même pas du tout, le rendu est quasi identique avec le cross-platform l&f .

Donc en plus, leur look&feel par défaut ne respecte pas le réglage de dpi de l'utilisateur? => Poubelle!
Parce que ce sont bien les dpis le problème principal quand on n'utilise pas les layouts, pas les styles.

C'est bien pour cela que je disais que c'est impossible de s'assurer vraiment que le rendu natif d'une autre plateforme est bon, sans la posséder.

Si ton application fonctionne correctement avec tous les styles livrés avec Qt, il y a de fortes chances qu'elle fonctionne correctement avec les styles natifs aussi. Et il faut savoir que "il y a de fortes chances" est suffisant dans le domaine du libre, les développeurs de logiciels libres sont bien conscients qu'ils ne peuvent pas tester sur toutes les plateformes sur lesquelles leur logiciel sera employé.

et dans les deux cas on peut passer de l'un a l'autre en une ligne de code qu'est sensé connaitre un développeur qui a dépassé le stade du "hello world".

Mais ça ne sert à rien à l'utilisateur qui se trouve bloqué avec une application non-native parce que le développeur a été trop paresseux pour mettre cette ligne! C'est bien pour ça que le look&feel par défaut est important.

C'est au développeur de choisir lequel il préfère, c'est très bien ainsi

Ben non, c'est à l'utilisateur! Et c'est bien comme ça que fonctionne normalement Qt (cf. qtconfig), et le choix par défaut est celui que la plupart des utilisateurs attendent (look&feel natif). (Maintenant, il y a des logiciels propriétaires pourris qui font joujou avec les réglages de style, genre Skype auquel il faut passer un paramètre spécial pour désactiver le style forcé, mais ça reflète bien l'attitude arrogante des logiciels propriétaires, où les développeurs "choisissent pour toi".)

et ne vaut vraiment pas la peine de troller sur ces détails insignifiants.

Ce n'est pas insignifiant. Le look&feel par défaut du toolkit est aussi celui de 99% des applications. Et c'est le choix pour l'utilisateur qui m'intéresse, pas pour le développeur! Le choix de style que je veux utiliser en tant qu'utilisateur est mon choix, pas celui du développeur de l'application, ça ne le regarde pas du tout! Il (ou plutôt son logiciel) a à s'adapter à mon choix, pas l'inverse.

Certes mais les contributeurs ça court pas forcement les rues.

Bah tant pis, il n'y aura pas de version Mac alors (et la version W32 sera cross-compilée et jamais testée, si elle existe). Les gens qui utilisent ces OS seront bien obligés de contribuer s'ils veulent utiliser l'application. (C'est comme ça que fonctionnent pratiquement tous les logiciels libres. S'il y a des portages W32, en général c'est bien parce qu'un utilisateur de cet OS s'est mis à porter le logiciel!)

Et j'attends toujours un cross compiler pour MacOS X qui m'évitera de recourir à un hackintoch bancal.

C'est bien pour ça que je ne propose pas de binaires pour OS X pour mes logiciels.

Cela dit, il est probablement possible de cross-compiler avec les fichiers "hackintosh" copiés sur une partition GNU/Linux. (On utilise une chaîne d'outils cross pour Darwin et on linke avec les libs "hackintosh".) Mais ce n'est pas plus légal qu'utiliser directement le système "hackintosh".

Non ce n'est pas que un langage de programmation.

Tu peux discuter autant que tu veux là-dessus, mais ce qui compte, c'est que ce n'est ni un système d'exploitation ni une interface graphique (genre X11), ni un environnement desktop (genre KDE), et c'est à l'ensemble de ces composantes (ce que j'appelle "plateforme") de définir le look&feel, pas à une soi-disant "plateforme" de développement qui ne fait que tourner par dessus la vraie plateforme. Donc ce qu'est exactement le Java n'a aucune importance pour ça.

Sally (./70) :
Si, avec lablgtk ; mais quand on code dans un langage hyper verbeux comme java c'est sûr que c'est vite chiant

Bof ça reste du gtk (donc de l'impératif) je trouve toujours ça nul
De toutes façons c'est des arbres donc personnellement ce que je trouve le plus pratique si je dois me passer de designer c'est de décrire l'interface en XML (cf XUL, XAML, XRC, etc).

Kevin, tu veux pas aller t'occuper de KDE, Qt ou pourquoi pas TIGCC, plutôt que de troller ?

c'est marrant de lire Kevin

Quand on parle de TIGCC c'est lui le dév le plus important et non l'utilisateur
Quand on parle de Java, c'est l'utilisateur le plus important et non le dev.

Quel Blagueur ce KK

Qu'est-ce qui te choque dans ce raisonnement ? Il respecte la loi n°1 : Kevichou a toujours raison.

Manoloben (./74) :
c'est marrant de lire Kevin

Quand on parle de TIGCC c'est lui le dév le plus important et non l'utilisateur
Quand on parle de Java, c'est l'utilisateur le plus important et non le dev.

Quel Blagueur ce KK

Ya mieux, il prone le natif, mais impose des trucs non natifs....

Manoloben (./74) :
Quand on parle de TIGCC c'est lui le dév le plus important et non l'utilisateur

Euh, c'est vraiment n'importe quoi. J'ai toujours l'utilisateur en tête, par exemple si je rejette des patches non documentés, c'est bien parce que c'est le bordel à utiliser.

Certains se plaignent du remplacement de VTI par TiEmu, mais TiEmu est des mondes au-delà de VTI en termes de confort pour les utilisateurs, surtout pour les programmeurs C qui ne comprennent pas l'assembleur (et il y en a beaucoup), qui ont maintenant à leur disposition un débogueur. (Le débogueur de VTI est totalement inutilisable si on ne connaît pas l'assembleur.) Aucune fonctionnalité n'a été perdue avec le passage VTI->TiEmu!

Mais il ne faut pas oublier qu'il n'y a pas que l'utilisateur de TIGCC à avoir en tête, mais aussi l'utilisateur des programmes que l'utilisateur de TIGCC va développer! Si nous avons fait (au pluriel parce que ça date de l'époque où Zeljko et Sebastian étaient encore actifs) des choses comme:
* conseiller le mode _nostub,
* vérifier le modèle de la calculatrice et la version minimale de AMS dans le code de démarrage (sans mettre d'option pour retirer ces vérifications dans les dialogues des EDIs),
c'est bien dans l'intérêt de ces utilisateurs finaux, même si ça va à l'encontre des désirs de certains de nos utilisateurs directs (qui sont des développeurs). Ça reflète donc exactement l'état d'esprit que je défends dans ce topic (à savoir que c'est l'utilisateur final qui a toujours raison)!

Godzil (./76) :
Ya mieux, il prone le natif, mais impose des trucs non natifs....

J'utilise les meilleurs outils disponibles en logiciel libre, il se trouve que ce sont KDE/Qt et GTK+. (Pour mes projets personnels, c'est KDE/Qt systématiquement, mais je ne vois pas de mal à contribuer à des projets en GTK+, c'est aussi un bon toolkit multiplateforme.) Et ils offrent tous les deux un look&feel natif sous W32 et OS X (oui, il y a un portage Cocoa de GTK+ aussi maintenant). Et je signale aussi que c'est moi qui ai eu l'idée de gérer les dialogues de fichiers natifs (W32 et KDE) dans TiEmu et qui ai écrit pas mal du code nécessaire (Romain a codé en grande partie le code W32, j'ai fait quelques modifications au code W32 et écrit le code KDE). TiLP et GFM utilisent aussi ces abstractions pour les dialogues de fichiers maintenant.

Tout ce qui me manque, c'est un packager de binaires OS X - les Mac-eux sont toujours là pour exiger qu'on gère leur plateforme, mais jamais pour faire le boulot. (Pour W32, je peux m'arranger avec cross-MinGW, mais il n'existe aucun équivalent (légal) pour OS X.) Les sources sont déjà compatibles, et je fais tout mon possible pour qu'ils le restent (même si je n'ai pas de Mac!).


Bref, vous cherchez des contradictions là où il n'y en a pas.

Et tiens, pour une vraie contradiction: d'un côté on m'accuse toujours de ne jamais changer d'avis, de l'autre on m'accuse d'avoir des avis incohérents (en d'autres mots: de toujours changer d'avis). Faut savoir...

Kevin Kofler (./77) :
J'utilise les meilleurs outils disponibles en logiciel libre, il se trouve que ce sont KDE/Qt et GTK+.

Et Java aussi, à présent, non ?

Java pour W32 et OS X n'est pas libre, OpenJDK ne compile pas encore sous ces plateformes.

Et puis j'ai dit "les meilleurs", ça exclut clairement Java.

Kevin Kofler (./79) :
Java pour W32 et OS X n'est pas libre, OpenJDK ne compile pas encore sous ces plateformes.

Pourtant d'après le site d'OpenJDK, ils semblent indiquer que ça compile avec VS2003.

Kevin Kofler (./77) :

Manoloben (./74) :
Quand on parle de TIGCC c'est lui le dév le plus important et non l'utilisateur

Euh, c'est vraiment n'importe quoi. J'ai toujours l'utilisateur en tête, par exemple si je rejette des patches non documentés, c'est bien parce que c'est le bordel à utiliser.

Certains se plaignent du remplacement de VTI par TiEmu, mais TiEmu est des mondes au-delà de VTI en termes de confort pour les utilisateurs, surtout pour les programmeurs C qui ne comprennent pas l'assembleur (et il y en a beaucoup), qui ont maintenant à leur disposition un débogueur. (Le débogueur de VTI est totalement inutilisable si on ne connaît pas l'assembleur.) Aucune fonctionnalité n'a été perdue avec le passage VTI->TiEmu!

Toujours est-il que beaucoup d'utilisateurs préfèrent VTI, et tu ne prends pas leur avis en compte... Mais c'est comme toujours, tu imposes ta vision du monde sans jamais prendre en compte le fait que les autres puissent ne pas penser comme toi...

Pourquoi ai-je l'impression de lire ce post pour la cinq milliardième fois ?

Nil (./80) :

Kevin Kofler (./79) :
Java pour W32 et OS X n'est pas libre, OpenJDK ne compile pas encore sous ces plateformes.

Pourtant d'après le site d'OpenJDK, ils semblent indiquer que ça compile avec VS2003.

Source? Je ne trouve pas ça sur openjdk.org... (Ça doit être nouveau en tout cas, je sais que ce n'était pas le cas il y a quelques mois.)
Mais bon, si ça ne compile pas avec MinGW, c'est nul. Les solutions vraiment libres comme Qt, KDE et GTK+ sont compilables entièrement avec MinGW.

http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html (Et ça semble compiler avec Cygwin, mais j'ai lu de façon transversale)

Kevin: Ca commence vraiment a être lourd ta vision du libre MadeInKevin™ Si tu compile ton application java avec openJDK, quelque soit l'environnement elle reste libre MEME si c'est la JVM de Sun. Mais bon comme d'habitude il faut que tu cherche a avoir raison. Comme dire que Qt/Gtk est ce qui se fait de mieux en terme de "natif portable". Met toi sa dans le crâne, le NATIF-PORTABLE ça n'existe pas, aucune application Qt, (et encore moins GTK) ne s'intègre correctement sous Windows ou sous Mac OS X, les différenrences sont visible dans 99.99999% des cas du premier coup d'œil. Idem pour tes autres imbécillités sur les layouts ou DPI & co, sur chaque système, pour prendre un exemple simple) les bords des boutons sont différents, et il suffit que le bord ou le texte n'est pas imprimable soit vraiment différent, pour que ça tronque le texte, c'est du vécu sur des application dites "libre et portable" et ce même en Java, et c'est loin, très loin d'être un problème de layout ou autre conneries du genre. Une application pour qu'elle soit "native" DOIT être fait en respectant les règles de développement d'une IHM pour le système ou elle compte tourner. Mais bon les linuxiens avec leur manières ne peuvent comprendre ça.

Kevin Kofler (./77) :
Tout ce qui me manque, c'est un packager de binaires OS X - les Mac-eux sont toujours là pour exiger qu'on gère leur plateforme, mais jamais pour faire le boulot.    (Pour W32, je peux m'arranger avec cross-MinGW, mais il n'existe aucun équivalent (légal) pour OS X.) Les sources sont déjà compatibles, et je fais tout mon possible pour qu'ils le restent (même si je n'ai pas de Mac!).

J'en ai un, mais je ne suis pas excellent dans ce domaine (je ne sais pas grand chose de plus que configure, make et make install...), mais je suis prêt à faire le boulot, si on m'explique bien ce qu'il faut faire...

@Godzil: Justement, si on utilise les layouts comme il faut, le texte tronqué n'existe pas, parce que le layout va automatiquement rendre ton dialogue suffisamment grand pour que tout le texte rentre. (Du moins c'est ce qui se passe avec Qt, je ne sais pas pour le Swing.)

@KillerX: Je pense que le mieux est de faire un topic dédié, ou alors qu'on en parle sur IRC (sachant quand-même que je ne suis pas en ligne 24/7 et que même si je parais en ligne, je peux m'être endormi sans avoir pensé à me marquer absent ou éteindre l'ordinateur ).

Bah tu m'enverras un PM s'il y a quelque chose en particulier dont tu vx parler

Kevin Kofler (./78) :
Euh, c'est vraiment n'importe quoi. J'ai toujours l'utilisateur en tête

ton modèle de l'utilisateur basé sur toi même surtout

Kevin Kofler (./78) :
mais TiEmu est des mondes au-delà de VTI en termes de confort pour les utilisateurs

t'es bien fort pour juger à leur place.

Kevin Kofler (./78) :
Et ils offrent tous les deux un look&feel natif sous W32

rhhh je rugis de nativité

ne me dis pas que ça peut changer, c'est pas fait, c'est foutu.

Bon, euuuh, s'il vous plait, c'est le 25 décembre la fête de la nativité