"généraliste" pour GNOME, apportant un lot conséquent de corrections, améliorations et de nouvelles fonctionnalités.
Mlview est indépendant du type de fichier XML utilisé et propose actuellement l'édition du document dans un arbre graphique le représentant, diverses aides à l'édition comme la proposition des éléments possibles ou une coloration syntaxique et plusieurs outils comme la validation ou encore les transformations XSLT. Depuis la version 0.6.3, les fonctionnalités suivantes ont été ajoutées, parmi d'autres encore :
- le "undo/redo" infini
- les raccourcis claviers
- le support GnomeVFS
- le support du glisser-déposer depuis Nautilus
- le support du nouveau sélecteurs de fichiers de GTK+
- un meilleur respect des HIG
- un nouveau système de validation et de report graphique des erreurs, incluant en plus du support des DTD le support (à tester) des schémas Relax-NG et XSD.
La documentation interne a été actualisée et une documentation utilisateur concernant les raccourcis claviers a été écrite. Plusieurs traductions ont été actualisées. Quant au site Web, il est en cours de redesign.
Un plan de route pour les prochaines versions (qui s'avère fort prometteur, avec notamment le support déjà en grande partie écrit d'une vue d'édition basée sur le rendu CSS) est également disponible.
À noter l'apparition de nouveaux développeurs (en écrasante majorité francophones :-), signe de vitalité pour un projet libre. Cependant, la tâche étant ambitieuse, si vous souhaitez participer (et pas uniquement si vous êtes développeur, mais aussi si vous voulez écrire de la documentation, ou simplement tester), n'hésitez pas à nous rejoindre ! Vous pouvez retrouver des participants sur le canal #mlview de GIMPnet (irc.gnome.org).
Aller plus loin
- Le site MlView (18 clics)
- Les release notes (3 clics)
- Un screenshot (7 clics)
- La mailing list (1 clic)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mutualisation ?
Posté par HappyPeng . Évalué à 10.
Notre bien aimé et excellent maintainer, Dodji Seketeli, à d'ailleurs écrit, dans le but de l'utiliser pour MlView, une bibliothèque "boîte à outils" pour les CSS (libcroco) ainsi qu'un moteur de rendu XML basé sur les CSS (sewfox). Ces deux outils sont parfaitement réutilisables pour d'autres applications, ainsi libcroco est actuellement utilisée par librsvg et des développeurs de KSVG.
La base de MlView est libxml2 (de Daniel Veillard), qui est à mon avis -le- meilleur toolkit XML disponible et propose énormément de fonctionnalités ; libxml2 est également utilisable et utilisé par de nombreuses applications, qu'elles soient GNOME, KDE ou bien aucun des deux.
A partir de là, nous avons également pensé sortir de MlView (pour les mettre dans des bibliothèques réutilisables) certaines pièces comme le modèle de document (DOM) qui pourraient alors être développées et utilisées en commun par d'autres éditeurs (GNOME ou non).
En ce qui concerne kxmleditor, il utilise le module XML de Qt, qui est loin d'être aussi puissant et performant que libxml2 et qu'il est impossible d'utiliser dans une application GNOME. Par conséquent, il serait fort difficile de partager des composants avec cet éditeur.
[^] # Re: Mutualisation ?
Posté par Mouns (site web personnel) . Évalué à -3.
ou tous les langages de progs ?
sinon quelles sont les erreurs de conceptions de MLView ( puisqu'il est le sujet ) ? surtout que c'est une 0.x donc un truc encore changeable :)
[^] # Re: Mutualisation ?
Posté par alexissoft . Évalué à 2.
[^] # Re: Mutualisation ?
Posté par HappyPeng . Évalué à 2.
[^] # Re: Mutualisation ?
Posté par gnumdk (site web personnel) . Évalué à 1.
XUL? :) Avec le port vers qt (pas encore stable), y'aura plus ce genre de probleme.
Mais faire une appli en XUL, je suis pas sur, mais doit surement limité sur les possiblité de gtk et de qt. Et puis une pile d'abstraction de plus, ca veut dire un truc plus lent.
[^] # Re: Mutualisation ?
Posté par Yusei (Mastodon) . Évalué à 3.
Je prend un exemple de divergences qui serait difficile à résoudre: QT propose un mode MDI (interface multi-documents) à la Windows, c'est à dire avec des fenêtres dans une fenêtre. GTK ne propose pas cela, et c'est volontaire, car ils pensent que c'est une hérésie au niveau de l'interface (et je suis d'accord). Que faire ?
[^] # Re: Mutualisation ?
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Moi je trouve que l'interface de The Gimp qui n'utilise pas le mode MDI est une hérésie. Que dois-je faire ? :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Mutualisation ?
Posté par Yusei (Mastodon) . Évalué à 7.
Sans rire, c'est pas un troll, gérer les fenêtres c'est le boulot du gestionnaire de fenêtres, si le toolkit s'en mêle ça fout un boxon pas possible. Il suffit de prendre une application KDE utilisant le MDI-à-la-Windows, et de la faire tourner avec un autre gestionnaire de fenêtres que kwin pour voir que ça déconne puisqu'on a des fenêtres qui se comportent différemment des autres fenêtres.
Typiquement pour utiliser Gimp, c'est bien d'avoir des bureaux virtuels, la possibilité de marquer les fenêtres comme omniprésentes, et la possibilité de "remonter" toutes les fenêtres appartenant à la même application. Avec tout ça, l'interface est bien plus agréable que celle de Photoshop-Windows (je trouve).
[^] # Re: Mutualisation ?
Posté par Yusei (Mastodon) . Évalué à 6.
[^] # Re: Mutualisation ?
Posté par gnumdk (site web personnel) . Évalué à 4.
L'avantage d'une interface avec onglets sur le mode MDI et le mode GIMP(appelons le comme ca):
- Acces à tous les documents rapidement , en mode MDI, c'est la galère, il faut souvent passer par un menu fenetre
-Acces à tous les boites à d'outils quel que soit le document: avec The GIMP, on passe son temps a chercher les fenetres d'outils, il est quand meme bien plus sympa d'avoir tout d'accessible directement.
C'est pour ca que j'aime beaucoup krita qui utilise ce systeme d'onglets(qui ressemble pour l'instant à celui des tableurs), malheureusement, krita ne sera jamais un équivalent de The GIMP :( Donc, j'espere franchement que l'interface de The GIMP évoluera.
[^] # Re: Mutualisation ?
Posté par Yusei (Mastodon) . Évalué à 1.
Par contre pour les boîtes à outil, je ne comprend pas ce que tu veux dire, sur le fait de passer son temps à chercher les fenêtres d'outils. Tu ne savais pas que Gimp propose une interface à onglets ? Tu peux "docker" toutes les boîtes à outil les unes dans les autres, et te faire l'interface que tu veux.
[^] # Re: Mutualisation ?
Posté par 태 (site web personnel) . Évalué à -1.
L'avantage du mdi, c'est la possibilite de voir plusieurs fenetres de niveau equivalent simultanement, ce qu'empechent les onglets.
C'est pour ca que pour utiliser firefox confortablement, il faut accepter de voir les pop ups dans une autre fenetre (je parle des pop-ups "utiles" du style remplisser ces cases avant de poster votre reponse...) alors qu'opera reste confortable avec plusieurs instances...
Et bien souvent, les onglets font double emploi avec une utilisation intelligente des tabs du gestionnaire de fenetres (ah, gnome/metacity et kde/kwin ne font pas de tabs).
[^] # Re: Mutualisation ?
Posté par HappyPeng . Évalué à 1.
[^] # Re: Mutualisation ?
Posté par Croconux . Évalué à 1.
Pas forcément. On peut envisager un système modulaire façon X11 ou OpenGL constitué d'un noyau de fonctionnalités de bases plus des extentions. Quand on a besoin d'une extention, on teste si elle est disponible ou pas. Comme ça peut tirer le meilleur parti de chaque toolkit.
[^] # Et Conglomerate ?
Posté par durandal . Évalué à 5.
Conglomerate (http://conglomerate.org/,(...) copies d'écran ici : http://conglomerate.org/shots.html(...)) est aussi un éditeur XML, et il utilise aussi les bibliothèques Gnome. Il a l'air pas mal pour éditer des documents DocBook, avec une visualisation assez belle je trouve, mais il peut éditer tous types de documents XML, donc je pose la question :)
[^] # Re: Et Conglomerate ?
Posté par t00nsy . Évalué à 3.
A côté de ça il y a une foultitude de features présentent dans MlView qui n'existent pas dans conglomérate (cf les changelogs et autres features list pour s'en rendre compte).
[^] # Re: Et Conglomerate ?
Posté par Dodji Seketeli . Évalué à 9.
La difference fondamentale entre MlView et conglomerate reside effectivement dans l'architecture multi vues de MlView. Le multi vues est la possibilité a un moment donné d'editer un document XML en utilisant potentiellement plusieurs types de vues. Example, on est en train d'editer le doc en utilisant une vue orienteé "source" (une vue qui ressemble a celle presentée par un editeur tel screem ou bluefish) et subitement, on veut par example couper un sous arbre, et le coller à un autre entre endroit. Pour une telle operation, il est plus adequat d'utiliser une vue arborescente, ou on voit le doc sous la forme de d'un arbre de noeuds.
Hop, on cree une nouvelle vue d'edition sur le meme document. Dans cette vue, hop, on coupe le noeud (le sous arbre) , hop on le colle ou on veut. Hop, on revient sur notre vue orientée source et toutes les modifications qu'on a fait dans la vue arborescente sont repercutées en temps reel sur la vue source courante.
Une telle orientation multi vues necessite des choix architecturaux forts. Ce n'est pas "juste" une question de GUI.
Aujourd'hui, il est vrai que MlView n'offre qu'une vue qui est parfaitement operationnelle. La vue arborescente. Mais nous comptons serieusement developper d'autres types de vues d'editions. Nous pensons qu'en matiere
d'edition XML, il existe plusieurs cas d'utilisation possible. Pour adresser ces differents cas d'utilisation, il est logique de penser qu'il faut plusieurs types differents de vues d'edition. Mais, il fallait bien commencer par une vue ...
Pour les autres, Il nous faut juste du temps (et bien sur, plus de contributeurs ca peut aider ;) ) .
Une autre difference entre conglemerate et MlView reside dans le model de developpement. Pour MlView, nous avons choisis un model de developpement distribué. Nous utilisons GNU ARCH. Chaque contributeur (developpeur, redacteur de doc, designer du site web) a son archive de source. Il produit des patchs et les soumet au mainteneur. Celui ci les integre dans un arbre de source de reference. Chaque contributeur peut par ailleurs, se synchroniser avec l'arbre de reference. Il n'y a pas de depot central de source dans lequel tout le monde doit commettre les sources. Il n'y a donc pas de discrimination faite entre ceux qui ont le droit d'ecriture dans le "CVS" et les autres. Nous synchronisons bien sur
l'arbre de sources de reference avec le CVS de GNOME (les sources de MlView sont aussi presents dans le CVS de GNOME) afin que les traducteurs puissent travailler.
Pour conclure, je dirai que MlView et conglomerate sont
deux manieres d'aborder la problématique de l'edition XML. Le fait d'avoir deux
projets permet de tirer de tirer tout le monde vers le haut et au final, c'est GNOME qui gagne.
[^] # Re: Et Conglomerate ?
Posté par Ramso . Évalué à 2.
Un autre point je pense, même si je n'ai pas testé conglomerate de fond en comble, entre deux plantages (là j'essaye de compiler la version CVS), c'est que mlview semble plus adapté s'il faut saisir des attributs aux éléments.
En gros, mlview pour les techos et conglomerate pour les rédacteurs. Il ne fait donc aucun doute que les deux ont le mérite d'exister.
Quant au dynamisme du développement de conglomerate, je suis en train de voir pour y participer.
[^] # Re: Et Conglomerate ?
Posté par Dodji Seketeli . Évalué à 4.
L'interet du multi vues encore une fois. Si tu veux avoir une idee plus précise
du design de MlView (meme si tu es plus interessé par conglomerate)
tu peux jetter un coup d'oeil à http://www.seketeli.org/dodji/articles/mlview-internals/(...) .
Okay, cette vue n'a pour l'instant pas le merite d'exister, mais si cet aspect t'interesse, on peut imaginer une vue qui permette a l'utilisateur de taper son xml de maniere textuelle comme il le ferait dans un logiciel de traitement de texte.
La rendu tu texte pourrait etre piloté par du CSS par example ... je sais, c'est tres dur. Mais ce n'est pas une raison pour ne pas essayer.
# Rendu et CSS
Posté par Christophe Duparquet (site web personnel) . Évalué à 3.
Quelqu'un saurait-il dire si gecko pourrait être une solution ? Il me semble que c'est un moteur de rendu qui répond au cahier des charges mais je ne sais pas s'il est simple à intégrer. Des connaisseurs ?
<mavie>
À titre perso j'expérimente un système d'édition de documents 'sémantiques' : je saisis le contenu en XML, le système ajoute la mise en forme au moment de la traduction, en Latex ou en HTML+CSS. C'est écrit en Pyhon. Pour le moment, je dois saisir le code XML et c'est pas spécialement drôle même avec l'assistance d'emacs. Un éditeur offrant une vue formatée serait appréciable (un peu comme Lyx).
</mavie>
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Rendu et CSS
Posté par Dodji Seketeli . Évalué à 1.
Oui, explorer gecko n'est pas du tout une mauvaise idée, à mon avis.
Bon, le petit hic, c'est que cela demande beaucoup de travail.
En particulier, il faudrait que nous puissions partager le meme DOM que gecko.
Effectivement, il faudrait que MlView puisse échanger les evenements d'édition du DOM avec gecko. Il se trouve que MlView utilise libxml2 aujourd'hui, et gecko utilise biensur autre chose. Il faudrait que nous trouvions une solution qui nous permette communiquer. Peut etre porter MlView sur libgdome, et faire de meme avec gecko ? (beaucoup de travail, mais pas forcement une mauvaise idée).
Je n'ai pas encore d'idée arretée sur la question.
Les contributions seront les bienvenues ;)
Dodji.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.