c'est ce qu'il compte faire si j'ai bien compris son explication.
Mais ça ne serait jamais alors que du XUL-like, sans rien autour (XBL, overlay etc..). Comme la majorité des moteurs XUL-like ( dont une liste est ici http://xul.sourceforge.net(...) ). C'est à dire que ça reprend seulement le concept général de XUL (interface déclaré dans un fichier XML).
Si il veut vraiment faire du XUL comme il est possible de faire dans Mozilla, il sera obligé de casser KaXUL. En effet, Kaxul fait un truc tout con (et pas super beau en définitive, le développeur l'affirme lui même dans sa présentation), c'est qu'il parse le fichier XUL, pour générer un contenu .ui (qui est également un fichier XML d'interface), pour ensuite être interpreté par la lib QT.
Actuellement donc, cela veut dire que tu ne peux faire que du XUL statique. Car si tu veux faire du XUL "dynamique", c'est à dire pouvoir en javascript modifier la structure du fichier XUL (via le DOM), profiter d'un système de template, ou profiter de XBL (les composants XBL sont attachés aux balises XUL via des styles CSS, ce qui permet d'attacher, ou de détacher des XBL n'importe quand durant l'execution de ton programme), si tu veux pouvoir faire tout ça donc, cela signifie qu'à la moindre modif XUL, le contenu ui devra être regénéré, et reparsé par QT etc...
Ce qui n'est, à mon sens, pas du tout optimum. L'affichage ne se base plus directement sur un contenu DOM original comme c'est le cas dans Mozilla, mais via des moyens détournés, des transformations trés coûteuses en temps d'execution.
Si on veut avoir du vrai XUL dans Konqueror, il faut hacker KHTML, et pas passer par des moyens détournés à la KaXul, donc pas par les fichiers ui.
Le problème que je vois moi, c'est que les technologies de Mozilla (XUL, XBL, overlay, templates etc...) sont trés liées les unes avec les autres, ce qui résulte qu'il n'y a pas 36 moyens d'implementer tout ça ensemble je pense. Il faut le faire comme c'est fait dans Gecko (au niveau architectural j'entend). Est ce qu'alors KHTML a une architecture suffisement souple pour qu'on puisse ajouter toutes ces technos ensemble ? Je ne sais pas...
En tout cas, la majorité des moteurs XUL-like ne sont guère allé plus loin que le support du seul langage XUL (donc en gros, supporter une simple liste de balises et transformer chacune en appel de fonctions d'une API de widget, ce que ne fait absolument pas Gecko). La difficulté de mise en oeuvre des autres technos toutes ensembles doit être en partie la cause de ce simple support. (même si je reconnais que cela peut être suffisant dans beaucoup de cas). En tout cas, à mon sens, On ne peut pas dire que c'est du XUL comme dans Mozilla.
Le XUL (le vrai, celui de Mozilla), souvent copié, mais jamais égalé.
[^] # Re: stratégie google
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Bounties KDE pour le "summer of code" project de Google. Évalué à 4.
Mais ça ne serait jamais alors que du XUL-like, sans rien autour (XBL, overlay etc..). Comme la majorité des moteurs XUL-like ( dont une liste est ici http://xul.sourceforge.net(...) ). C'est à dire que ça reprend seulement le concept général de XUL (interface déclaré dans un fichier XML).
Si il veut vraiment faire du XUL comme il est possible de faire dans Mozilla, il sera obligé de casser KaXUL. En effet, Kaxul fait un truc tout con (et pas super beau en définitive, le développeur l'affirme lui même dans sa présentation), c'est qu'il parse le fichier XUL, pour générer un contenu .ui (qui est également un fichier XML d'interface), pour ensuite être interpreté par la lib QT.
Actuellement donc, cela veut dire que tu ne peux faire que du XUL statique. Car si tu veux faire du XUL "dynamique", c'est à dire pouvoir en javascript modifier la structure du fichier XUL (via le DOM), profiter d'un système de template, ou profiter de XBL (les composants XBL sont attachés aux balises XUL via des styles CSS, ce qui permet d'attacher, ou de détacher des XBL n'importe quand durant l'execution de ton programme), si tu veux pouvoir faire tout ça donc, cela signifie qu'à la moindre modif XUL, le contenu ui devra être regénéré, et reparsé par QT etc...
Ce qui n'est, à mon sens, pas du tout optimum. L'affichage ne se base plus directement sur un contenu DOM original comme c'est le cas dans Mozilla, mais via des moyens détournés, des transformations trés coûteuses en temps d'execution.
Si on veut avoir du vrai XUL dans Konqueror, il faut hacker KHTML, et pas passer par des moyens détournés à la KaXul, donc pas par les fichiers ui.
Le problème que je vois moi, c'est que les technologies de Mozilla (XUL, XBL, overlay, templates etc...) sont trés liées les unes avec les autres, ce qui résulte qu'il n'y a pas 36 moyens d'implementer tout ça ensemble je pense. Il faut le faire comme c'est fait dans Gecko (au niveau architectural j'entend). Est ce qu'alors KHTML a une architecture suffisement souple pour qu'on puisse ajouter toutes ces technos ensemble ? Je ne sais pas...
En tout cas, la majorité des moteurs XUL-like ne sont guère allé plus loin que le support du seul langage XUL (donc en gros, supporter une simple liste de balises et transformer chacune en appel de fonctions d'une API de widget, ce que ne fait absolument pas Gecko). La difficulté de mise en oeuvre des autres technos toutes ensembles doit être en partie la cause de ce simple support. (même si je reconnais que cela peut être suffisant dans beaucoup de cas). En tout cas, à mon sens, On ne peut pas dire que c'est du XUL comme dans Mozilla.
Le XUL (le vrai, celui de Mozilla), souvent copié, mais jamais égalé.