60

Kevin Kofler (./57) :
(mais ils utilisent un look&feel non natif par défaut pour je ne sais pas quelle raison, peut-être du marketing, comme le look Aqua de Safari, mais ça fait que les applications Swing ont un look hors de place par défaut alors que ce ne serait pas du tout nécessaire! frown.gif )
Je trouve moi aussi cela dommage. La raison avancée par SUN est que les applications java se doivent d'avoir un comportement identique sur toute les plateformes, donc en utilisant le "crossplatform look and feel" par defaut, il n'y a pas de problèmes du style des éléments plus gros sous Windows que sous Linux qui dépasseraient de la fenêtre. Le seul problème qui pourait rester est celui des polices.
Enfin, passer au L&F natif prend 2 lignes de code.



avatar

61

Mais 99% des apps ne les mettent pas, ces 2 lignes de code, et beaucoup de développeurs ne savent même pas qu'elles existent. sad

Et il y a aussi les développeurs qui s'amusent à packager leur skin préféré avec leurs apps, genre WordRider est livré avec Kunststoff. sick
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

62

Ah ? Lesquelles ? Ca m'intéresse smile
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

63

./62: http://java.sun.com/javase/6/docs/api/javax/swing/UIManager.html donne par exemple
[code]UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());[/code]
(encadré par try / catch, vu que ça jette une exception).
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

64

Le look est natif mais c'est quand même du dessin proprio on dirait. Regardez la différence entre les menus, et le rendu des polices (à droite, c'est netbeans, fait en java, à gauche c'est le menu avec le rendu des polices normal):

[URL=http://imageshack.us][IMG]http://img391.imageshack.us/img391/7531/img07ml7.png[/IMG][/URL]

Le contenu de la page principale utilise lui aussi une fonte bizarre avec un lissage bizarre (et franchement pas très beau comparé au reste de Windows). Le feeling est lui aussi différent, certains éléments ne réagissent pas exactement comme sous Windows (ce qui peut dérouter), l'animation et les ombres manquent, et on sent que le tout est beaucoup plus lourd à l'utilisation que n'importe quelle appli standard.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

65

D'après ce que j'avais lu il y a quelques temps, l'équipe de JAVA aurait fait pas mal d'effort pour l'intégration visuelle à Windows lors de la sortie de Vista.
A ce que j'ai compris, leur méthode de dessin glauque et bourrin - du code de merde quoi - n'était pas compatible avec Vista, et Microsoft (Hé oui il y a un support logiciel, j'espère que ça ne choquera pas KK) leur a vivement recommandé d'utiliser les API officiels ET documentés (GG les mecs de chez Sun ! tritop), ce qu'ils ont fini par faire, enfin du coup même si c'est du Java c'est quand même mieux intégré au système qu'avant normalement - y compris sous XP - et puis, justement parce que c'est du java, on ne peut pas lui demander de s'intégrer parfaitement au système, vu qu'il a plutôt été conçu pour l'inverse... Mais c'est bien là le seul cas où c'est excusable smile
Pour le coup de l'ombre sous les menus, à supposer qu'ils utilisent bien des fenêtres natives pour les menus (le contraire est difficile à imaginer, mais qui sait...) ce n'est pas compliqué à ajouter en théorie, mais tout dépend de leur code à eux. Après, pour les animations il faudrait qu'ils recodent eux même tout le fonctionnement ce qui n'est clairement pas une bonne idée happy
Concernant le lissage des polices je crois qu'ils utilisent leur propre rendu de police (à base de freetype probablement ?), en tout cas pas mal d'appli en JAVA ont un style partiel lissé + non lissé (ceci dit ça arrive aussi avec des applis natives Win32 alors qu'il faut *explicitement* le demander pour que le lissage ne soit pas appliqué triso), voir ne sont pas du tout lissées (et parfois ne proposent pas l'option pour le faire) alors que le système est réglé sur lissage des polices. (Puis de toutes façons leur lissage n'est qu'un simple anti-aliasing, pas le ClearType proposé par Windows)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

66

Non, ce n'est pas FreeType, justement un des premiers changements faits dans IcedTea/OpenJDK, c'était de remplacer leur moteur de polices propriétaire par FreeType.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

67

Pour voir si java redessine les composants à sa manière, il suffit de faire une connexion distante. C'est super lent -> il redessine, sinon non.

68

J'avais pas le temps de répondre à tous le point hier, alors voici ma spécial réponse, "Onur t'est à coté de la plaque"
onur (./1) :
Meme si tu me payais j'installerai pas cette merde... Malheureusement, le temps que les développeurs java se réveillent en remarquant qu'avec les autres langages que les votres on fait des trucs qui fonctionnent 20 fois plus vite, je suis obligé de supporter la présence de vos VM et autres trojan officiels qui essayent de me fourger les autres cacas que vous produisez.

Grosse geulante qui ne veut rien dire étant donné que tu mélange des concepts qui n'ont rien à voir comme le libre, spyware, java avec une méconnaissance claire de chacun de ces problèmes.
Je suis d'accord que proposer d'installer un logiciel avec un autre par défaut est clairement lourd surtout si l'option est coché par défaut. Mais ça ne fait pas de java un spyware loin de là ni même un adware.
Et ce que tu reproche au libre, et une pratique courante du propriétaire. D'ailleurs ici ce n'est pas un problème de libre non plus vu que cette machine virtelle de Sun que tu conspue est propriétaire. Perso je ne connait aucun logiciel libre qui fait ça alors que des propriétaire, qui le font, j'en vois plein pour ne citer que les plus connus: Microsoft et Apple.
Donc rennome vite ton topic en CDG contre "MS, Apple, Sun, le propriétaire et tutti quanti."
onur (./9) :
Depuis hier, on a la joie d'entendre qu'avec les JIT à methode de tracing, le Javascript est sur le point de devenir super rapide. Et j'en suis réjoui. Par contre du coté de Java, ça fait 10 ans que c'est lent. Tout ce que je sais, c'est qu'un applet dans une page met 10 secondes à s'initialiser, en 2008 c'est un peu la téhon. Quand on sait pas faire des VM, on spam pas les gens et on laisse le javascript prendre le dessus, puisque lui au moins, ça marche.
onur (./11) :
non, c'est un langage orienté prototype. Il est lui aussi compilé et interpreté par un VM, VM qu'ils ont optimisé comme des malades récemment justement.

Arrête de comparer deux chose qui ne sont pas comparables. La JVM Java de Sun est infiniment plus optimisée que les JVM Javascript. Même avec les amélioration prévues, le Javascript part avec 10 ans de retard sur Java en matière de JIT. le JIT existe depuis la version 1.2 et n'a cessé d'être amélioré depuis. Dans certains car les optimisation au runtime permettent même d'aller plus vite que l'équivalent natif. Je ne dit pas que tout est parfait et que Java fait tout mieux que le natif, loin de là. Je ne dit pas non plus que le Javascript est un langae pourris et que les inovations dont on parle ne sont pas un grand pas en avant.
Mais pour le moment question performance pure, par rapport à Javascript, il n'y à pas photo Java est loin devant.
Niveau temps de démarrage, ce n'est abolument pas comparable étant donné que la machine virtuelle Javascript est généralement embarquée dans l'application alors que celle java (dans le cas de l'applet vu que c'est de ça dont tu sembles parler)est démarrée en temps que plug-in.
De plus si c'est lent, ça peut-etre la faute du programmeur et pas forcément de Java. Perso, la majorité de mes programmes java(même swing) démarrent la première fois en moins de 3 secondes, et instantanément les fois suivantes.
Niveau fonctionalité ce n'est pas comparable non plus vu que Java posséde une API crossplateforme très complète, alors que Javascript ne poséde rien de tout cela inclus de base.
onur (./11) :
Je sais pas si c'est ironique mais perso les téléphones avec un VM que j'ai eu entre les mains, il faut attendre plus d'une seconde quand on appuie sur une touche dans un menu pour que ca séléctionne un autre item...
Sauf que t'est encore à coté de la plaque car les menus ne sont pas en java. Ça prouve donc au contraire qu'on peut faire tourner une JVM viable sur des téléphones tellement pourris que les menus rament alors qu'il sont codés en natifs.
Mais la encore c'est assez variable et dépend plus de la qualité du programmeur, j'ai vu pas mal de téléphone avec des performances JAVA excellentes, mais désagréables à l'utilisation à cause des menu qui rament en vice-versa. Des fois on se demande comment ils font.
Pour avoir bossé chez Gameloft qui fait des jeux sur téléphone portable, je sais de quoi je parle.
onur (./17) :
Bah le topic cest un CDG contre le libre et le pseudo-libro-propriétaire de m**** qu'est Sun.
Sauf que rien dans ton argumention n'a à voir avec le libre, et la plupart des argument contre Java montre une méconnaisance totale de ce que tu critique.
avatar

69

FsDv
ca m'affiche une dizaine de fois ce message box A CHAQUE FICHIER qu'il essaye de compiler sur C:, comme quoi il y a pas de disque dans le lecteur D. tritop Ca tombe bien, on t'a pas demandé de compiler sur D bordel.

CodeBlock, mingw, g++...
Tout ce qui passe pas par le port 80, c'est de la triche.

70

J'ai mis un CD bidon dans le lecteur, là il est content. Voilà, finalement le slogan des libristes ça devrait être:

Des logiciels de développement pro, pour construire des logiciels pro.
Tout ce qui passe pas par le port 80, c'est de la triche.

71

ah tiens je l'avais eu avec TIGCC celui là à une époque, il tenait absolument à exécuter des fichiers de mon disque C: ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

72

T'es sûr que t'as pas un makefile/assimilé foireux ? grin
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

73

onur (./69) :
ca m'affiche une dizaine de fois ce message box A CHAQUE FICHIER qu'il essaye de compiler sur C:, comme quoi il y a pas de disque dans le lecteur D. tritop.gif Ca tombe bien, on t'a pas demandé de compiler sur D bordel.
CodeBlock, mingw, g++...
Ouah! Quel joli changement de sujet sans aucun interet.

Tu essaie de prouver quoi? Qu'il peut y avoir des bugs dans un logiciel libre?
Rassure toi, on était au courant. Et puisse que tu semble découvrir plein de truc je tiens à te signaler que ça arrive aussi aux logiciels propriétaires.
avatar

74

Ximoon (./72) :
T'es sûr que t'as pas un makefile/assimilé foireux ? grin

nop, d'autant plus que j'avais regardé à l'éditeur hexa et qu'il y avait bien un chemin en C:\blabla\gcc.exe en dur dans le binaire :/
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

75

Ca aurait pu être ça puisque l'auteur du projet open source que j'essaye de compiler s'est permis des chemins absolus du genre C:/msys/... C:/Program Files/Visual Studio/VC98... top

Mais non, j'ai tout mis en relatif et il n'y a absolument rien concernant le lecteur D dans ce projet.
Tout ce qui passe pas par le port 80, c'est de la triche.

76

Zeph> ah c'est la lose ça grin Mais comme c'est open source, on peut le recompiler pour modifier ça cheeky
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

77

une petite idée du temps qu'il faut pour recompiler GCC, et de la partie de plaisir que c'est quand on est sous Windows ? grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

78

Mauvaise excuse, tu n'à qu'à installer un OS Libre !
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

79

et tutti quanti...


Il existe un os libre, codé en java ? je ne crois pas...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

80

Un OS 100% Java c'est impossible a moins que l'on face un proccésseur qui execute directement le bytecode. Et encore, sans accès direct à la mémoire, c'est mal barré pour faire un OS.
Il faudra toujours au minimum une JVM en natif.
avatar

81

Par contre on peut faire un OS qui execute qu'un JVM (comme le font si bien les constructeurs de téléphones portables qui rament)
Tout ce qui passe pas par le port 80, c'est de la triche.

82

A part quelque cas très particuliers tout l'OS est codé en natif. La JVM n'est démarrée que lorsque une appli java est lancée. Si les menu ramment c'est généralement que l'OS est codé avec les pieds. D'ailleurs les menus que l'on programmait nous même pour nos jeux en Java étaient généralement bien plus rapides que les menus systèmes, bien que souvent plus complexes.

Tu mets vraiment de la bonne volonté à te convaincre que Java est la source de tous les malheurs de l'humanité et ne pas écouter ce que j'essaie de t'expliquer.
avatar

83

Aïaïaïaïaïe. Un OS complètement codé en Java, ça ce serait assez horrible. Certains avanceront que niveau sécurité c'est bien, mais niveau performances ça ne vaut pas le coup je trouve... sick
JackosKing (./67) :
Pour voir si java redessine les composants à sa manière, il suffit de faire une connexion distante. C'est super lent -> il redessine, sinon non.

Huhu je n'avais pas pensé à ça. Encore un désavantage pour le dessin proprio.
Uther (./82) :
A part quelque cas très particuliers tout l'OS est codé en natif. La JVM n'est démarrée que lorsque une appli java est lancée. Si les menu ramment c'est généralement que l'OS est codé avec le pieds. D'ailleurs les menu que l'on programmait nous même en Java dans nos jeux etaient généralement bien plus rapide que les menus systèmes.

Ca c'est pas logique, parce que de ce que j'ai vu ce qui fait ramer c'est principalement le dessin, et ça tu n'y coupes pas vu que l'api MIDP est tellement limitée. Donc du coup sauf cas hyper particuliers (système de menus vraiment mal codé, mais ça m'étonne parce qu'à part attendre une touche et gérer le curseur il n'y a rien à faire) ton appli Java devrait être au moins aussi lente que le système. En plus, quand un téléphone est mal codé, c'est rare qu'il intègre une JVM Jazelle/JIT/AOT, mais plutôt un truc interprété façon TI-BASIC.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

84

Brunni (./83) :
Ca c'est pas logique, parce que de ce que j'ai vu ce qui fait ramer c'est principalement le dessin, et ça tu n'y coupes pas vu que l'api MIDP est tellement limitée. Donc du coup sauf cas hyper particuliers (système de menus vraiment mal codé, mais ça m'étonne parce qu'à part attendre une touche et gérer le curseur il n'y a rien à faire) ton appli Java devrait être au moins aussi lente que le système.
J'ai pas dit que c'était logique. Les OS des téléphone portables sont souvent mal codés, et c'est certainement pour cela que l'on arrive à de tels résultats. Toujours est il qu'il ne sont pour la plupart pas codés en JAVA.

avatar

85

C'est impossible de faire un jeu en Java pour téléphone portable qui dépasse les 2 FPS roll
(et malheureusement on n'a pas le choix de faire dans un autre langage)
Tout ce qui passe pas par le port 80, c'est de la triche.

86

Brunni (./83) :
En plus, quand un téléphone est mal codé, c'est rare qu'il intègre une JVM Jazelle/JIT/AOT, mais plutôt un truc interprété façon TI-BASIC.

Java est devenu un standard pour les téléphones. Même des téléphones tout pourris on des JVM JAVA. Certains de nos téléphones se programaient via une API C++. Mais plus de 95% des téléphones ont des JVM Java et non Basic ou autre. que ce soit des bête de course ou non. Si Java c'est imposé c'est surtout par sont aspect sécurisé de sandbox et c'est pour cela que l'OS n'est pas en Java mais que les appli tierces le sont.
Les écarts de performances OS/JVM s'expliquent tout simplement ca se ne sont pas les mêmes équipes qui bossent sur l'OS et la JVM.(ca ne m'étonnerait pas que la JVM soit sous-traitée)
avatar

87

onur (./85) :
C'est impossible de faire un jeu en Java pour téléphone portable qui dépasse les 2 FPS roll.gif (et malheureusement on n'a pas le choix de faire dans un autre langage)
Une fois de plus tu dis n'importe quoi sans savoir. J'ai bossé 2 ans à Gameloft et nos jeux faisaient des FPS normaux et tout à fait jouables. Après bien sur, ça varie suivant les performances, résolution, mémoire, des téléphones et il fallait adapter au cas par cas(c'était 90% de mon boulot).
Mais je peux te garantir qu'on ne sortait que des jeux jouables.

avatar

88

onur (./85) :
C'est impossible de faire un jeu en Java pour téléphone portable qui dépasse les 2 FPS roll
(et malheureusement on n'a pas le choix de faire dans un autre langage)

Si c'est possible. Sur mon téléphone Nokia 6300 (et son processeur ARM9 @ 240 MHz) tu peux atteindre jusqu'à 30 fps en fullscreen 320x240 (~30 ms pour blitter l'écran, dont 15 sont "gratuitement" disponibles pour dessiner autre chose, mais gaspillées si tu ne fais rien). Peut être qu'avec l'API Nokia DirectGraphics, il serait possible de faire mieux.
Cela dit c'est vrai que c'est dommage de ne pas avoir C++ comme choix. On prône la portabilité, mais ne venez pas me dire ça ne nivelle pas tout vers le bas. C'est pour ça que parfois je préfère des trucs non-multiplateforme mais bien faits que des trucs multiplateforme (tels que OOo) mais avec des choix ergonomiques non adaptés et qui n'ont pour seule excuse "la portabilité".
Uther (./86) :
Brunni (./83) :
En plus, quand un téléphone est mal codé, c'est rare qu'il intègre une JVM Jazelle/JIT/AOT, mais plutôt un truc interprété façon TI-BASIC.

Java est devenu un standard pour les téléphones. Même des téléphones tout pourris on des JVM JAVA. Certains de nos téléphones se programaient via une API C++. Mais plus de 95% des téléphones ont des JVM Java et non Basic ou autre. que ce soit des bête de course ou non. Si Java c'est imposé c'est surtout par sont aspect sécurisé de sandbox et c'est pour cela que l'OS n'est pas en Java mais que les appli tierces le sont.
Les écarts de performances OS/JVM s'expliquent tout simplement ca se ne sont pas les mêmes équipes qui bossent sur l'OS et la JVM.(ca ne m'étonnerait pas que la JVM soit sous-traitée)

Hum je ne disais pas que les téléphones utilisaient le Basic hein, je disais juste que les performances de certaines JVM interprétées (comme celle du Motorola d'un pote) sont presque comparables au TI-BASIC ^^ alors que sur d'autres téléphones au contraire il est nettement préférable d'avoir un code lourd qui te permette de limiter au maximum tout ce qui est affichage.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

89

Ok.

Oui c'est dommage pour le C++ car apparemment (cf ./87) meme en Java ils adaptent, donc autant adapter du code C++ avec des modifs ça et là pour les parties machine-dependent.

edit: en fait, j'ai jamais vu de jeu sur tél. portable qui dépasse 2 FPS, mais je m'y intéresse pas particulièrement faut dire. Content de savoir que les perfs sont meilleurs maintenant.
Tout ce qui passe pas par le port 80, c'est de la triche.

90

En fait comme je l'ai dit si java c'est imposé plutôt que C++, c'est surtout pour l'aspect sécurité.
L'aspect "Write Once Run Anywhere" aurait été interessant, mais autant ça marche pas trop mal pour JEE et JSE autant pour JME, ce n'est pas vraiment ça. La plupart des JVM n'ont pas un comportement identique et sont buggées ce qui oblige a reprendre le code pour l'adapter à la plupart des téléphones.
avatar