Forums : Les possiblités de la plateforme Mozilla

Merci beaucoup, je reste sur une optique XUL dans ce cas (et attend avec impatience l'implémentation de trucs sympas comme des sources SQlite dans un treeview, etc...)... :)

Désolé de l'incursion, je vous laisse à vos débats techniques ;)

Un certificat fourni par un tiers de confiance c'est entre 200 et 800$ par an

L'ordre de grandeur est un peu élevé : ma boîte possède quelques certificats de signature de code pour des applets java, elle les paie environ 100$ par an.

De passage sur le site, je me demandais si le problème du nsTreeView avait été résolu ?

Sinon, pour remplacer xul, je pense beaucoup à qooxdoo : compatible IE, Firefox, Opera !

Les démos qui n'ont rien à envier à xul : demo 1 , demo 2 .

Ami

je me demandais si le problème du

nsTreeView avait été résolu ?

non.

Les démos qui n'ont rien à envier à xul

Euh, c'est un lancé de troll là ? "rien à envier".. tu plaisantes ?

• c'est trés lourd par rapport à du xul (non mais, sans dec, ça charge au moins un script js de 850ko !, sans compter celui de 50k rien que pour l'appli)
• ce n'est pas un langage xml, donc pas comparable, et y a rien de comparable avec XBL, Xforms etc...
• au niveau rapidité d'exécution : c'est trés trés lent.
• ça n'utilise pas les feuilles de styles CSS : "Cascading Style Sheets’ intention is to style web pages, not advanced GUIs." bouarf.. quel foutage de gueule... Et le XUL, il est stylé avec quoi ? Résultat, ils stylent tout à la main (comme des porcs). C'est du n'importe nawak.
• et puis bien sûr, encore un enième framework qui réinvente la roue au niveau de l'interface, de la gestion des évènements etc...

Même si je ne suis pas développeur de métier, je suis d'accord avec Laurent : On ne peut pas comparer la puissance d'un framework développé et utilisé par Mozilla à ce framework là qui me semble bien lourd et bien compliqué pour pas grand chose.

Et puis je trouve ça un peu incohérent de proposer un framework dans la mouvance Web 2.0 sans utiliser de CSS ni de XML, qui sont quand même un peu puissants et incontournables dans le contexte actuel.

Mais le pire, c'est ce qu'ils osent appeler des "thèmes" lol... Y a juste les icônes et la couleur de la barre de titre qui changent lol, on se croirait sous Win95 à changer sa barre de titre bleu en vert olive... XD

Rien à voir avec l'intégration graphique de XUL dans n'importe quel environnement, ça c'est de toute beauté ^^

> je me demandais si le problème du
nsTreeView avait été résolu ?
non.

Dommage

> Les démos qui n'ont rien à envier à xul

Comme interface graphique c'est propre !

Euh, c'est un lancé de troll là ? "rien à
envier".. tu plaisantes ?

* c'est trés lourd par rapport à du xul (non
mais, sans dec, ça charge au moins un script js de
850ko !, sans compter celui de 50k rien que pour
l'appli)

850ko la première fois ! Pas la seconde, ni la troisième .... et puis selon la doc, cela peut être réduit comme indiqué ici zip ou ici à 90ko zip2 .

* ce n'est pas un langage xml, donc pas
comparable, et y a rien de comparable avec XBL,
Xforms etc...

bof, ca me gêne pas !

* au niveau rapidité d'exécution : c'est trés trés
lent.

Pas tant que ca ! Le très très très très lent est de mauvaise foi.

* ça n'utilise pas les feuilles de styles CSS :
"Cascading Style Sheets’ intention is to style web
pages, not advanced GUIs." bouarf.. quel foutage
de gueule... Et le XUL, il est stylé avec quoi ?
Résultat, ils stylent tout à la main (comme des
porcs). C'est du n'importe nawak.

Cool, plus de CSS ! Sinon, techniquement, je n'ai jamais mis le nez dans le code source de xul et qooxdoo et je serais bien incapable de juger. La doc est bien faite doc , api . Mais si tu as déjà mis le nez dans le code de qooxdoo, explique ce qui est choquant ?

* et puis bien sûr, encore un enième framework qui
réinvente la roue au niveau de l'interface, de la
gestion des évènements etc...

C'est pas mon avis : ca fonctionne, multi navigateur et LGPL. Bcp de + à mettre dans la balance.

Ami

Pas tant que ca ! Le très très très très lent est de mauvaise foi.

Non pas du tout. Je suis quand meme aller voir les demo et par rapport à du XUL, c'est trés lent. C'est d'ailleurs mathématique : dans qoox l'interface est généré à coup de manipulation DOM. En XUL, le DOM est déjà là, chargé naturellement à la lecture du contenu de la page. Le moteur de rendu n'a plus qu'à afficher les noeuds. De plus, qoox génère à la main les styles sur chaque élément. En XUL, le moteur a juste à lire la feuille de style, et applique lui même les styles, ce qui est trés rapide puisque c'est natif !

En résumé : qooxdo, contrairement à une appli XUL, n'utilise pas les possibilités natives du moteur de rendu, il fait tout à la main. C'est donc forcément plus lent. Et ça se sent.

850ko la première fois ! Pas la seconde, ni la troisième .... et puis selon la doc, cela peut être réduit comme indiqué ici zip ou ici à 90ko zip2 .

Il n'en reste pas moins que le moteur JS doit se taper 850ko de code JS à parser à chaque chargement de page.

Et puis ce que génère qooxdoo, ça reste du HTML : au niveau accessibilité, ça reste limité par rapport à XUL. (En HTML, un liste, même maquillée en menu deroulant, ça reste une liste, alors qu'en XUL, un menu deroulant, c'est un vrai menu deroulant, avec toutes les mécanismes d'accessibilité qu'il y a derrière)