Etienne Juliot a écrit 285 commentaires

Je rajoute qu'il y a d'autres éditeurs Open Source qui supportent LSP :
* Theia : https://theia-ide.org/ , un éditeur web qui peut aussi servir de plateforme pour des IDE
* Che : https://www.eclipse.org/che/ , un IDE qui s'appuie sur Theia et qui y rajoute une notion de workspace de travail et des outils supplémentaires, notamment pour Kubernetes
* LSP4E : https://projects.eclipse.org/projects/technology.lsp4e , il fournit des éditeurs génériques intégrés à Eclipse pour intégrer LSP (à la fois la partie éditeur et debug). C'est d'ailleurs leadé par un français, Mickael Istria. C'est utilisé au coeur de Wild Web Developer https://projects.eclipse.org/projects/tools.wildwebdeveloper , qui fournit des éditeurs Web (CSS, HTML, JSon, JavaScript, TypeScript…).

Pour faire des diagrammes de séquences, tu peux utiliser Sirius.
C'est un projet Open Source sous licence EPL.
Voici le type de résultat que tu pourrais obtenir : 

Les fonctionnalités de diag de séquences te permettent de faire à peu près tout ce qu'on trouve classiquement dans ce type de diagramme, cf la doc : http://www.eclipse.org/sirius/doc/specifier/sequences/Sequence%20Diagrams.html

Mais il y a un avantage particulier : tu peux complètement choisir le format que tu souhaites utiliser pour stocker tes données, et tu peux personnaliser complètement le rendu graphique.
Si tu veux t'y essayer, mieux vaut commencer par un diagramme classique en suivant le tuto : http://www.eclipse.org/sirius/getstarted.html

Je connais deux outils basés sur Sirius qui sont eux mêmes Open Source et qui fournissent des diagrammes de séquences :
- UML Designer (ça m'a d'ailleurs étonné que ne cite pas ce projet Open Source dans la liste des projets libres qui font de la modélisation UML : http://www.umldesigner.org/ ). Le diag de seq : http://www.umldesigner.org/ref-doc/implement-the-application.html#Sequence_Diagram
- Capella, pour modéliser des architectures http://polarsys.org/capella/ et qui lui exploite toutes les capacités du moteur Sirius de diagramme de séquences : http://polarsys.org/capella/images/start/diagrams/[ES]_SAR.png

OnlyOffice ne supporte que OpenXML, le format issu de MS Office. Ca se comprend d'un point de vue marché et vu qu'ils se positionnent en concurrent de MS Word, Excel, etc.
Mais pour séduire la communauté Open Source, ils vont avoir du mal sans un support d'Open Document Format.

Mon entreprise a tous ses fichiers en odt, ods, odp et utilise LibreOffice pour les éditer. Et donc, c'est un nogo direct pour ne serait ce que tester OnlyOffice car ce n'est pas envisageable d'avoir une partie des utilisateurs sur un format, et une partie sur un autre.
D'ailleurs, il y a quelques années, Google Docs supportait nativement ODF, ce qui n'est plus le cas car il faut faire une conversion. Il y a donc justement une place à prendre …

Pour la prochaine version, est ce que vous envisagez un support du format ReqIF pour rendre le résultat de la fonctionnalité d'exigences interopérable avec d'autres outils ?

Du coup, ca serait pas mal que la rédaction de LinuxFR retire cette news de la page d'accueil. Parce que ceux qui se limitent à lire le titre risquent de se trouver tromper. Et ca risque d'alimenter encore des trolls.
Non pas que je veux défendre Oracle, mais bon, ca ne serait pas justifier sur ce coup de se plaindre si c'est une simple erreur (ce qui peut arriver, même aux plus gros).

J'en profite pour signaler l'existence depuis peu d'un consortium qui regroupent les professionnels intéressés par les outils de localisation OpenSource : LocationTech.
L'url : http://locationtech.org/

Bien entendu, il y a du OpenStreetMap dedans, mais pas seulement.
C'est ouvert à toute entreprise, quelque soit sa taille, et qu'elle soit utilisateur ou fournisseur.

PS : pour info, c'est adossé à la fondation Eclipse afin de bénéficier de tout son savoir-faire en terme de consortium OpenSource.

J'ai reçu effectivement ce courrier.
Et j'avais compris que c'était une arnaque. Merci quand même d'avoir fait cette news, car ce n'était pas si évident.
En effet, ils ont été malin car les formulations peuvent faire croire en lecture rapide que c'est officiellement soutenu par SolutionsLinux, quand on lit en détail, ils disent bien qu'ils sont indépendants, et non affilés à Tarsus. Du coup, j'ai l'impression que c'est complètement légal leur truc. Non ?

J'ai été utilisateur pendant quelques années de PhpWebGallery.

Je trouve vraiment dommage que le projet Piwigo ne fasse pas plus appel aux effets CSS3 pour que le résultat soit beau. Pour l'affichage de photos, c'est devenu un élément majeur de choix d'un projet de galerie photo.
Et parfois, ce n'est pas forcément compliqué à faire (2 / 3 transition-delay par ci, par là, et le tour est joué).

La raison est peut être simple : il suffit que le sujet de son intervention à la FOSDEM soit spécialisé sur la comparaison avec GCC.
Et oui, quand tu fais des pres chaque année à la FOSDEM, tu ne vas à chaque fois ressortir le même talk et refaire une introduction de LLVM. Tu as envie de faire des talks différents chaque année.

Au final, tu as peut être raison, mais gaffe à ne pas te faire un avis sur seulement une conférence qui était justement là pour faire une comparaison.

M2M, c'est pour Machine-to-Machine.
Genre, une communication entre ton smartphone et ta brosse à dents.

Je pensais bien évidemment dans un contexte où le fichier html était stocké côté serveur, et non côté client.

Perso, je pense qu'avec la grosse montée de force de GitHub et Orion (et des CMS où tout est déjà hébergé), on va bientôt trouver des projets pour faire directement de la conception dans le web, en mode Wysiwyg. Il y aura sûrement des limites par rapport à du natif (et encore, je ne suis pas si sûr que toi), mais ce sera tellement plus simple que ça vaudra le coup.

En tout cas Laurent, je suis déjà un utilisateur de BlueGriffon (et j'utilisait Composer dès ses débuts) et je le trouve bien pratique sur quelques besoins locaux. Mais j'ai juste un peu peur pour l'avenir.

Bravo à Daniel et à ceux qui t'ont soutenu.

Je me pose une question : qui à refondre Nvu and Co, pourquoi ne pas avoir implémenté BlueGreffon directement en HTML / JS / CSS, de manière à ce que ce soit directement un site web pour créer des pages web ?
C'est quand même dommage d'avoir besoin d'installer une application, alos que les technos web auraient permis de faire cela directement dans le browser. Non ?

Bravo les gars. Ca fait toujours plaisir de voir que des boites se lancent dans un business model OpenSource.

Tiens, petit conseil en passant : mettez plus en valeur des screenshots ou screencasts, c'est un des premiers trucs que les gens vont voir sur le site d'un outil.

Et 2e conseil : mettez vous à la place de quelqu'un qui veut vous acheter quelque chose. Et bien c'est pas hyper clair actuellement. genre, tu vas là : http://www.openconcerto.org/fr/support_pro.html et ca redirige là http://www.ilm-informatique.fr/ , et ca y est : t'es perdu.

A te lire, je dirai plutôt que vous aviez en interne des développeurs qui maitrisaient mieux les clients lourds que les technos web.
Car désolé de le dire, mais faire des applis riches, avec mode offline, avec ergonomie top, ne nécessitant pas un débit énorme, ca fait sans problème. Faut juste avoir les compétences.

Faut bien voir que tout l'industrie y passe et je n'imagine pas que ca reviendra en arrière. Et je ne l'espère pas non plus car c'est un vrai plaisir d'avoir des technos web qui permettent du multi-plateforme, avec des IHM bcp plus belles que ce qui se fait en client lourd, et surtout basées sur des standards.

Tiens, si je ne me trompe pas, OpenERP vient de TinyERP qui a l'origine était un client lourd et a migrer vers le web. Ils n'ont pas garder aussi l'ancien client ?

Non, au contraire.

Et si "les autres" comprennent déjà UML, ton DSL peut très bien s'appuyer sur une partie d'UML (genre, si tu veux modélisation un modèle Orienté Objet).
Si tu veux réutiliser un diagramme (genre séquence ou activité) sur un DSL, il n'y a pas de problème : il faut bien différencier le diagramme, et le contenu de ce qui est manipulé. Comme ça, tu obtiens quelque chose de simple à comprendre, et réutilisant les formes que tu as déjà appris.

Disons que maintenant, tu as une alternative réellement crédible à UML et beaucoup plus simple à mettre en oeuvre : les DSL.

Ca te permet de te définir ton propre vocabulaire, ton propre modeleur avec tes choix de représentation graphique, le tout en gardant un format standard. En gros, si tu choisis de modéliser quelque chose de simple, et bien ca reste simple à utiliser ! Et si tu as un système complexe à mettre au point, et bien tu es libre d'aller très loin en précision de conception.

Il y a une pres faite à un JUG qui explique un peu cela :
http://www.parleys.com/#st=5&sl=1&id=2042

Ca, c'est clair que c'est un bon gros troll.

Surtout que les technos styles GMF ou Acceleo n'impose rien sur la techno cible (tu peux très bien gérer du Python, du JavaEE, du PHP, ... et donc générer du code performant ou non).

Pour info, le Pôle Emploi a aussi choisi le logiciel libre pour ses développements informatiques.

Ils utilisent notamment :
- Eclipse : pour le dev et comme socle pour leurs plug-ins
- GMF : pour le design de leurs applications
- Acceleo : pour la génération JavaEE

Il y a un retour d'expérience public dispo sur : http://www.obeo.fr/pages/success-stories/unedic/fr

Nous, à Obeo, on vient de faire le même constat que toi Stéphane et on passe à Jira.
On préfère de très loin utiliser les outils OpenSource et en faire la promotion ou envoyer des patchs, mais là faut bien avouer que la différence entre Bugzilla/Trac/andCo et Jira était trop grande pour rester sur la solution existante. (en gros, on estimait à 0,5j de charge par mois par personne de perdu, à multiplier par plusieurs dizaines de personnes, ca commence à faire mal).

Par exemple, un problème typique qu'on avait était sur la confidentialité. Quand tu as un trac sur ton outil OpenSource, et que tu as des clients avec du support ou des projets commandés, tes clients t'envoient parfois du code confidentiel avec leurs problèmes. Donc, tu ne peux pas le mettre en publique, et comme il n'y a pas workflow et de confidentialité bien paramétrable, et bien on avait plusieurs Trac. Et du coup, avec des redondances dans les bugs sur les projets FOSS, et une gestion plus complexe qu'avec Jira qui permet de tout unifier.

C'est vraiment dommage qu'une solution libre aussi puissante n'existe pas. Mais comme d'hab : YAKAFOKON ... Si quelqu'un se sent la volonté de faire changer cela, Trac et autre sont des projets ouverts à contribution.

Je ne parlais spécialement d'Eclipse, mais bien de tenter d'unifier le modèle de plug-in. Et le seul standard que je connais, et qui est multi-plateformes et non spécifique à un soft, c'est OSGi. Si tu en connais un autre, je suis preneur.

Et si tu as des idées pour simplifier OSGi, je pense qu'ils seront preneurs de tes lumières.

Image si les descripteurs de tes plug-ins Pidgin, FIrefox, OpenOffice, etc ... avaient tous la même syntaxe de description des dépendances ? Ca ne me semble pas inatteignable (en rêvant un peu), et sacrément utile pour le développeur.

Perso, je préfère largement Eclipse.

Je ne le trouve pas si lourd, à partir du moment où tu n'installes pas tous les plugins de la terre.

Au niveau des astuces pour le quotidien, je trouve qu'Eclipse, c'est la rolls. Il y a plein de raccourcis et d'outils de refactoring qui sont indispensables quand tu y as gouté.

Pour Git, la prochaine version d'Eclipse 3.6 proposera le plugin eGit (fait en partie par des gars de Google).

Pour l'aspect plugin, je trouve cela délirant que les outils Linux ré-inventent tous cette notion de plugins. C'est la grosse mode de rendre à base de plugins, mais surtout, il ne faut pas réutiliser ce qui existe déjà. Dommage pour les développeurs car avoir un modèle commun de pluginisation serait top.
Pour info, il y a OSGi qui fait cela depuis des années, et qui le fait bien (c'est utilisé dans les telephones portables, dans Eclipse, dans les serveurs JavaEE, dans des composants embedded, etc ...)

C'est quand même un gros troll de dire que c'est de la foutaise quand on ne s'est même pas fatigué à suivre les liens !!

Désolé, mais le Perl et le PHP, ça ne suffit pas dans un vrai système d'information.
C'est clair qu'un ESB et son vocabulaire, ca peut paraitre complexe, mais désolé, le problème de connecter ensemble des grosses applications, des petites, des veilles, des modernes, des biens codés, des mal codés, etc ... et bien ce n'est pas si simple. Bienvenue dans la vraie vie.

Si tu sais faire plus simple, et bien vas y. Fait un projet OpenSource, prend tous les besoins d'interconnexion d'un vrai système informatique d'une grosse boite, et fait mieux que Petals. Rendez vous dans 10 ans.

Moi, je pense que les communautés gagneraient à plus se parler. Je ne suis pas un expert kernel Linux ou xorg, mais d'après ce que j'ai regardé, DBus est un genre de bus de communication système. donc, un genre d'ESB. Mais de ce que j'ai vu, c'est loin (très loin) des fonctionnalités d'un Petals (ou concurrent).

Pour les 500 acronymes de Java, regarde la news sur RedHat (http://linuxfr.org/2010/04/22/26771.html ) et compte le nombre d'acronymes. Ce n'est pas mieux. C'est donc juste que tu n'es pas familiarisé avec ces acronymes là.

Pour finir, je vois de temps en temps les ptits gars de PetalsLink (les hommes en orange à SolutionsLinux), et ils sont bien sympas , font du projet OpenSource de qualité, et donc ca m'énerve d'autant plus quand on dit "foutaise" sur une news qui annonce la sortie d'un de leur projet. Encourageons les plutôt.

pour le support utilisateur, ca veut dire que tu paies pour un nombre illimité d'utilisateurs, mais que tu paies en fonction d'une liste de packages supportés ?
C'est ça ?

Ce qui veut dire que si tu es une PME de 10 pers, ou une entreprise de 10000 pers, c'est le même prix ?

Bravo pour la sortie de la v2.

Vous faites vraiment un super outil, bien foutu, joli, et simple.
Et la boite derrière (SonarSource) semble d'un bon esprit vis à vis de la communauté et du projet.

Dommage qu'on n'est pas eu de démo à SolutionsLinux, ca aurait été l'occaz ....

Pour avoir tenter de l'essayer, le principal reproche que je lui ferai est tout simplement d'être moche.
Et pour un outil de montage vidéo, c'est assez important d'avoir une bonne ergonomie sous peine de devenir trop compliqué.

D'après ce que j'ai lu, cela était notamment dû à l'historique du projet qui était parti avant l'avènement des toolkits GTK et QT.

Si on pouvait garder sa puissance, mais avec une IHM plus épurée et un toolkit natif, il pourrait devenir un vrai plus de tous les desktops Linux. Perso, le montage vidéo amateur est une des principales raisons pour lesquelles j'ai encore un double boot avec Windows ...