Démarrage d'OpenKomodo

« Écosystème de Jelix - High techno au cinéma »

Démarrage d'OpenKomodo

Par Laurentj le mercredi, septembre 5 2007, 22:38 - Logiciels - Lien permanent

Depuis que je fais des applis XUL, j'ai toujours vu un potentiel énorme de la plateforme Mozilla pour réaliser un environnement de développement. En effet, imaginez un Eclipse like, mais en XUL. Personnaliser alors son environnement serait vraiment aisé grâce au système d'extension XUL. On pourrait même aller beaucoup plus loin qu'Eclipse en matière de personnalisation et de configuration (vive les overlays !). Ce n'est pas qu'Eclipse n'est pas bien, mais il faut tout de même avouer que c'est un bordel sans nom pour rajouter des plugins par rapport à l'installation d'une extension XUL. Et je ne parle même pas du développement de ladite extension/plugin qui est quand même plus simple pour Mozilla que pour Eclipse.

Et justement, ActiveState propose depuis des années un IDE basé sur la plateforme Mozilla, Komodo. Le problème est que cet environnement n'est pas libre et est payant, c'est pourquoi il n'est pas forcément très connu (pour l'anecdote, c'est eux qui sont à l'origine du binding XPCOM pour Python). Il y a depuis quelque mois une version "light" et gratuite, Komodo-edit, mais ce n'est toujours pas libre. Cependant, le groupe de travail Mozpad, qui oeuvre pour le développement de XulRunner et de son ecosystème, et qui réfléchi notamment à la mise en oeuvre d'un IDE pour aider à la réalisation d'applications XUL, avait Komodo dans son colimateur depuis quelques temps. En effet, quoi de plus naturel d'utiliser un IDE en XUL pour réaliser des applis XUL, surtout que, connaissant la techno, réaliser des extensions est plus facile que d'aller apprendre JAVA et tout le système de plugins complexe d'Eclipse. Mais le fait que Komodo soit propriétaire était bloquant pour s'en servir comme base d'un future IDE pour XUL.

Et voilà que, comme par une heureuse coïncidence^[1], ActiveState décide de libérer sa plateforme IDE ! Le nom du projet : OpenKomodo.

OpenKomodo n'est pas un IDE à proprement parler, mais un framework, une base pour réaliser un IDE, s'appuyant donc sur les technologies Mozilla. Il aura tous les composants de base nécessaires à la création d'un IDE, restera alors plus qu'à réaliser des extensions et probablement l'interface principale pour créer un IDE. OpenKomodo sert d'ailleurs de base pour les produits Komodo-IDE et Komodo-Edit. Une première version publique sera disponible en novembre. Et un autre projet va démarrer, Komodo Snapdragon, qui sera un IDE spécialisé pour le développement d'application web.

Reste plus maintenant qu'à démarrer un projet d'IDE pour applis XUL, ce qui ne devrait pas tarder d'ici la fin de l'année, on peut compter sur des Mozpad'iens :-)

Seul bémol toutefois, après avoir testé la version linux de Komodo-edit cet aprés-midi : l'interface n'est pas très réactive, et ça rend son utilisation agaçante. Je soupçonne les composants en Python et peut-être aussi le binding XPCOM Python, d'être responsable de cette lenteur. Ce serait pas mal qu'à l'avenir, dans OpenKomodo, les composants les plus critiques soit converti dans un autre langage plus performant. Ou alors améliorer le binding Python. Le seul truc qui est très réactif, c'est la zone d'édition. Mais c'est normal, c'est un plugin basé sur l'éditeur scintilla, le même type de plugin qu'à fait Paul dans codeditor ;-)

Notes

[1] il est possible que le voeux de mozpad d'avoir un komodo libre ne soit pas étranger à la décision d'Activestate, mais ce n'est que pure supposition de ma part :-)

Commentaires

1. Le mercredi, septembre 5 2007, 23:43 par lrbabe

Je m'interroge quand même pas mal sur la politique de ActiveState : Les différents IDE seront basés sur OpenKomodo, ok. Mais il y aura un IDE payant et pas libre, un IDE gratuit et pas libre et un autre libre, c'est bien ça ? On peut donc penser qu'ils se débrouilleront pour toujours laisser les versions gratuites derrière la version payante en terme de fonctionnalités...

2. Le jeudi, septembre 6 2007, 01:29 par Damien

J'utilise Komodo-Edit depuis quelques mois, c'est à l'heure actuelle mon IDE préféré tout OS confondu. Par contre il est vrai qu'il souffre d'une certaine lourdeur (l'explorateur de fichier par exemple).

Très bonne nouvelle cette ouverture du code, merci pour la news !

3. Le jeudi, septembre 6 2007, 02:34 par Ner0lph

Reste plus qu'à faire un WinDev-like et un WebDev-like libres... !

4. Le jeudi, septembre 6 2007, 16:34 par Country

Très bonne nouvelle. J'espère qu'à terme cela débouchera sur un vrai IDE en XUL facilement extensible.

Pour l'instant je me suis tourné vers Aptana (basé sur Eclipse) mais c'est vrai que c'est bien lourd et compliqué (et les extensions, n'en parlons même pas).

5. Le vendredi, septembre 7 2007, 21:04 par Florent V.

lrbabe: ce que j'ai compris pour ma part, c'est qu'ActiveState libère la «base» de ses logiciels Komodo Edit et Komodo IDE.

ActiveState continue donc à proposer son Komodo IDE payant et son Komodo Edit gratuit (aucun des deux n'étant libre), peut-être en profitant d'améliorations de la base (OpenKomodo) par une possible communauté.

Par contre, je ne crois pas qu'ils vont développer eux-même un IDE libre par-dessus OpenKomodo. Mais la libération d'OpenKomodo permet à un projet de se monter pour réaliser cela.

Mais je dis peut-être une bêtise. :D

6. Le vendredi, septembre 7 2007, 21:11 par Florent V.

Autant pour moi, il semblerait qu'ActiveState veuille également développer un logiciel libre complet basé sur OpenKomodo. Par contre, il sera dédié aux technologies web côté client (html, css, javascript), et basé sur Komodo Edit. Donc ne fera pas particulièrement concurrence à leur produit payant, Komodo IDE, je suppose.

Pour le coup, c'est une très bonne nouvelle pour moi, vu que j'utilise (et apprécie) déjà Komodo Edit, et que mon domaine est justement les langages web côté client. :)

7. Le mercredi, septembre 12 2007, 12:07 par nico

je comprends pas pourquoi tout le monde dit qu'il est plus simple d'ecrire du XML : XUL, Xforms, ... plutot que du code, java ou javascript. Voir les topics http://www.ljouanneau.com/blog/2006/04/05/544-xforms-vs-ajax-1---0 et http://www.ljouanneau.com/blog/2005/09/29/478-ajax-est-deja-obsolete.
Je n'aime pas du tout les frameworks pseudo automatiques, ou on aurait simplifie les choses en remplacant du bon vieux code par du XML. Sauf qu'en general, on met bien plus de temps a remplir ce fichu XML qui genere (invisiblement) des centaines de trucs qui ne sont jamais ce qu'on veut !
Il vaut souvent mieux avoir des choses transparentes sur lesquelles on a veritablement le controle !

8. Le mercredi, septembre 12 2007, 13:01 par LaurentJ

@nico : le bon vieux code comme tu dis, n'est pas adapté à tout. L'utilisation du XML a plusieurs avantages :

c'est moins lourd à taper, quoi que tu en dises, car on déclare les choses, on indique ce que ça doit faire et non pas comment cela doit être fait. C'est tout l'intérêt de ce qu'on appelle la programmation déclarative.
grâce à l'aspect déclaratif, c'est plus accessible par des néophites (pas besoin de connaitre la programmation en général).
extensibilité, pour le XUL par exemple. Va donc modifier une interface utilisateur faite en GTK sans toucher aux sources par exemple (et sans que l'auteur n'ait prévu 15000 hooks pour pouvoir modifier l'interface). Au contraire d'une interface en XUL. Et cette propriété n'existe que grâce à l'aspect déclaratif se faisant au travers d'un fichier déclaratif de type XML.
utilisation plus facile dans d'autres dialectes XML (XForms dans du Xhtml par ex).
on peut utiliser des IDE pour générer lesdit fichiers XML. Pour xforms par exemple, il existe des clickodromes pour construire ses formulaires. Va donc développer un clickodrome qui génère non pas un formulaire en XML, mais en C++ par exemple (ou tout autre langage de programmation classiques), et qui permette de modifier le formulaire aprés coup, voir même après d'éventuelles modifications à la main du code généré, et toujours en wysiwyg. Sache que réaliser ce genre de générateur est très complexe, voir impossible (certains s'en sortent en mettant des commentaires spéciaux partout dans le code pour s'y retrouver, mais si le développeur a le malheur d'y toucher, le générateur est perdu). A contrario, réaliser des générateurs/éditeurs de fichier XML, c'est très facile (car le XML a une syntaxe claire, simple, structurée, et sa manipulation avec le DOM est très facile...)

Pour finir, je reprend un exemple de l'article sur ajax, au sujet de la balise <a> en html. Si elle n'existait pas, il faudrait faire ce genre de chose : <span onclick="location.href='toto.html'">mon lien</span>. Trouves-tu cela plus simple que de faire <a href="toto.html">mon lien</a> ? Et encore, imagine que location.href n'existait pas, et qu'il fallait passer obligatoirement par xmlhttprequest, pour aller charger la page...

9. Le vendredi, septembre 14 2007, 11:31 par nico

OK pour les points 1 et 2, ca peut ameliorer les choses.

point 3 : tu ne pourras jamais prevoir tous les cas possibles dans un dialecte XML. Je te donne mon exemple : je genere des formulaires HTML a partir de schemas RNG dans mon boulot. Lorsque l'utilisateur remplit le formulaire, il y a des champs qui se cachent selon ses choix. Ces champs, je ne veux pas les envoyer au serveur. Je suis bien oblige de mettre du javascript derriere, pour selectionner les champs que je veux reellement envoyer.
point 4 : a ce que j'en ai vu, XForms a l'air encore plus complique a apprendre qu'un formulaire de validation Ajax (voir dojo, et les forms widgets dijit), et ca fait des annees qu'ils disent sortir une specification finale. Surtout qu'on est pas du tout sur que cela serve un jour, alors qu'apprendre javascript, c juste s'adapter a une nouvelle syntaxe, pas tres differente d'autres languages.
point 5 : j'avais utilise le generateur de JBuilder, et je ne me rappelle pas avoir eu plus de problemes que ca. Le code genere est assez lourd, mais le XML est volumineux aussi.

Et pour la fin, je suis tout a fait d'accord qu'utiliser le javascript, sans passer par un framework est une perte de temps. Mais avec des bonnes APIs, ca devient aussi simple que d'ecrire une balise <a>. Et puis Ajax ne sert pas uniquement a faire des liens hypertexte, il peut reduire enormement le nombre de pages a ecrire, ne pas laisser l'utilisateur attendre devant une page de chargement...

10. Le vendredi, septembre 14 2007, 16:52 par LaurentJ

tu ne pourras jamais prévoir tous les cas possibles dans un dialecte XML.

Oui mais on s'en fout totalement. Dans le cadre du XUL par exemple, on peut modifier ce qu'on veut d'une interface original sans y toucher et sans que ce soit prévu. La seule limitation actuelle dans Gecko, c'est qu'il faut mettre des id un peu partout dans le fichier original, mais cette limitation peut être levée si on pouvait utiliser des selecteurs XPath ou CSS dans les overlays. Va lire comment fonctionne les overlays XUL pour mieux comprendre ce que je veux dire par extensibilité.

XForms a l'air encore plus complique a apprendre qu'un formulaire de validation Ajax

oui, mais pour XForms, il existe des clickodrome. Pour un formulaire ajax, tu ne pourra jamais avoir ça de manière complète, donc tu devra toujours te taper du code à la main.

et ca fait des annees qu'ils disent sortir une specification finale.

Ça fait dejà 4 ans que XForms 1.0 est un standard, et il y a même eu 2 autres éditions depuis.

Surtout qu'on est pas du tout sur que cela serve un jour

Installe l'extension XForms pour Firefox, et tu peux t'en servir. XForms est utilisé dans de nombreux programmes et dans de nombreuses entreprises dans des applis métiers. Ce qu'il faut savoir c'est que XForms est beaucoup utilisé ailleurs que sur le web.

alors qu'apprendre javascript, c juste s'adapter a une nouvelle syntaxe, pas tres differente d'autres languages.

Oui, si tu t'en tient à une utilisation ultra basique comme beaucoup de développeurs. Mais si tu veux utiliser toutes les spécificités de JS, c'est bien plus qu'une simple adaptation car il comporte des concepts que peu de langage courant ont (objet basé prototype). Et en tout cas, javascript est un langage de programmation, donc il faut connaître la programmation.

XForms, non (et encore plus vrai si tu utilises un clickodrome pour générer ton formulaire).

Et puis Ajax ne sert pas uniquement a faire des liens hypertexte

Certes, c'était un exemple.

il peut reduire énormément le nombre de pages a ecrire

Je vois pas en quoi...

ne pas laisser l'utilisateur attendre devant une page de chargement...

On sort du sujet là...

11. Le lundi, septembre 17 2007, 17:11 par nico

mais cette limitation peut être levée si on pouvait utiliser des selecteurs XPath ou CSS dans les overlays.

donc c possible de n'envoyer que les champs d'un formulaire selectionnes par l'utilisateur ou non ? Et puis ca fait encore Xpath et css a apprendre, si ils sont supportes.

Ça fait dejà 4 ans que XForms 1.0 est un standard, et il y a même eu 2 autres éditions depuis.

ok, mais wiki dit que ca s'est termine en mars 2006, et que la seconde edition est "in progress" http://en.wikipedia.org/wiki/XForms

XForms, non (et encore plus vrai si tu utilises un >clickodrome pour générer ton formulaire).

En 4 ans ou 1 an et demi, ils ont deja sorti des clickodromes qui fonctionnent bien ? Il faut que je regarde... Et les regles de validation seront de toute facon a taper a la main.

Je vois pas en quoi...

par exemple en transformant un flux XML sur le serveur, selon le client, pour le recuperer a l'interieur d'une page web deja chargee sur l'explorateur. On peut creer un template, puis charger tous les articles XMLises.

On sort du sujet là...

je ne crois pas, le A de Ajax est pour asynchrone, on peut charger un flux HTML pendant que l'utilisateur continue a lire son article, tu ne peux pas faire ca sans utiliser xmlhttprequest. Ton idee de "declarer" une interface rend le truc assez statique je crois.

Je dis pas que cette XMLisation n'apporte rien, c'est ce que je fais dans mon boulot. Mais on ne fera pas tout avec, il faudra toujours quelque chose de reellement programmable.

12. Le lundi, septembre 17 2007, 17:40 par LaurentJ

donc c possible de n'envoyer que les champs d'un formulaire selectionnes par l'utilisateur ou non ?

Je ne vois pas le rapport avec l'extensibilité dont on parle.

Et puis ca fait encore Xpath et css a apprendre, si ils sont supportes.

Euh... tout développeur web connait les sélecteurs CSS un minimum... Quant à XPath, ce n'est pas plus compliqué que CSS, et c'est implémenté dans les navigateurs (ne serait-ce parce qu'ils embarquent tous un moteur XSLT).

ok, mais wiki dit que ca s'est termine en mars 2006, et que la seconde edition est "in progress"

Relis bien, c'est la version 1.1 qui est in-progress. Mais bon, y a déjà une norme XForms 1.0, donc où est le problème ?

je ne crois pas, le A de Ajax est pour asynchrone, on peut charger un flux HTML pendant que l'utilisateur continue a lire son article, tu ne peux pas faire ca sans utiliser xmlhttprequest

Dans n'importe quel page web, je peux te charger un bout de page HTML sans utiliser xmlhttprequest, avec iframe par exemple (certes, c'est un autre document complet mais bon). Et en XUL, on peut utiliser la balise template pour charger générer une partie de l'interface sans utiliser xmlhttprequest. Dans XForms, les données des champs de saisie sont soit dans un bout de XML inclus dans le formulaire, soit dans un fichier XML distant dont tu indiques une url. Bref, pour tout ces exemples, tu as juste une url à indiquer dans un attribut pour que ça te charge un document et te l'inclus dans le document courant. Il manque juste en fait une balise du genre <include src=""> pour intégrer un bout de html dans la page courante, sans qu'on ait à faire appel à xmlhttprequest.

M'enfin tout ce que je dis là, je l'ai déjà expliqué dans plein de billets dont ceux dont tu as donné le lien...

jy[B]log