L'éditeur HTML Nvu 0.40 est sorti

Posté par  (site web personnel) . Modéré par Pascal Terjan.
Étiquettes :
0
11
août
2004
Mozilla
La version 0.40 de Nvu, l'éditeur HTML basé sur Mozilla Composer soutenu par Linspire Inc. (anciennement Lindows Inc.) à travers Disruptive Innovations vient de sortir. Outre les sources, des binaires pour Windows et GNU/Linux x86 (noyau 2.4.x, gcc/g++ 2.95.4, gtk2, Xft) sont disponibles.

C'est une version majeure, basée sur Mozilla 1.7.1, beaucoup plus stable que la 0.30 et apportant des nouvelles fonctionnalités plutôt intéressantes comme la retouche des colonnes et lignes de tableau à la souris ou la validation du code dans l'application sans appel à un navigateur externe. NdM : les changements
- basé sur Mozilla 1.7
- retaille des éléments à la souris, notamment les colonnes et lignes de tableau
- argument en ligne de commande "nvu -edit "
- affichage des résultats du validateur W3C dans Nvu
- menu contextuel sur les onglets pour en fermer un ou tous
- possibilité de créer des tableaux sans alignement vertical ou horizontal par défaut
- affichage correct du titre dans les onglets
- menu contextuel sur les barres d'outils
- correction sur le réglage de la taille des images
- plus de perte de sélection lors d'un changement d'onglet
- entrée de menu À propos
- inspecteur de documents

Aller plus loin

  • # gtk2+ xft

    Posté par  (site web personnel) . Évalué à 1.

    Pourquoi est ce que tout les softs basé sur mozilla sont compilé avec gtk2 et xft? Les versions linux sont déja bien plus lentes que les versions windows mais si en plus on rajoute l'antialiasing, ça devient vraiment très lent. Graphiquement, je trouves ça moche et plus génant qu'autre chose(et oui, mon systeme est bien configuré, j'aime pas, c'est tout)

    C'est vrai, je peux désactiver l'antialiasing avec un export GDK_USE_XFT mais si on utilise xinerama, ça freeze en 2 min.
    • [^] # Re: gtk2+ xft

      Posté par  . Évalué à 2.

      c'est sur que comparé à l'interface de moz sous Windows, la version GNU/Linux est bien plus lente...

      dommage pour un si bon browser sous un si bon OS :(
      • [^] # Re: gtk2+ xft

        Posté par  . Évalué à 7.

        Hmmm, cela ne se limite pas à Moz, Regardes aussi OpenOffice ! Regardes la lenteur générale de X + GDK/GTK ou QT/KDE !

        Si au moins on pouvait avoir un système de widget implémenté comme une extension (unique) au protocole X, et rendu côté serveur (comme PicoGUI), et un serveur X implémenté au dessus d'une lib graphique 2D/3D (comme OpenGL) optimisée pour être en bas de la pile...
        • [^] # Re: gtk2+ xft

          Posté par  . Évalué à 2.

          serveur X implémenté au dessus d'une lib graphique 2D/3D (comme OpenGL)
          Ca me fait penser que les specifications d'OpenGL 2.0 sont sorties :
          http://www.sgi.com/newsroom/press_releases/2004/august/opengl.html(...)
        • [^] # Re: gtk2+ xft

          Posté par  . Évalué à 5.

          Bof, je suis d'accord que les interfaces graphique "normale" de Linux sont lentes (BeOS 'etait nettement plus rapide), maintenant as-tu des benchmark qui prouvent que c'est la partie X + ( GDK/GTK ou QT/KDE ) qui est lente?

          Cela pourrait tres bien etre de la faute des applications aussi..

          La regle d'or de l'optimisation est qu'il faut profiler d'abord pour voir ou se trouve la lenteur, et avant de "tout casser" encore faudrait-il avoir la preuve que c'est bien la cause de la lenteur, non?

          Moi aussi l'architecture de type PicoGUI me parait plus elegante, mais je n'ai jamais vu de benchmark qui prouvait que la faute venait d'X et/ou des toolkits plutot que des applications..

          [ HS ] Dans le DrDobbs d'aout, il y a un article de Michael Abrash qui raconte avoir pass'e du temps a optimiser la mauvaise partie d'une application car il n'avait pas profiler correctement l'application avant et pourtant c'est un expert!
          [ /HS ]
          • [^] # Re: gtk2+ xft

            Posté par  (site web personnel) . Évalué à 4.

            Bof, je suis d'accord que les interfaces graphique "normale" de Linux sont lentes (BeOS 'etait nettement plus rapide), maintenant as-tu des benchmark qui prouvent que c'est la partie X + ( GDK/GTK ou QT/KDE ) qui est lente?

            Il suffirai de tester la vitesse des interfaces graphiques des applications utilisant GTK ou QT sous Windows et de les comparer avec GTK ou QT sous GNU/Linux, je pense que les résultats ne laisseront aucun doute...

            Mon expérience personnelle du bureau Linux me montre que quel que soit l'application utilisée, la boîte à outils (Motif, GTK ou QT), l'affichage me semble lent et l'interface peu réactive. Bien sûr on le ressent moins sur un Pentium 4 2.5 Ghz que sur un PII 400Mhz. Mais pour la gestion de fenêtres et de widgets, un PII 400Mhz et 64Mo de RAM devraient normalement donner pleine satisfaction.

            Mes quelques tests de développement avec la Xlib m'ont intiment persuadé que X11 est ce goulot d'étranglement.
            D'ailleurs j'avais traduit cet article voilà bientôt deux ans :
            http://linux.tlk.fr/articles/xfree86_accelerer.php(...)

            Souhaitons bonne chance à X.org, ce fork de XFree86 devrait améliorer les choses dans le bon sens, d'ailleurs la X11R6.8 devrait sortir le 25 août 2004 http://wiki.freedesktop.org/XOrg/XorgReleasePlan.(...) Des projets prometteurs comme DirectFB ou PicoGUI n'attendent qu'une chose, de lui piquer sa place :-)
            • [^] # Re: gtk2+ xft

              Posté par  . Évalué à 2.

              > Il suffirai de tester la vitesse des interfaces graphiques des applications utilisant GTK ou QT sous Windows et de les comparer avec GTK ou QT sous GNU/Linux, je pense que les résultats ne laisseront aucun doute...

              Je ne sens pas beaucoup de difference entre Windows et Linux, les deux "rament" pareil pour moi, mais je pense que tu as raison pour les petites configurations.

              Avec BeOs au depart je pensais que la vitesse etait due a une interface graphique bien pensee, mais apres je me suis rendu compte que c'est plutot due a une bonne utilisation du multi-threading..

              >Mes quelques tests de développement avec la Xlib m'ont intiment persuadé que X11 est ce goulot d'étranglement.

              J'ai programm'e un peu aussi en Xlib, j'avais ete surpris par la "verbosite" du protocole: le nombre d'evenement genere au moindre deplacement de souris est impressionnant (et sous-optimal a mon avis)..

              >D'ailleurs j'avais traduit cet article voilà bientôt deux ans :
              http://linux.tlk.fr/articles/xfree86_accelerer.php(...(...))

              Oui, je m'en souviens, d'ailleur merci pour la traduction, j'avais eu du mal a comprendre l'original et j'avais bien apprecie la traduction.
              Mais cet article ne donne des benchmark que pour la partie XFree donc il est difficile de savoir si c'est la le probleme..
            • [^] # Re: gtk2+ xft

              Posté par  (site web personnel) . Évalué à 3.

              "X11 est ce goulot d'étranglement. "

              C'est complètement faux. La plus part des trace fait montre que les bibliothèques de widget utilises très mal X et empèche de faire correctement remplir le pipeline graphique.

              Je me rappelle d'un test d'Alan Cox sur un browser de fichier où il montrait un certain nombre de round-trip qui prennait un temps fou et qui n'avait aucun interret.

              Il faudrait plutot optimiser Qt et gtk qu'autre chose...

              "La première sécurité est la liberté"

              • [^] # Re: gtk2+ xft

                Posté par  . Évalué à 5.

                Et supprimer les memory leaks au passage... car ça devient le parcours du combattant de retrouver les fuites dues à son propre code lorsqu'on code avec gtk ou Qt...
            • [^] # Re: gtk2+ xft

              Posté par  . Évalué à 2.

              Es-tu sur que on test n'a pas démontré que c'est la Xlib qui est le goulot d'étranglement et pas X lui même ?

              BeOS le faisait il y a 20 ans !

        • [^] # Re: gtk2+ xft

          Posté par  . Évalué à 2.

          Moz et OOo sont une usine a gaz. Ce sont de tres mauvais exemples.

          OOo comporte plus de 7.5 millions de ligne de code. Quand tu vois comment c'est foutu, tu comprends que ca rame.

          Par contre, je sais pas ce qu'il en est de la difference entre ces logiciels sur win ou sur GNU/linux. Ni d'ou provient la difference. Comme l'a justement dit reno, il faut s'en assurer avant de tout revoir.
          • [^] # Re: gtk2+ xft

            Posté par  . Évalué à 2.

            j'ai pu comparé le Moz et le Firefox (ou encore Firebird ?) de Woody dans une configuration difficile.

            et le vieux Moz était bien plus à l'aise que le Firefox dont les menus ramaient à mort...
    • [^] # Re: gtk2+ xft

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Je pense que la non-réactivité de nos chères outils vient du fait qu'ils ne sont pas compilés avec la pthread.

      Chez moi, mon Thunderbird bloque au démarrage, lorsqu'il contacte pour la première fois les serveurs SMTP...
    • [^] # Re: gtk2+ xft

      Posté par  (site web personnel) . Évalué à 1.

      Parceque tu fais parties des rares personnes que avoir un mozilla utilisant un toolkit moderne avec antialiasing gene. Va falloir t'y faire...
      • [^] # Re: gtk2+ xft

        Posté par  (site web personnel) . Évalué à -1.

        Eh ben, vive l'évolution...
      • [^] # Re: gtk2+ xft

        Posté par  (site web personnel) . Évalué à -1.

        Mais bon, moi ce qui me gene, ce n'est pas l'aa, tant que je peux le désactiver(ce qui n'est pas le cas), c'est que ce soit plus lent.
        • [^] # Re: gtk2+ xft

          Posté par  . Évalué à 1.

          A partir du moment où Render (l'extention qui gère l'anti-aliasing) n'est pas accéléré, on ne peut s'étonner du contraire.

          La prochaine version de xorg devrait apporter cette accélération, au moins pour les possesseurs de radeon.
    • [^] # Re: gtk2+ xft

      Posté par  (site web personnel) . Évalué à 2.

      J'ai déjà vu des question bêtes mais celle-là bat des records...
      Pourquoi est ce que tout les softs basé sur mozilla sont compilé avec gtk2 et xft ?
      Voila pourquoi:
      1989 => 2004
      --------------------
      gopher => http
      uuencode => mime
      minitel => web
      sgml => xml
      sunos4 => linux
      tty => xft
      Linux n'atteindra jamais la diffusion de masse tant qu'on posera des questions de ce type. Mettez un non-babasseur devant une fonte non lissée et il fera "berk". C'est tout. En cinq secondes, vous avez cassé Linux chez un utilisateur potentiels pour trois ans. Encore bravo :-)
  • # bof

    Posté par  . Évalué à 10.

    Toujours pas de coloration syntaxique, ce n'est pas encore aujourd'hui que j'utiliserais nvu.
    • [^] # Re: bof

      Posté par  (site web personnel) . Évalué à 6.

      Ce serait bien de faire un comparatif de toutes les solutions libres pour faire des sites web.
      Il y aurait maintenant de quoi faire un bel article et de beaux trolls.
      D'ailleurs je vais commencer le troll à la façon de Cyrano de Bergerac, sans la verve de Rostand mais traduit en langage geek courant :

      <troll class="naif"> Personnellement, j'utilise gvim et je trouve ça très bien ;-)</troll>
      <troll class="barbu">Tout le monde devrait utiliser emacs !<ttroll>
      <troll class="inria">C'est mieux qu'Amaya ?</troll>
      <troll class="prudent">On peut utiliser à la place ou en plus de Quanta ?</troll>
      • [^] # Re: bof

        Posté par  (site web personnel) . Évalué à 3.

        Tag not closed at line 3:
        <troll class="barbu">Tout le monde devrait utiliser emacs !<ttroll>
        <troll class="inria">
      • [^] # Re: bof

        Posté par  . Évalué à 2.

        C'est vrai qu'il y en a pour tout les gouts:
        en plus de nvu et de ceux que tu a cité:

        Screem
        Bluefish
        Mozilla Composer (mozilla -editor)
        OpenOffice (ooweb)

        Ou encore des solutions plus « exotiques » :
        Lyx
        Conglomerate
        latex2html (hyperlatex, hevea, ...)
        Abiword

        etc ...
    • [^] # Re: bof

      Posté par  . Évalué à -4.

      envoie un patch.
    • [^] # nvu colloration

      Posté par  (site web personnel) . Évalué à 2.

  • # NVU est sur la bonne voie

    Posté par  (site web personnel) . Évalué à 2.

    J'utilise NVU depuis un bon bout pour faire quelque page simple. Il est sur la bonne voie, et ce pour sûr.

    Mais cependant, je dois toujours retoucher le HTML à la main par après. Je trouve que ce que NVU génère ne vaut pas grand chose. Il m'aide à générer mon interface, mon layout, mais à part ça, je me vois pas mettre ce code là sur le web...

    Mais je trouve que cette nouvelle version est déjà mieux.

    Jeff Saucier

  • # Un binaire dépendant d'une version du noyau ?

    Posté par  . Évalué à -4.

    Outre les sources, des binaires pour Windows et GNU/Linux x86 (noyau 2.4.x, gcc/g++ 2.95.4, gtk2, Xft) sont disponibles.

    nvu.com : nvu-0.40-pc-linux-gnu.tar.gz - Tarball built on Linspire (Debian k2.4) gcc/g++ 2.95.4

    Déjà préciser le compilateur, c'est totalement inutile, mais alors le noyau de la machine qui a compilé le binaire, je m'en balance violemment le sgeg !

    [-1] (ah non, [0] en fait)
    • [^] # Re: Un binaire dépendant d'une version du noyau ?

      Posté par  . Évalué à 5.

      Ca dépend... Vu le bordel que c'est l'ABI C++, quand tu veux compiler galeon/epiphany en utilisant un mozilla précompilé, c'est important de savoir le compilateur utilisé, idem pour utiliser un plugin java avec un mozilla précompilé, ça a été un peu le bordel au moment de la transition gcc 2.95/gcc 3
      Donc ça peut pas faire de mal de préciser le compilo utilisé...
  • # Le sponsoring ca marche bien.

    Posté par  . Évalué à 2.

    j'ai rien en particulier contre Linspire, mais c'est la seul boite a soutenir un projet libre? Je me trompe peut-etre, mais il me semble que c'est la seul dont on rappelle le sponsoring avec tant d'assiduité...

    Je vais finir par m'acheter une boite de lindows moi.
    • [^] # Re: Le sponsoring ca marche bien.

      Posté par  . Évalué à 1.

      Sans vouloir être méchant, tu es à côté de la plaque. Il y a énormément de boites qui soutiennent des projets libres, seulement elles ne communiquent autant sur ce sujet.
      • [^] # Re: Le sponsoring ca marche bien.

        Posté par  (site web personnel) . Évalué à 4.

        Je crois que c'était ironique, c'est justement le propos de sa remarque : il n'y a pas que linspire, mais ce qu'on peut en parler, ventre-saint-gris ! La lobotomie crée par cet excès va faire qu'il va s'en aller quérir une boite de linspire.
  • # Une 0.41 vient de sortir

    Posté par  (site web personnel) . Évalué à 8.

    Pour ceux qui se servent de Nvu en production (j'en fais partie), il est bon de signaler qu'une 0.41 est déjà sortie pour corriger un bug embêtant sur la gestion de sites distants (méthodes http et ftp).
  • # Powered by Gecko

    Posté par  (site web personnel) . Évalué à 2.

    Si je suis encore dans le coup, ça signifie que le moteur de Mozilla est utilisé, mais est-ce uniquement pour le rendu où y-a-t'il d'autres utilisations possibles?
    Et qu'en est-il de XUL? Je ne connais pas (encore) cette technologie mais j'aurais bien jeté un oeil aux sources si XUL était de la partie, car visiblement l'interface ne fonctionne qu'en anglais (le changement de langue ne s'opère pas) et lorsque j'ai tenté de rechercher des extensions j'ai eu un beau message d'erreur.
    Ah et puis 'esearch -S nvu' me fait comprendre que ce ne sera pas de la tarte de l'installer sous Gentoo...
    • [^] # Re: Powered by Gecko

      Posté par  . Évalué à 2.

      > Ah et puis 'esearch -S nvu' me fait comprendre que ce ne sera pas
      > de la tarte de l'installer sous Gentoo...

      Tu peux toujours surveiller ce bug, c'est là que l'écriture de l'ebuild se trame :
      http://bugs.gentoo.org/show_bug.cgi?id=40821(...)
      • [^] # Re: Powered by Gecko

        Posté par  (site web personnel) . Évalué à 3.

        Tu peux toujours surveiller ce bug, c'est là que l'écriture de l'ebuild se trame :
        http://bugs.gentoo.org/show_bug.cgi?id=40821(...(...))

        Merci Thomas, j'avoue sans grande honte que le terme bug est toujours resté péjoratif à mes yeux. Par conséquent je n'ai pas le réflexe de considérer l'absence d'une application comme un bug. Et puis j'éprouve toujours une certaine réticense à publier un bug. C'est comme si je me sentais désobligeant au lieu d'être respectueux vis-à-vis du développeur. Bref de vieilles habitudes du "monde propriétaire" à bazarder vite fait si je ne veux pas me retrouver en retraite anticipée...
        Merci.
        • [^] # Re: Powered by Gecko

          Posté par  . Évalué à 2.

          Ceux qui demandent un nouveau logiciel n'y sont pour rien, c'est bugzilla qui veut que toute modif soit "une correction de bug".

          Ils auraient pu appeler ca une tache (task), mais bon...
  • # Nvu pour osX??

    Posté par  . Évalué à 1.

    Bonjour, j'aimerasi savoir comment installer Nvu sur Mac osX??

    Merci

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.