Articles précédents : Articles
- [28] Montage vidéo sous Linux (Kino)
- [121] Linux est partout ?
- [53] Mise en place du Réseau Indépendant d'Hébergeurs Autogérés
- [8] RobotCup 2003
- [25] The Demo Effects Collection : Effets old school en GPL
- [13] Cinquième journée du libre : « Le poste de travail alternatif »
- [55] Newham et Nottingham envisagent la migration de plus de 10.000 postes vers Linux
- [6] ADAE - Annonce de futurs appels d'offres
- [11] Pétition : Un pilote pour le chipset WiFi de Texas Instrument
- [43] Les aventures en mp3 continuent
Liens connexes
- Glow - client collecticiel du groupe Ooo (3401 hits)
- Projet collecticiel de OpenOffice.org (1023 hits)
- OSAF (GNU/GPL) (450 hits)
- Minkowsky client-serveur (GNU/GPL) (551 hits)
- TWIG (GNU/GPL) (508 hits)
- Skriv (GNU/GPL) (464 hits)
Dépêche modérée par
Articles : 1ère mouture du collecticiel client de OpenOffice.org : Glow
Posté par ginkyo (page perso, ). Modéré le 10 juin 2003.Glow 0.1 est la première mouture publique du collecticiel client de OOo, sortie le 7 juin 2003.
Licence : LGPL/SISSL
Langage : 100 % java
Ci-dessous, lien vers d'autre groupiciels
NdM : le groupe s'appelle OOogw pour faire simple. L'outil se base sur XML, et le développement collabore avec Mozilla Calendar et PHPGroupWare.
Glow - client collecticiel du groupe Ooo (3401 hits)
Projet collecticiel de OpenOffice.org (1023 hits)
OSAF (GNU/GPL) (450 hits)
Minkowsky client-serveur (GNU/GPL) (551 hits)
TWIG (GNU/GPL) (508 hits)
Skriv (GNU/GPL) (464 hits)
> Lire la dépêche (103 commentaires, moyenne: 1,7).
-espère sortir au cours de ce mois, un serveur de calendrier (ou régeste ?) publique (WCAP)
-appel aux rapports de bogue, suggestions, code
-espère que des développeurs et/ou entreprises apportent leur aide
-attend développeurs et/ou entreprises pour travailler sur la section (non développées pour le moment) courrielleur, messagerie instantanée, gestion de fichiers avec support de Webdav.
collecticiel n. m.
Logiciel qui permet à des utilisateurs reliés par un réseau de travailler en collaboration sur un même projet.
synonyme(s) : synergiciel n. m., groupiciel n. m.
source : gdm, granddictionnaire.com
Autre liens de collectitiels (yavaitplusdeplace) :
Kroupware (GNU/GPL)
http://pim.kde.org/development/kroupware.php
Ximian Evolution (GNU/GPL) + Connector (module proprio de connection à MS Exchange )
http://ximian.com/products/evolution/
http://ximian.com/products/connector/
phpGroupWare (GNU/GPL)
http://www.phpgroupware.org/
Si vous avez d'autre liens et des commentaires sur les collectiels que vous avez pu rencontrer et/ou installer : lachez-vous ! :)
(Précisez bien si ce sont des clients ou des serveurs ou les deux. NdM : en client lourd ou léger/web et puis la licence)
Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
> Langage : 100 % java
Ouch ! deja que 00 ce n'est pas leger leger, si en plus on rajoute java , ca va exploser !
-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par superpop () le 10/06/2003 à 13:21. (lien). Évalué à -7.Oué c'est vraiment dommage que ca soit en java ...ca aurait pu etre interessant sinon ..
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Sami Dalouche (page perso, ) le 10/06/2003 à 13:25. (lien). Évalué à 1.autant pour J2EE, pas de probleme pour java, c'est plus rapide, mais alors java / swing ca va vraiment etre beurk...
pourquoi ne pas faire du java avec bindings gtk/gnome ? ou meme swt a la limite, ca sera toujours mieux que swing....
enfin bon, il faut se dire que des framework vont etre constuits, ca parle de serveur de calendriers, etc, ensuite ca donnera envie aux gens de programmer des trucs propres (gnome, kde)
sam-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Sebastien Guillemin (page perso, ) le 10/06/2003 à 16:37. (lien). Évalué à 1.pourquoi ne pas faire du java avec bindings gtk/gnome ? ou meme swt a la limite, ca sera toujours mieux que swing....
Sur le long terme c'est à voir... Il me semble me rappeler que pour le JDK 1.5 les interfaces Swing pourrait prendre avantage de l'interface native (et plus seulement utiliser un look and feel ressemblant).
Dans ce cas, il faudra voir ce que çà donne, mais çà peut être judicieux de ne pas s'engager dans un autre toolkit... tout de suite.-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Christophe GRAND (page perso, ) le 10/06/2003 à 17:38. (lien). Évalué à 4.Sur le long terme c'est à voir... Il me semble me rappeler que pour le JDK 1.5 les interfaces Swing pourrait prendre avantage de l'interface native (et plus seulement utiliser un look and feel ressemblant).
Dans ce cas, il faudra voir ce que çà donne, mais çà peut être judicieux de ne pas s'engager dans un autre toolkit... tout de suite.
D'un autre point de vu sur le long terme, en misant sur une évolution du JDK1.5 tu t'inscris encore plus dans une relation de dépendance vis-à-vis de Sun et comme c'est pas de si tôt que l'on aura un JDK1.4 ou + libre...
Sur le long terme c'est la solution faisant intervenir le plus de solutions libres|ouvertes qui gagne.
-
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Thomas MARTIN (page perso, ) le 10/06/2003 à 15:51. (lien). Évalué à 7.Par rapport à la légèreté, ne serait-il pas souhaitable, justement, que OOo fasse la même chose que mozilla, à savoir séparer les composants pour avoir plusieurs binaires et faire un peu moins usine à gaz.
quel est le con qui a trouvé collecticiel ?
franchement pour trouver plus moche cela va être dur
ok je sors
-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par gilles renault (page perso, ) le 10/06/2003 à 14:04. (lien). Évalué à 2.logiciel collaboratif c'est pas mal, mais c'est plus long.
--
Vous venez de mourir pour la troisième fois. Perte d'adhérence aggravée par des pneus trop étroits.-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par redguts () le 10/06/2003 à 15:00. (lien). Évalué à 1.collotiel?
non, ça fait penser à un gratte-ciel mal lavé
groupociel?
non, ça ne sonne pas bien
bandaciel?
euh... faut pas avoir l'esprit mal tourné
meutociel?
nan : trop 'zyva'
polyciel?
ah ouais, j'aime bien-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par Glenn Y. R. (Jabber id, page perso, ) le 10/06/2003 à 19:13. (lien). Évalué à 7.Comme dirait Sarko, les polyciels c'est en général des composants des commissariels... (ou des brigadiciels)
-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par zyglotron () le 10/06/2003 à 21:29. (lien). Évalué à 7.Pour reprendre l'expression longue "logiciel collaboratif" on pourrait parler de collabociel.
Et pourquoi pas de synerciel ou synergiciel, c'est censé générer de la synergie ce genre de logiciel :o)
"On a du redémarrer la centrale synergicielle" ça fait bien accompagné d'un "J'ai réazimuté le zyglotron" quand le client vous demande ce qui n'allait pas :o)-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par inisheer () le 11/06/2003 à 07:16. (lien). Évalué à 2.attention, collabotiel ca rappelle de mauvais souvenirs...
[-1] ce monde est sans pitié-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par Pierre Jarillon (page perso, ) le 11/06/2003 à 18:42. (lien). Évalué à 1.Pourquoi pas groupiciel ?
-
[^]Re: quel est le con qui a trouvé collecticiel ?
-
-
-
-
-
-
-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par Gniarf () le 10/06/2003 à 14:45. (lien). Évalué à 2.c'est vrai que c'est franchement laid.
--
Windows has no users. It has hostages.-
[^]Re: quel est le con qui a trouvé collecticiel ?
Posté par Jeff () le 11/06/2003 à 12:10. (lien). Évalué à 1.Moi je propose un concours de nouveaux noms de types de logiciels! (c recherché ça comme thème, non?) Ok, je commence... euh... ... zomblahiciel! Voilà! euh... par contre je sais pas du tout à quoi ca sert... :/ Allez, candidat suivant Simone? :)
-
Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Et ça marche !
Allez, quelques srishoutes : http://seb.ouvaton.org/tmp/(...)
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Aurélien Girard () le 10/06/2003 à 15:28. (lien). Évalué à 3.J'aime beaucoup le "Copyright 2002" sur http://seb.ouvaton.org/tmp/glow.png(...)
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Jean-Pierre Schwickerath (page perso, ) le 10/06/2003 à 16:46. (lien). Évalué à 2.Ben disons qu'à première vue cela ressemble beaucoup au "module" Rendez-vous de Star Office 5.2.
Je suppose qu'ils ont repris des parties que Sun avait programmées / rachetées de Star.
C'est pour moi le signe que je vais pouvoir me séparer de Star Office que je n'ai gardé qu'à cause de la gestion des rdv. que j'utilisais.--
Nothing's impossible... Everything's relative!
-
Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
J'aime beaucoup le premier lien : ils expliquent qu'ils ont choisi la bonne technologie.
"Work with the right technologies - use Java:"
LA ou ça devient intéressant c'est quand on voit que la "bonne technologie" n'a strictement rien à voir avec OOo.
Donc Glow n'a rien à voir avec OOo, ca sera juste un bidule lourdingue (Java oblige) et mal intégré.
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 10/06/2003 à 14:49. (lien). Évalué à 2.Quand on voit qu'OOo n'est lui-même pas intégré aux bureaux existants (à quand une version gtk ?), on se dit que c'est mal barré pour avoir une suite bureautique intégrée qui n'ait pas l'air totalement dépareillée. Heureusement qu'Abiword, Gnumeric et Evolution continuent de s'améliorer...
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par LupusMic (page perso, ) le 10/06/2003 à 15:06. (lien). Évalué à 6.Quand on voit qu'OOo n'est lui-même pas intégré aux bureaux existants
Le problème est que OOo est un bureau ! Il suffit de rajouter un gestionnaire de fenêtre, et tu as un environnement bureautique complet, avec client mail et navigateur internet.-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Adrien (page perso, ) le 10/06/2003 à 15:19. (lien). Évalué à 3.Ouais ils ont copié Emacs quoi...
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Nÿco (Jabber id, page perso, ) le 10/06/2003 à 15:26. (lien). Évalué à 0.Ouais ! On se fait un petit JEmacs en Java ?
--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Erwan (page perso, ) le 10/06/2003 à 15:39. (lien). Évalué à 1.Ca c'etait StarOffice avant le passage en GPL ! Il y avait meme un bouton demarrer, dis donc. Mais c'est finit.
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Matthieu Moy (page perso, ) le 10/06/2003 à 14:57. (lien). Évalué à 1.> Donc Glow n'a rien à voir avec OOo, ca sera juste un bidule lourdingue (Java oblige) et mal intégré.
Il y a au moins un point commun : Le copyright SUN. C'est donc un truc qui sera à priori intégré à StarOffice, avec une jolie boite à la FNAC, un installeur commun avec OOo ou SO, ... Un argument de moins pour "OO, c'est null, y'a pas d'agenda, alors qu'avec MSOffice, y'en a un", ...
Techniquement, je ne sais pas si ça apportera grand chose, mais au niveau marketing, c'est une bonne chose.
D'autres collecticiels
Exchange4linux: http://www.billworkgroup.org/billworkgroup/home(...)
Serveur Exchange sous Linux écrit en Python. GPL mais le module client est payant.
Direto: http://www.direto.org.br/(...)
Aucune idée (le site est en protugais)
Desknow: http://www.desknow.com/(...)
Serveur de communication proprio. La version normale est gratuite, la version pro payante.
Mimerdesk: http://www.mimerdesk.org/(...)
Groupware passant par une interface web. Ecrit en Perl sous GPL
PHPProjekt: http://www.phprojekt.com/(...)
Groupware web écrit en PHP. GPL
MoreGroupware: http://moregroupware.sourceforge.net/(...)
Tout pareil, Web, PHP, GPL
Group-Office: http://www.hilckmanngroep.com/sourceforge/(...)
Idem.
Samsung Contact: http://www.samsungcontact.com/en/(...)
Clone Exchange tournant sous Linux. Proprio, payant.
phpGroupWare: http://www.phpgroupware.org/(...)
Groupware web écrit en PHP. GPL
-
[^]Re: D'autres collecticiels
Posté par Gonéri Le Bouder (Jabber id, page perso, ) le 10/06/2003 à 14:25. (lien). Évalué à 5.Il y a aussi kgroupware qui semble prometteur.
http://kroupware.kde.org(...)
Il est prévu une intergration de kmail, kaddressbook, knode, etc
Des captures d'écran
http://kroupware.kde.org/screenshots.html(...)
Et la faq
http://kroupware.kde.org/faq/faq.html(...)--
apt-get moo-
[^]Re: D'autres collecticiels
Posté par vga1523 () le 11/06/2003 à 09:47. (lien). Évalué à 1.j'installe kolab en ce moment (la partie client c'est déroulée sans prb), apache me donne du mal.
je suppose que tout ceci cera intégré à kde 3.2 ??
qui d'autre à testé ?
est il possible de synchroniser le sony ericson p800 avec un groupware du type kolab ou phpgroupware ?
-
-
[^]Re: D'autres collecticiels
Posté par LupusMic (page perso, ) le 10/06/2003 à 15:09. (lien). Évalué à 1.GPL mais le module client est payant.
Mais vu que c'est compatible exchange, ne pourrais-t-on pas utiliser Evolution ? (malgré son épaisseur ;) )-
[^]Re: D'autres collecticiels
Posté par Yusei (page perso, ) le 10/06/2003 à 15:22. (lien). Évalué à 2.Le plugin Exchange d'Evolution était payant _et_ proprio, c'est pas forcément rentable.
-
[^]Re: D'autres collecticiels
Posté par free2.org (page perso, ) le 10/06/2003 à 15:31. (lien). Évalué à 1.je crois qu'il suggère d'utiliser le serveur exchange GPL avec le client evolution GPL pour faire une solution 100% GPL et compatible exchange
-
[^]Re: D'autres collecticiels
Posté par Yusei (page perso, ) le 10/06/2003 à 15:49. (lien). Évalué à 1.Soit j'ai rien compris soit pour accéder au serveur exchange GPL il faudra le plugin exchange pas-gpl d'evolution...
-
[^]Re: D'autres collecticiels
Posté par free2.org (page perso, ) le 10/06/2003 à 16:55. (lien). Évalué à 1.je crois avoir compris:
la question suivante est: est-ce que le serveur exchange GPL est compatible avec des standards comme smtp, ical, etc. auquel cas il peut peut-etre communiquer à la fois avec des clients GPL smtp/ical et des clients propriétaires de type Exchange
ce serait une solution + économique que d'acheter le Ximian Connector non libre
-
-
-
-
[^]Re: D'autres collecticiels
Posté par PsychoFox () le 11/06/2003 à 06:39. (lien). Évalué à 1.en fait, ce qui est appelé "module client" est le connector pour outlook :
You can download the exchange4linux Outlook(TM) Connector for Outlook 97 - 2000 by http at the following site:
exchange4linux-outlook2000-setup-2.3.10.exe (MAY-30-2003)
You can download the exchange4linux Outlook(TM) Connector for Outlook XP by http at the following site:
exchange4linux-outlookxp-setup-2.3.10.exe (MAY-30-2003)
Le client c'est outlook :
N&H received more and more customer requests asking for a independent workgroup server solution running under LINUX, but using MS-Outook(TM) as the Client on the MS-Windows(TM) Desktop for use with shared calendars and task lists, etc, and not limited to e-mail. MS-Outlook(TM) uses a MAPI Service Provider to store workgroup data centrally in MS-Exchange(TM) database or other 3rd party messaging servers.
s'il faut déja un connector pour pouvoir utiliser outlook, ça risque d'être dur d'utiliser evolution. En fait, c'est juste une solution pour les boites qui veulent un serveur exchange à pour moins cher.
-
-
[^]Re: D'autres collecticiels
Posté par Rozé Etienne () le 11/06/2003 à 08:50. (lien). Évalué à 1.Il y a aussi les outils basés sous Zope, par exemple Plone.
(http://www.plone.org/(...) ) Je n'est pas testé...
Tous ces liens donnés sont certainement intéressant. Mais est-ce que quelqu'un connaitrait un document ou un site qui comparerait ces logiciels et leurs fonctionnalités. Il faudra que je le fasse mais si c'est déjà fait...
-
[^]Re: D'autres collecticiels
-
[^]Re: D'autres collecticiels
Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
erreur dans le titre : "Articles : 1ère mouture du collecticiel client de OpenOFfice.org : Glow "
2 'f' a Office
Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Petite erreur générale de tout le monde :)
java n'est pas lent ! ca dépend de comment on programme !
Pour preuve :
http://arkanae.tuxfamily.org/fr/index.html(...)
http://www.eclipse.org(...)
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 10/06/2003 à 15:28. (lien). Évalué à 2.Dans cette optique, Perl n'est pas lent non plus.
Pour preuve : Frozen Bubble.-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (page perso, ) le 10/06/2003 à 20:42. (lien). Évalué à 2.C'est sûr que Frozen Bubble est un super exemple. Il marche très bien en 100% pur Java alors que pour Perl, c'est basé sur SDL (programmé en C). Et c'est sûr que le rendu graphique de Frozen Bubble est comparable à celui de Arkanae.
Ceci étant, par dela le ridicule total de cette comparaison, je ne vois pas le problème. Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces. La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu, contrairement à OpenGL for Java. SWT d'IBM est déjà beaucoup mieux.
C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 10/06/2003 à 22:54. (lien). Évalué à 0.Il marche très bien en 100% pur Java alors que pour Perl, c'est basé sur SDL
Ah, les sprites FB sont affichés pixel par pixel en "100% pur Java", peut-être ? Il n'y a pas la moindre bibliothèque en-dessous ? Je suis scié.
Et c'est sûr que le rendu graphique de Frozen Bubble est comparable à celui de Arkanae.
On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.
Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial. M'enfin, chacun son truc.
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?
Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.
Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.
Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.
C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.
Là pour le coup question pertinence tu fais très fort :)-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Keos () le 11/06/2003 à 10:18. (lien). Évalué à 3.M'enfin Master-dick est toujours le premier à taper sur du Java...je me souvient d'une phrase genre "VB ou Java, enfin un langage de neuneu quoi"....ca m'a fait bien rire....quel objectivité.....
C'est vrai que Swing est affreusement lent...mais je pense que ce que BouBou voilais dire c'est que Java c'est bien pratique quand il faut faire du cross platform...il est clair que comme OpenOffice est dispo sur +sieurs platform, glow doit l'etre aussi....alors oui on peux faire du cross platform en C++ ( il est pour neuneu celui la au fait ??? nan juste pour savoir, j'ai un peu de mal) mais c'est souvent aussi lait que le langage lui-meme ( meme RMS le dit ;)...et puis OpenOffice quel belle exemple de _SUPER_RAPIDITE_(tm) ;)
Sa me gave de voir que dans une communauté qui se veut ouverte on assiste a de telle fermeture d'esprit....m'enfin
Les gas faut arréter, vous devenez aussi binaire que vos machine....
(Suze c mal, login c mal, Java c mal tm)-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 11/06/2003 à 11:11. (lien). Évalué à 0.Hé ben, pour une fois que je ne tapais pas sur Java... ;)
je me souvient d'une phrase genre "VB ou Java, enfin un langage de neuneu quoi"
J'ai dit ça ? Je devais être dans un grand jour :-))
Ceci dit, et tout troll mis à part, les interfaces graphiques réalisées en Visual Basic répondent en général bien mieux que celles faites en Java. (et pour appeler des routines externes, VB s'interface naturellement avec COM)-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Keos () le 11/06/2003 à 13:01. (lien). Évalué à 0.<blockquote> Ceci dit, et tout troll mis à part, les interfaces graphiques réalisées en Visual Basic répondent en général bien mieux que celles faites en Java. (et pour appeler des routines externes, VB s'interface naturellement avec COM) </blockquote> ouai c'est bien vrai...
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (page perso, ) le 11/06/2003 à 16:38. (lien). Évalué à 1.Ah, les sprites FB sont affichés pixel par pixel en "100% pur Java", peut-être ? Il n'y a pas la moindre bibliothèque en-dessous ? Je suis scié.
Tu es vraiment d'une mauvaise foi consternante. Tu sais très bien que seul le C affiche les pixels de façon directe, et encore, la plupart des drivers contiennent de l'assembleur. D'autre part, tu sembles oublier (ou ne pas connaître) plusieurs choses.
D'abord, Frozen Bubble version Java est écrit en AWT pour être compatible avec java 1.1. Les sprites sont gérés avec drawImage, qui était l'api de plus bas niveau en Java (ce n'est plus cas avec les versions récentes). L'appel Java est traduit en un appel natif de la bibliothèque graphique sur laquelle AWT est construit (par exemple Motif sous Unix). Il n'y a donc pas de différence notoire entre un programme Java et un programme C utilisant motif. Et les performances de FB en Java prouvent qu'on peut très bien faire de l'utilisable avec la version 1.1 en Java pur, tout aussi pur que n'importe quel programme dont l'affichage est géré par X11 (ou d'ailleurs par windows, ça revient au même). Il existe très peu de toolkits qui parlent directement le protocole X, par exemple. Ils utilisent en général la XLib.
D'autre part, il existe depuis la version 1.4 de Java une api d'accès direct à la mémoire vidéo qui permet d'être encore plus pur Java, puisqu'on court-circuite le toolkit.
Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple. Trouver là dedans une preuve des performances de Perl est bien sur ridicule (ce que tu ne sembles pas nier), mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.
On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.
Absolument pas, cf supra. SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances. Peut-on faire ça en Perl avec un rendu aussi complexe que celui d'arkanae ?
Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial.
Et alors ? C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres ? Le rendu d'arkanae est plus complexe que celui de Frozen Bubble, qu'il soit inférieur à celui de Doom III ne change rien à ça.
C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?
Où est-ce que tu vois que je ne fais pas le raisonnement pour les autres langages ? De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.
Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.
Je n'ai jamais dit ça, bien que une non relecture de ma phrase ait provoqué l'apparition d'un mot inutile (implémenter). Je voulais dire "il est logique d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.", ce qui n'a aucun rapport avec les interfaces graphiques, mais la réutilisation de ce qui se fait de bien. Sinon, je ne considère pas Perl comme un langage de haut niveau.
Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.
Pour l'aspect logique, cf plus haut. Sinon, oui, Python et Ocaml sont d'excellents langages qui sont interfacés avec des bibliothèques efficaces en C. Et alors ?
Là pour le coup question pertinence tu fais très fort :)
En tout cas, je n'atteinds pas ton niveau de mauvaise foi.-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 11/06/2003 à 17:00. (lien). Évalué à -1.Tu sais très bien que seul le C affiche les pixels de façon directe
Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple.
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Trouver là dedans une preuve des performances de Perl est bien sur ridicule
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres
Oh rien, je ne fais que sous-entendre que manipuler quelques dizaines de triangles simultanés ne doit pas être trop lourd pour une machine moderne, même avec un langage poussif... Et comme la complexité graphique du rendu (texturages, etc.) est dévolue à OpenGL ou à l'accélération matérielle, cela ne rentre de toute façon pas en ligne de compte dans le travail dévolu à Java.
Le rendu d'arkanae est plus complexe que celui de Frozen Bubble
Sans définition de la "complexité" d'un rendu cela ne veut pas dire grand'chose de chercher à comparer 2D et 3D. Et puis, après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot. Mais bon, si ça peut te permettre d'évacuer un excédent de fougue :)-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (page perso, ) le 11/06/2003 à 17:50. (lien). Évalué à -1.Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?
Ca veut dire que le programme est écrit entièrement en Java et utilise un toolkit écrit en C. Tu es stupide ou tu le fais exprès ? Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ? Et donc qu'il y a beaucoup plus de C dans Frozen Bubble Perl que dans la version Java ?
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Ca commence a devenir clair dans ma tête, tu le fais exprès... Mais comme je suis charitable, je t'explique : si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame. Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances. Mais visiblement, tu ne veux pas comprendre, alors bon...
après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot
Mais tu es vraiment crétin, c'est ça ? Aucun langage autre que le C (et encore), n'utilise le hardware moderne de façon native. Tu es trop bête pour comprendre ça, c'est ça ton problème ? Les drivers sont programmés en C et en assembleur, puis on ajoute une couche du langage cible. C'est la vie.
Actuellement, l'impression de lenteur associée à Java est presque exclusivement liée à trois choses : l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage) qui donne l'impression que ça rame sur une machine avec une mémoire sous dimensionnée, le temps de chargement (lié au fait que Sun n'a toujours par prévu la sauvegarde du code byte compilé pour les bibliothèques de base) et surtout swing. Nous sommes plusieurs a essayer de t'expliquer que swing pose problème, pas Java, avec des exemples de couches d'abstraction mieux conçues comme SWT ou comme Open GL for Java. Mais comme tu te comportes comme un crétin, tu ne veux pas comprendre. J'abandonne.-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 11/06/2003 à 19:15. (lien). Évalué à -1.Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ?
Non, je ne vois pas la différence, puisque conceptuellement il n'y en a aucune.
Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie. Heureusement que tu finis tous tes messages en disant que tes interlocuteurs sont de mauvaise foi :-)
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame
C'est marrant : pour une fois que je ne dis pas cela, tu te mets en tête de le réfuter. C'est une obsession chez toi ?
Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Mais tu es vraiment crétin, c'est ça ?
Je ne veux pas t'imiter dans l'insulte, mais j'impression que c'est toi qui est trop crétin pour comprendre que :
- je suis d'accord depuis le début que les primitives graphiques sont codées en natif
- c'est précisément l'argument que j'employais pour dire que le "rendu complexe" (je rigole doucement) d'Arkanae ne prouvait rien quant aux performances de Java
l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage)
Voici une URL intéressante :
http://internalmemos.com/memos/memodetails.php?memo_id=1321(...)
C'est supposément un mémo interne Sun Microsystems. Voici un passage qui concerne l'occupation mémoire de Java (les chiffres sont crédibles et restent à peu près valables à mon avis) :
« Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%. »-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (page perso, ) le 11/06/2003 à 20:32. (lien). Évalué à -1.Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Quand tu sous-traites quelque chose (par exemple l'affichage) à un ebibliothèque implémentée en C et en assembleur, celle-ci est destinée à te faire gagner du temps (ça va, tu as compris jusqu'ici ?). Plus la bibliothèque est bien faite, plus elle te fait gagner du temps (exemple, en SDL tu peux demander à la bibliothèque de bouger un sprite, le tout implémenté en C et en assembleur) (tu suis toujours ?). De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage (pas de problème ? Je peux répéter, si tu veux). Donc, meilleure est la bibliothèque (en C), moins les performances de l'autre langage influent sur les performances globales. Normalement, tu devrais comprendre, maintenant.
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie.
Ca me semble cohérent, quel est le problème ? Je vais préciser, parce que tu sembles en mauvaise forme ce soir. Swing est une couche 100% Java ajoutée par dessus le toolkit de la plateforme cible. Il ne bénéficie que très peu du dit toolkit (sous linux en tout cas) car presque tout est ré-implémenté (ascenceur, gestion du focus, etc.). De plus, il y a des problèmes dans la gestion des pipelines graphiques, quelques erreurs de conception (reconnues par Sun et en cours de correction) etc. Bref, ça rame, tout le monde est d'accord. Le concurrent SWT d'IBM ne rame pas. Il n'est pas aussi réactif qu'une interface en C, je suis d'accord, mais il est tout à fait utilisable, même sous linux. Ca prouve qu'on peut faire un toolkit Java correct. Qu'il soit basé sur du C ne pose aucun problème, c'est le cas de tous les langages. Enfin, AWT n'est pas génial pour faire des jeux, car même s'il rame moins que swing (il y a une couche en moins), il est très loin d'offrir les fonctionnalités évoluées de la SDL. Il est donc remarquable (au sens de notable, pas au sens de formidable) que Frozen Bubble fonctionne bien malgré l'utilisation de l'AWT.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Fais un effort, je pense que c'est à ton niveau.
Je ne veux pas t'imiter dans l'insulte
Quelques exemples (c'est moi qui souligne) :
C'est une incapacité à comprendre la relativité d'un argument ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
tu persistes avec cet argument idiot
Quant à ton memo, il est amusant. Evaluer l'empreinte mémoire avec HelloWorld, c'est sur puissant. Comparer un langage comme Sather dont le support du parallelisme très limité (par rapport à Java) et dont l'aspect dynamique est inexistant à Java est aussi tout à fait fair play et de bonne foi (pareil pour Eiffel sur l'aspect dynamique). Pour la comparaison avec Python, je ne me prononce pas, je ne connais pas assez bien trois choses : la part des bibliothèques qui sont écrites en C (ce qui limite toujours l'occupation mémoire), l'aspect multi-thread et le niveau de reflexivité/introspection.-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 11/06/2003 à 21:00. (lien). Évalué à -1.Donc, meilleure est la bibliothèque (en C), moins les performances de l'autre langage influent sur les performances globales.
Non, n'importe quoi. Si l'overhead apporté par la bibliothèque est moins important, alors l'influence du reste est plus importante relativement au total (c'est des maths, tu sais). Et puis, apprends à lire les messages auxquels tu réponds, tu t'enfonces dans un argumentaire qui vient d'être réfuté pour la troisième fois. Pas que je me lasse...
Evaluer l'empreinte mémoire avec HelloWorld, c'est sur puissant
Oh, ils ne parlent pas que de ça, il suffit de savoir lire. Et puis, HelloWorld permet justement de mesurer l'overhead minimal (coût fixe) de l'environnement d'exécution. Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))
Quelques exemples (c'est moi qui souligne) :
Tu ne sembles pas comprendre la différence entre dire qu'un argument est "idiot" (ce qui se conçoit rationnellement) et dire qu'une personne est "crétine" (ce qui est de l'ordre de l'appréciation subjective et du dénigrement de bas étage). Je m'en fiche un peu, c'est juste que ça ne rend pas tes interventions très crédibles...
Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)
Same player, shoot again ?-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (page perso, ) le 11/06/2003 à 22:02. (lien). Évalué à -1.Non, n'importe quoi. Si l'overhead apporté par la bibliothèque est moins important, alors l'influence du reste est plus importante relativement au total (c'est des maths, tu sais).
Tu confonds évaluation théorique et réalité pratique, ce qui est très génant pour un jeu. Ce que l'utilisateur voit, c'est la fluidité du jeu, en gros le nombre de frame par seconde. Quand ça tombe en dessous d'un certain niveau, c'est injouable. A partir d'un autre niveau, on ne voit plus la différence. Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence. Si ta bibliothèque C est bien faite, comme c'est le cas de SDL, tu peux facilement dépasser très largement le minimum syndical. Que le reste de l'application rame un peu ne change pas grand chose car cela représente une part infime des performances de la dite appli. Tu as parfaitement raison de dire que l'influence relative du langage est plus importante quand la bibliothèque est bien faite, mais on s'en fout. L'importance relative n'est pas directement perçu par l'utilisateur, c'est la réactivité de l'ensemble qui compte. Quand tu programmes avec une bibliothèque comme SDL ou OpenGL qui te permets de garantir (ou presque) de bonnes performances, le reste importe peu. A contrario, quand tu utilises une bibliothèque mal faite, il te reste une part très faible du temps CPU disponible entre deux frames et les performances du code utilisé à ce moment sont cruciales pour l'interactivité du jeu. C'est le même problème pour swing. L'utilisateur qui doit attendre une demi-seconde la première fois qu'il clique sur un menu parce qu'il faut byte-compiler la sur-couche swing d'une vague fenêtre motif va être assez ennervé, même si les fonctions complexes déclenchées par le GUI sont exécutées très rapidement.
il suffit de savoir lire
Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation., mais ça, tu ne risques pas de le citer, n'est-ce pas...
Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))
Tu ne sembles pas savoir que la J2ME a une occupation mémoire très faible (beaucoup plus faible que celle de la J2SE dont il est question dans ton mémo). L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi. D'autre part, je maintiens que la mémoire ne coûte rien sur un PC et donc que les problèmes de la J2SE ne sont pas si graves que ça.
Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)
Oui oui, bien sûr. C'est marrant, mais ayant développé (en C) la gestion du son et la version 2 du pathfinding de freecraft (pas la version 3, je l'avoue), j'avais l'impression d'avoir une vague idée de ce qu'est un jeu. Je pensais aussi que la lecture régulière de gamasutra m'aidait un peu dans cette compréhension. Mais apparamment non, j'ai un manque chronique de connaissances en la matière (j'aime bien les insultes polies, ça m'a toujours fait beaucoup rire. Je suis plus direct, en général, mais bon, je respecte l'art de l'insulte polie). D'autre part, tu devrais relire https://linuxfr.org/comments/221368.html(...) Peut être que tu ne comprends pas ma première phrase, mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Allez, va, c'est ma dernière réponse, je ne peux pas lutter contre un grand réfutateur d'argument qui connaît si bien le jeu vidéo.-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 11/06/2003 à 22:45. (lien). Évalué à -1.Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence
D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)
A propos de fps, un autre intervenant a posté des chiffres factuels sur les performances d'un Quake en Java. Je suis sûr que tu auras à coeur de trouver de multiples excuses aux performances pour le moins faiblardes de cette version (largement inférieures à 50 fps). Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.
Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation
Sauf que les chiffres cités pour Solaris sont à peu près égaux à ceux cités ici par d'autres personnes en ce qui concerne Linux (et que tu n'as pas contestés).
D'autre part, je maintiens que la mémoire ne coûte rien sur un PC
Le mémo que je citais (oui, encore une fois) ne parlait pas que de HelloWorld. Il constatait aussi que l'occupation mémoire augmentait beaucoup plus avec la taille des données en Java qu'en Python. De plus l'occupation mémoire a des coûts en terme de performances (cache miss, etc.).
Surtout, tu confonds deux choses : le coût de la mémoire, et la volonté qu'ont les utilisateurs potentiels d'upgrader la mémoire de leur machine. Si une seule appli se met à ramer parce qu'elle a besoin de trop de mémoire, les gens ne vont pas ajouter une barrette (c'est de toute façon au-delà de leurs compétences pour la majorité), ils vont simplement trouver que l'appli n'est pas performante.
L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi.
J'ai surtout l'impression que les applis présentes sur un téléphone portable, et les contraintes d'utilisation y afférentes (vu l'ergonomie désastreuse du bidule, pas besoin d'un temps de réaction < 100ms), font que les performances ne sont pas vraiment cruciales sur ce genre de produits. De plus, ces applis ne sont pas "coeur de métier", c'est juste un bonus pour attirer les gogos, la qualité n'est pas importante.
Mais apparamment non, j'ai un manque chronique de connaissances en la matière
Oh, pas du tout. Tu as juste raconté des bêtises sur 1) la soi-disant stagnation des performances des compilateurs C ; 2) le soi-disant peu d'importance des performances CPU dans les jeux modernes ; 3) le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main ; 4) la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison ! Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ah, et le meilleur pour la fin :
j'aime bien les insultes polies
Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (page perso, ) le 12/06/2003 à 09:34. (lien). Évalué à -1.Tu es très fort, tu arrives à me faire aller à l'encontre de mes bonnes résolutions.
D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)
Mais bien sûr. J'ai dit :
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.
SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances.
De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.
si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage
etc., je ne vais pas recopier intégralement des posts que tu ne lis pas. Maintenant, cherche bien là dedans (et dans le reste) et dis moi à quel moment j'ai nié ton histoire d'importance relative du langage. C'est toi qui a écrit que je pensais le contraire.
Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.
Oui, ou encore de descendre à 50 fps si le reste du jeu est implémenté dans un langage qui rame. Bravo, tu as compris ce que je me tue à t'expliquer depuis plusieurs posts (cf avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage).
la soi-disant stagnation des performances des compilateurs C
Ton super exemple est gcc (très utilisé pour compiler les jeux commerciaux), pour lequel je veux bien croire que les performances ont augmenté, heureusement, malgré ses nombreuses qualités gcc a toujours été très en retard sur les compilateurs commerciaux (par exemple sur alpha, c'était une catastrophe). J'aimerais savoir quelle a été la progression des compilateurs C commerciaux sur les 10 dernières années (pour le C++, la progression est énorme). Ton autre super argument est la prise compte d'un hardware moderne. Formidable. C'est aussi le cas dans tous les autres langages. De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.
Ceci étant, pour te faire plaisir, je veux bien dire que j'ai dit une connerie.
le soi-disant peu d'importance des performances CPU dans les jeux modernes
J'ai dit De plus, le discours sur les performances me fait bien rire.. C'est bizarre mais j'ai l'impression que ce n'est pas exactement la même chose. Et je maintiens que Carmack a été très réticent pendant des années à passer au C++ pour des raisons de performances et de bugs des compilateurs. Or, aujourd'hui, plus personne ne critique le choix du C++ pour programmer l'essentiel d'un jeu. Mon argument était juste de dire que je pense que dans quelques années (disons j'espère), l'argument "Java ça rame" sera devenu aussi pertinent que celui "C++ ça rame".
le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main
Alors la, bravo. Trouve moi la citation qu'on rigole. Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur (par rapport au C). Les programmeurs codent les jeux en C++ parce que la perte de performance est largement compensée par le hardware actuel et les économies en temps de développement, pas parce qu'ils sont sur que l'assembleur engendré est aussi bon que ce qu'ils pourraient faire à la main. Et je ne connais pas de bench significatif concernant la qualité du code engendré (les parties d'ATLAS concernées sont très spécifiques).
la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.
Aller, trouve moi la citation qu'on rigole de nouveau.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison !
Je suppose que tu travailles dans un grand studio de développement de jeux (et tu ne connais pas Vampire The masquerade ?). Parce que sinon, tu fais comment pour savoir ce qui est utilisé comme techno dans les logiciels propriétaires que sont les jeux ? Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.
Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ba oui, c'est d'ailleurs exactement ce que j'ai dit (tu dois pouvoir trouver la citation quelque part). D'ailleurs, c'est sûrement pour rien que j'ai dit mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Tu peux toujours faire de l'ironie à deux centimes. J'ai juste voulu indiquer que j'avais quelques compétences en jeux vidéo, contrairement à ce que tu affirmes. Quelles sont les tiennes, à part une grande bouche ?
Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))
D'après le grand robert, crétin signifie "personne sotte, stupide". Je te suggère donc de remplacer dans mes phrases "tu es un crétin" par "tes arguments sont stupides". C'est plus long et moins direct, et éventuellement un peu moins une généralisation hâtive (c'est vrai que tu utilises peut être des arguments intelligents dans d'autres contextes). Au final, tu obtiendras ce que j'appelles une insulte polie, mais ça ne semble pas te gêner, alors allons pour l'insulte polie.-
[+] [^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik () le 12/06/2003 à 11:12. (lien). Évalué à -1.Mon argument était juste de dire que je pense que dans quelques années (disons j'espère), l'argument "Java ça rame" sera devenu aussi pertinent que celui "C++ ça rame".
Qu'est-ce que ça vient faire ici ? On parle des performances actuelles de Java. Si tu es capable de prédire les performances de Java dans 5 ou 10 ans, tant mieux pour toi. Note que les problématiques de compilation de Java ne sont pas vraiment les mêmes qu'en C++ (sinon elles seraient déjà résolues), ce qui rend l'analogie peu convaincante.
Et je maintiens que Carmack a été très réticent pendant des années à passer au C++
Quelle est la pertinence de Carmack dans cette discussion ? Les scrupules de Carmack n'ont rien à voir avec un argumentaire d'ordre général, tu ne crois pas ? C'est comme ton magnifique argument sur les prétextes de MDI pour la création de Gnome (que le langage utilisé par KDE soit la raison déterminante de la création de Gnome, tout le monde y a cru, bien évidemment :-)).
Du reste, je ne vois pas pourquoi tu t'acharnes sur C++. Que les compilateurs C++ aient beaucoup progressé en quelques années, tout le monde le sait. Cependant ils étaient déjà largement exploitables il y a quatre ou cinq ans. Les fonctionnalités les plus importantes pour les jeux (templates peu complexes, inlining) fonctionnaient très bien.
De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.
"Par rapport à", peut-être. Et alors ? Dans une discussion qui comparait l'utilisation de C et de l'assembleur dans les jeux video, tu te mets tout d'un coup à invoquer C++ et Java ?
Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur
Oh, merci de ne pas me faire dire ce que je n'ai pas dit. Je n'ai jamais dit que l'assembleur était toujours inutile, j'ai dit que dans la majorité des cas le code généré par un compilateur était aussi sinon plus performant, et cela expliquait que C/C++ était dominant dans les jeux depuis quelques années (tu ne contestes pas cette évidence, n'est-ce pas ?). Ce n'est pas le cas des calculs mathématiques et/ou vectorisables. (relis ce que j'ai dit sur le SSE, qui est utile pour optimiser les calculs 3D).
Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.
Quand comprendras-tu que tes lectures n'ont aucune incidence sur la crédibilité de tes arguments ?
mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu
Magnifique ! On est donc d'accord :) Je suis quand même curieux : pourquoi es-tu intervenu au tout début de la discussion, alors ? A cause du besoin impérieux de venir jouer les midinettes dans un thread qui mettait en doute les performances de Java ? Tu es émotif quand on parle de langages informatiques ?
-
-
-
-
-
-
-
-
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par yoplait () le 11/06/2003 à 18:03. (lien). Évalué à 2.C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.
y a pas que quand il parle de java... : http://linuxfr.org/2002/08/03/9162.html(...)
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Aurélien Girard () le 10/06/2003 à 15:30. (lien). Évalué à 5.Java est peut être rapide (il y a des gens dans les facs qui malgré les apparences continuent à le crier haut et fort).
Par contre il faudra faire preuve d'une mauvaise foi sidérante pour affirmer qu'une interface graphique en Java offre un semblant d'utilisabilité tellement c'est poussif même sur les machines les plus véloces.-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Romain Guy (page perso, ) le 10/06/2003 à 15:46. (lien). Évalué à 3.www.javagoodies.com
Essaye, tu verras.
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Roger Rabbit () le 10/06/2003 à 20:21. (lien). Évalué à 3.sous linux ...
sous windows c'est nettement mieux
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Guillaume Leclanche (page perso, ) le 10/06/2003 à 21:50. (lien). Évalué à 1.Moi tout ce que je sais, c'est que mon téléphone portable est programmé en java et que la réactivité, c'est vraiment pas ça.
Et c'est un FAIT.-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Éric (Jabber id, page perso, ) le 10/06/2003 à 22:18. (lien). Évalué à 2.pire, je suis sur que si on faisait tourner une jvm sur mon 286, eclipse ramerait.
La question est-ce : est ce que ca remet en cause le langage ?
Non parce que c'est aussi potentiellement le software qui est mal programmé ou le téléphone qui est un peu faiblard.
Perso je trouve aussi que mon téléphone (pas java du tout) réagit lentement, comme quoi ca n'a pas forcément à voir avec le langage. Je suis aussi capable de faire un truc qui rame en C ou assembleur.
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Yusei (page perso, ) le 10/06/2003 à 15:56. (lien). Évalué à 3.Chez moi Eclipse c'est lent, trop lent pour être utilisable agréablement. Certes, ma machine n'est pas à la point de la technologie, mais bon en dehors de certains softs Java et des jeux en 3D, je n'ai rien qui rame au point que je ne puisse m'en servir.
Alors j'veux bien, Java c'est rapide, mais j'attend toujours de voir. Et c'est pas faute d'essayer occasionnellement, contrairement à ce qu'on peut lire parfois.
Mais promis, je dirai à mon ordinateur qu'il se trompe, et qu'il ne devrait pas ramer autant ;-)-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Benoît Bailleux (Jabber id, ) le 11/06/2003 à 06:08. (lien). Évalué à 2.C'est assez pénible, à la longue, ce débat (deuxième fois en une seule semaine).
En fait Java n'est pas spécialement rapide. OK.
Mais ce n'est pas non plus spécialement lent, sauf quand on utilise certaines bibliothèques +/- bien concues ou implémentées. Point.
Les avantages sont ailleurs, à mon avis.
Ceci dit, au boulot j'utilise un PIII 450MHz avec Win2000, et Eclipse tourne étonnament bien. Moi je dit : bravo les développeurs et bravo Java.--
BB-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Etienne Juliot (page perso, ) le 11/06/2003 à 07:00. (lien). Évalué à 2.Merci pour ce résumé, et j'espère qu'on va arrêter de débattre de cette façon.
Ca avance à rien cette discussion.
Java n'est qu'un langage, et il est clairement bien fait (plus de pointeur, bien concu, bien documenté, ...).
Après, qu'il soit lent, ce vient de la JVM.
Bref, si vous trouvez Java trop lent, aidez le projet GNU en participant à Classpath (l'implémentation de la JFC (la bibliothèque Java) en GPL utilisée notamment par GCJ).
http://www.gnu.org/software/classpath/classpath.html(...)
Là au moins, on a le droit d'optimiser comme on peut/veut et il n'y a plus d'excuses valables.
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par alenvers () le 10/06/2003 à 17:18. (lien). Évalué à 2.Java est lent, perl est lent, python est lent parce que ils ont tous de l'interprétation à un moment ou à un autre !
SI on utilise un compilateur natif ca ne serait plus lent. Cependant, il resterait le problème des garbages collectors qui produisent des variations importantes en temps d'exécution (ce qui est ennuyant pour les applics temps réel).-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Geo Vah () le 10/06/2003 à 17:35. (lien). Évalué à 2.Sauf que dans les dernières versions de certain compilo, des parties sont compilées dynamiquement !
Donc ca tourne quand même, et l'api 3D de java utilise openGL il me semble, donc en 3D ca tourne aussi.
Par contre je suis d'accord que la GUI est lourde et lente
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par tene (page perso, ) le 10/06/2003 à 19:03. (lien). Évalué à 2.Mon avis (j'adore donner mon avis ;), c'est que finalement "lent" ça veut pas dire grand chose, ils peuvent faire un truc propre et efficace... là ou ça me préoccupe plus c'est pour le déploiement, ça a toujours été une plaie à déployer java...
Mes 2 cents ;)
Sinon je suis curieux de voir comment ils vont s'intégrer à OO.org...-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Geo Vah () le 10/06/2003 à 19:34. (lien). Évalué à 1.Si déploiment c de l'installation chez un client par exemple, rien de vaut un bon petit script ant !
C aussi chiant qu'un makefile, mais aussi tôt que l'on maitrise quel bonheur :
Récupération du code source via cvs, compilation, installation,etc...
Vive Ant ! Vive Makefile !
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par superpop () le 10/06/2003 à 19:36. (lien). Évalué à 1.Avec le RUNTIME java, ca va encore faire monter la taille de OO ...
Franchement je trouve l'interface graphique ideuse ...-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Roger Rabbit () le 10/06/2003 à 20:38. (lien). Évalué à 7.... swing est thémable ...
en utilisant skinlf.jar de lf2prod, tu peux utiliser
1- les themes natifs skinlf
2- les themes kde
3- les themes gnome
un petit screenshot de mon netbeans utilisant le look "alloy"
de kde
http://antonin.tuxfamily.org/capture4.png(...)
skinlf fonctionne avec toutes les GUI swing, et on peut changer
le look d'un application en ligne de commande , si on ne veut/peux
pas changer le code d'un soft.
le theme swing sera complétement revu pour le jdk1.5 [ cf une
ancienne discussion ]
pour plus d'infos sur skinlf :
http://www.l2fprod.com/(...)
pour récuperer des skin swing [ skinlf ou L&F standards ]
http://www.javootoo.com/(...)
autres screenshots de swing thémé :
http://www.incors.com/lookandfeel/abeille.png(...)
http://www.incors.com/lookandfeel/jprofiler1.png(...)
pour rire :
http://javootoo.l2fprod.com/plaf/xp/screenshot_xp.jpg(...)
pour lancer netbeans avec des themes :
tu downloade http://www.l2fprod.com/download/files/latestskinlf.php(...)
tu le decompresse
tu copie le fichier skinlf.jar dans le repertoire /ext de netbeans
ensuite, il faut choisir le type de theme, 3 types :
1) theme skinlf
tu peux les downloader à http://www.javootoo.com/(...)
2) themes qt
3) themes gtk
ensuite utiliser les themes
1) theme skinlf :
/opt/netbeans/bin/runide -mainclass Skinit -pack \themes\aquathemepack.zip
org.netbeans.Main
2) theme kde
crée un ~/.skinlf
détarre la version de dev de skinlf et mets y themepack.zip
ensuite pour lancer :
/opt/netbeans/bin/runide mainclass Skinit -kde
/usr/kde/3.1/share/apps/kstyle/themes/alloy.themerc org.netbeans.Main
3) themes gtk :
runide -mainclass Skinit -gtk /usr/share/themes/Chrome/gtk/gtkrc
org.netbeans.Main
NB : tu peux configurer netbeans dans
/opt/netbeans-3.4.1/bin/ide.cfg
en mettant par exemple
-J-Xverify:none -J-Xms24m -J-Xmx96m -mainclass Skinit -kde
/usr/kde/3.1/share/apps/kstyle/themes/alloy.themerc org.netbeans.Main
Pour C/C , toutes les appz swing sont largement et facilement thémables,
apres on aime ou on aime pas .....
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Romain Guy (page perso, ) le 10/06/2003 à 22:52. (lien). Évalué à 2.Ce n'est plus vrai. Déployer grâce à Java Web Start est un bonheur. Pour le programmeur, il suffit de créer un fichier .jnlp (du XML) très simple et très court. Pour le client, installer Java Web Start puis cliquer un lien sur Internet pour donwloader/lancer l'appli.
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par tene (page perso, ) le 11/06/2003 à 09:24. (lien). Évalué à 0.Ce n'est plus vrai. Déployer grâce à Java Web Start est un bonheur.
D'accord, mais:
- il faut déployer java web start avant... et avoir l'infrastructure nécessaire pour le faire fonctionner.
- tu crois que ce sera utilisable pour le reste des applications OO.org?
- tu ne trouves pas que c'est encore un peu plus d'enfoncer dans les techno java?
-
-
-
[^]Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.