Manwe a écrit 26 commentaires

Oui, mais quand on dit qu'il fait le café, ben on y est presque.
Le défi dans Eclipse, c'est de désactiver les option qui nous intéressent pas, et découvrir les options qui nous intéressent.

Celà dit, Java, c'est LOURD niveau ram, c'est indéniable.

Oui, mais le probleme est que ceux ci n'ont pas été écoutés par une très grande partie de l'UMP qui s'est contenté de "suivre" les directives du gouvernement plutot que de réfléchir et voter en leur âme et conscience.

En tous ca, c'est l'épisode le plus triste de la démocratie francaise qu'il m'ai été donné d'assister. Puisque meme en faisant front Gauche+UDF étaient minoritaires.

Ca ressemble a la facon dont le "Patriot Act" a été voté aux US. Impressionnant de rebondissements et d'actes anti-démocratiques...

Tout à fait d'accord, FLAC serait parfait (évidemment).

Mais ils doivent pense à leur bande passante aussi je pense.
Du OGG avec un Bitrate très élevé suffit déjà amplement.

Impossible de savoir la qualité qu'ils utilisent.
QQ'un à déjà acheté quelque chose chez eux, histoire de savoir le Bitrate ?
Rien trouvé sur les Forums, ni sur le Site.

Domage à un an près...

"...nous tenterons de répondre le jeudi 9 mars 2005..."

Pourvu que ce soit une erreur que j'attende pas à la porte :D

Le probleme pour moi, c'est de trouver un moyen d'ouvrir un compte Google.
Il faut se faire parainer par quelqu'un c'est ca ?
Ya pas d'autre moyen ?

Ca ressemble quand meme beaucoup l'état du projet Netscape lorsque Mozilla en a hérité.
D'ailleurs, tenter l'utilisation de la plateforme Mozilla pourrait permettre de sortir de ce système d'application Monolytique et de bénéficier bientot de XULRunner (dont les buids fonctionnent bien :) ).
Moins il y a de languages utilisés, plus le projet sera attrayant.
- Que du C++ avec un Framework digne de ce nom pour économiser les lignes de code
- Que du Java ? (est ce pertinent niveau performances et suffisement libre ?)
- Que du XUL (est ce possible ?)
Perso, j'avoue que KOffice est une alternative vraiment très intéressante mais qui manque à Windows. Je suis pressé de pouvoir la proposer à mes amis quand Qt sera completement porté sous Windows.

Oula, faut pas s'énerver, héhé.
Tu nous fait un poisson aussi ?
Juste pour info, tu l'a pas lu, hein, le projet de constitution ?

Perso, je l'ai lu, je vais voter OUI, et je suis pas Capitaliste.
C'est pas parfait, mais c'est ce qu'il nous faut, c'est tout.

Soyons clair, ok :
J'ai un PC sous Windows (evidement, pour comparer...).
Pas de logiciel de lancé.
Pas de "démarrage rapide" (si tous les logiciels en avaient un ce serait la misèrre)
Je lance Office 2003, je ferme
Je lance OpenOffice 2
Je commente même pas la comparaison, je vous laisse juger.

Je vois pas la mauvaise foi. Pour moi, c'est être réaliste. Mon but est que mes amis utilisent OOo à la place d'Office en préparation d'une migration Linux. Tout se passe bien pour Firefox, Thunderbird, Psi (quoique), mais ca coince sur OOo : ils me disent "trop lent".

Je sens que quand QTWin permettra le port de KDE sous Windows, je vais leur faire gouter du KOffice qui me semble quand meme plus rapide.

"c'est le jours ou la nuit"
Oui mais on est passé d'un programme très lent à charger à un programme lent à charger.

Pour moi, ca devrait s'appeler 1.2 et pas 2.0
à moins que des fonctionnalités révolutionnaires n'aient été ajoutées (auquel cas je ne m'en servirai sans doute jamais).

Le probleme semble être le meme que pour Netscape : Un gros code bien inextriquable. Et comment Mozilla s'est sorti de ce pétrain ? En séparant UI, Comportement et traitement. Voire meme en séparant les fonctionnalités (mail, surf...). Je pense pas que OpenOffice opte pour cette voix...

Romain a raison, ton post ne vaut pas grand chose si tu ne nous en dit pas plus.
Par contre, une URL et je me prosterne... :)

Si l'application est meilleure (plus rapide par exemple), sans aucune hésitation je dis OUI.
La distance entre le double clic et la permière lettre reste impressionnante sous OpenOffice comparé à MS Office.

J'ai honte des fois quand je montre ca à mes "profanes".

J'avais tellement espéré une amélioration des performances d'OpenOffice dans la version 2 que le choc a été rude avec ces versions Beta.
Je comprend mieux maintenant.
Plus il y a de Java, plus c'est lourd à charger...
Je trouve Java performant essenciellement sur les serveurs, les applications clientes sont peu populaires, peut être à cause du temps de chargement du JRE.
Les performances du 1.5 sont-elle vraiment meilleures ? de beaucoup ? On a que la 1.4.2 nous en Prod.

L'idéal serait un XULOffice.
Un programme qui manipule du XML (qui est une technologie Web) serait facile et rapide à développer avec une technologie Web.
En plus, on pourrait l'utiliser à distance dans Firefox à terme peut être.

Une fois XULRunner terminé, l'occupation mémoire sera optimisée et on disposera d'une plateforme de développement qui méritera largement d'avoir sa suite Office..

Si je pose un brevet, il dure combien de temps avant de finir dans le domaine public ?
Parce-que, je suis pas du tout contre les brevets s'ils durent 1 an...
Par contre, s'ils durent 70 ans, c'est problématique...

Moi je suis satisfait de tous ces rebondissements.
Ils ont forcé Microsoft à se montrer et à faire pression pour passer en force.
Du coup, beaucoup de politiques on enfin compris les enjeux cachés de la directive, et sont un peut... remontés je pense.
Si elle passe en force, elle finira pas être retirée démocratiquement.

Mais je ne pense pas qu'elle passera sous sa forme actuelle...

Un WM qui gère la 3D, il peut gèrer la 2D... Kler !
Un WM qui gère la 3D permet de faire des choses nouvelles, Kler aussi.
Un WM qui gère la 3D peut afficher une console ?
Bon, en gros, c'est un moyen de s'exprimer SUPLEMENTAIRE et pas un remplacement imposant une bataille entre pour et contre.

DE PLUS, lors de l'avènement du desktop beaucoup ont craché dessus (sisi) puisque les choses pouvaient être faites de manière plus rapide au clavier. Pourtant, personne ne peut dire que le bureau a été un flop.

Le passage à la 3D, pour l'instant, c'est surtout pour le fun, et je pense que ca finira par permettre à certains de présenter une vision différente de l'ergonomie.

Si c'est stable, performant et intuitif (un jour ce sera le cas), alors ca va faire un malheur, assuré.

Et le jour ou tout le monde aura un ecran à affichage 3D comme Sharp et Nec commence à en vendre, ainsi que deux petites webcams qui détectent la positions de nos mains, alors on aura un nouveau petit joujou dont nos enfants demanderons : vous faisiez comment avant ? Et on pourra seulement éviter qu'ils rigolent de nous en leur parlant de l'époque des cartes perforées... :)

La licence Mozilla est propriétaire ? Faudra que je la lise mais c'est assez exagéré je trouve.

Sinon, dans leur cas, ils vont juste utiliser un FrameWork XUL, ce qui est différent de s'ils envoyaient effectivement du XUL directement au client (Du coup, Gecko serait indispensable).
Donc, ils écrivent leur Appli en XUL (ce qui est rapide et facile) pour gagner en temps de développement/correction/modification, et le FrameWork traduit directement en XHTML TOTALEMENT compatible Gecko/IE/Opera/Konqueror.

Donc la question de "Client Lourd" ne se pose pas, c'est la notion de temps d'exécution du langage interprété sur le serveur qu'il faut surveiller, OR le gain de performance lorsqu'on utilise des fichiers XML au lieu de fichiers textes simples est parfois déconcertant.

>"cela impose des outils aux développeurs du monde"
En ce qui concerne les IDE : en gros, il n'en a pas vraiment pour le XUL qui soient finalisés et ils ne sont pas indispensables immédiatement. Et pour le PHP, il n'y a que l'embara du choix.

Je pense qu'ils ont bien testé leur choix en charge et qu'ils sont juste des précurseurs. L'association XUL/PHP 5 pourrait bien être la réponse libre (?) la plus efficace fàce à ASP.NET.

Yep, c'est bien mais il faudrait un type de fichier XML/CSS/JS compatible avec nos compilateurs préférés pour générer des applis Qt, Gtk, Java plus un interpréteur de ces fichiers pour X ou à défaut pour KDE (comme KaXul) et pour Gnome (et autres...).

De cette manière, on pourrait développer sans compiler puis compiler le final.

Choisir XUL comme format par défaut le positionnerait en concurrent direct de XAML (le fork de XUL de M$) pour les applis Desktop et Web.

Je rève d'un Window Manager entièrement en XUL. ;)

Yep, ya des tonnes de format de XML UI (Gtk, Qt, et consors) qui ont l'air d'avoir tous leurs partisants mais qui sont bien sur completement incompatibles entre eux. pourtant, c'est juste des fichiers XML (ou pas d'ailleurs) qui peuvent facilement être convertis entre eux en traitant ces chaines de caractères. Ce serai bien d'avoir un format XML UI standard en plus des autres que toutes les platteformes de Dev puissent interpreter.
Les migrations seraient bien plus rapides (par exemple OpenOffice qui veut passer en Qt ou Gtk je sais plus).

Le probleme est de choisir ce format (hehe, trolls en perspective).

XUL parait tres bien car XPCOM et XBL permettent d'inclure du comportement qui n'a souvent rien à faire avec le traitement pur.

Moi je dit : tout en XML ! (compilé ou non)

XUI -> Description de l'interface
XMC -> Description du comportement
XSS -> Description du style (un CSS 3 quoi)
XCF -> Description des parametres de l'application

Ne sont compilées que les parties choisies par le développeur.
Du coup, pas besoin de compiler pour tester les Devs.
Du coup, possibilité infinie de créer facilement des petites applis.
Du coup, ya qu'a choisir le compilateur et on a une appli compatible avec la platteforme de son choix.

Vous partez dans tous les sens....
La question n'est pas XAML ou XUL ou un autre language XML.
La question n'est pas "c'est lent", "c'est rapide", "c'est lourd"

La question est d'unifier la programmation des UI.

Microsoft a copié completement la platteforme Mozilla pour
Longhorn. On a beau dire, c'est pas par hazard.
http://www.devx.com/DevX/Article/17899(...)

Je crois qu'au niveau Licence, Mozilla est approprié. De plus, le XUL est désormais bien avancé (plus que XAML)

Il nous faut unifier nos langages en faisant des interpréteurs XML UI pour nos Window Manager favoris (KXUL, GXUL) ou meme directement X11XUL. Ainsi que des plugins pour nos outils de Dev de facon à pouvoir compilers ces XML pour monter les performances.

Les applications pourront ainsi être installées avec les UI compilées ou modifiables.

perso, je reve d'un YXUL :)
http://www.y-windows.org/about.html(...)

Si on pouvait programmer au moins les UI de la meme facon quelque soit les langages utilisés, un grand pas serait fait.

Je suis pour l'idée de Edd Dumbill. Cette direction est inéluctable.

So, lets Code my friends !

Etonnant, j'ai jamais eu ce probleme. Pourtant j'en ai fait des install de 9.2.
Si t'as aimé la 7.2, je te conseille la 8.2 alors ou la 9.1 qui étaient de très bonne qualité.

>mais ça ne donne aucune envie de tester les prochaines.
Ben moi si, j'ai testé la 10 preview #2 et j'avoue que c'est appétissant.
En plus, si tu utilise bugzilla, tu pourras signaler ton bug, ya des chances qu'il finisse par passer à la trappe. C'est bien mieux pendant le développement qu'à postériori.

Bref... Je me prosterne devant l'inventeur du BootLoader, et attends chaque étape vers MDK 10 de pied ferme...

Plus d'infos sur XUL et XAML ou comment Moucro$oft a bien pompé l'architecture Mozilla.
http://www.devx.com/DevX/Article/17899(...)
Il semble aussi etre d'accord avec moi pour l'exponentielle :)

Objectif de programmation : assembler des briques avec toujours la possibilité de créer les manques si "The Evil is in the detail".

Je vote : OpenOffice en XUL, Qt/Gtk compatibles XUL que ce soit en compilation ou interpretation.

>T'as raison, c'est pas assez lourd OpenOffice. Relançons les ventes de processeurs !

Je suis pas persuadé que le résultat soit plus lourd...
Franchement, je demande à voir.
Je pense que l'équipe OpenOffice se retrouve avec le meme problème (l'héritage de l'organisation de programmation de StarOffice) que l'équipe Mozilla avec le Blob Netscape.

Au vu des résultats obtenus (Stabilité et Performance) par l'équipe Mozilla, je me demande si ce n'est pas un exemple à suivre.

Sinon, je serait quand meme partisant que Gtk puisse compiler ou utiliser du XUL. Et pareil pour tous les autres. Qu' on adopte au maximum un langage commun...

Mais si, mais si. Si c'est pas XUL, ca aura un autre nom mais un systeme de ce type va s'imposer. :)
C'est du Modele Vue Controlleur mais l'interface est pas (forcément) compilée et en XML, donc éditable.
Ca devient facile d'unifier les visuels d'un environnement, de supprimer des fonctionnalités, d'inverser leur emplacement, sans avoir à recompiler le logiciel et sans risque.

Faut voir si on perd vraiment breaucoup à interpreter au lieu de compiler.

L'objectif premier est de séparer completement UI et Traitement.
Ensuite, de n'écrire qu'une fois l'interface quelle que soit l'OS / le Window Manager utilisé.
De plus, ces interfaces sont automatiquement compatibles WEB à travers Firebird ou Mozilla, ou meme gràce à un des multiples interpréteurs XUL en Java.

Les plus beaux exemples sont, je pense, Firebird et Thunderbird que je ne trouve pas lourds du tout !

Je ne propose pas :
- XUL -> KXUL -> Qt/Gtk -> Ecran mais plutot
- XUL -> KXUL -> Ecran
- XUL -> GXUL -> Ecran
- XUL -> XXUL -> Ecran
- XUL -> WinXUL -> Ecran
- XUL -> MacXUL -> Ecran

Sachant que tous sont possibles et chaque systeme améliore régulierement son framework.

Ca existe déjà depuis bien longtemps dans certains languages comme vous le faites remarquer mais l'objectif est d'en avoir un complet et le plus universel possible entierement en XML.

Je suis persuadé que ca va se répendre exponentiellement.

PS : MS aussi s'y met avec XAML.