Journal Tomboy re-écrit en C++

Posté par  .
Étiquettes :
8
16
avr.
2009
Un petit journal pour signaler aux personnes intéressé par avoir un remplaçant à tomboy qu'une re-écriture de ce logiciel dans un autre langage (C++) a eu lieu. On peut remercier Hubert Figuière pour cela. D'après les premiers commentaires que j'ai pu lire il y a eu grâce à cela une un amélioration très notable de la rapidité.

Le liens annonçant le projet:

http://www.figuiere.net/hub/blog/?Gnote

et un ppa pour ubuntu a été mis en place:

https://launchpad.net/~vperetokin/+archive/gnote

  • # Novell

    Posté par  . Évalué à 5.

    On peut quelque part « remercier » Novell qui s'est récemment défait d'Hubert et qui du coup a fait ça pour passer le temps en attendant de retrouver un emploi.

    • [^] # Re: Novell

      Posté par  . Évalué à 4.

      Ce qui veut aussi dire que le support du format de microsoft openxml dans openoffice.org est a peu près abandonné et que Novell a vraiment joué à l'enflure en le soutenant.

      • [^] # Novell... toxique pour le libre?

        Posté par  . Évalué à 1.

        Mouarf... en parlant des performances "douteuses" de Novell... on attend toujours leur driver 3D pour xorg. En effet, les p'tits gars de nouveau ont un meilleur support de la 3D et, eux, font du reverse engineer sur les GPU NVIDIA et n'ont pas l'ensemble des specifications qu'a fournit AMD.
        Hum... hum... ça sent mauvais...

        • [^] # Re: Novell... toxique pour le libre?

          Posté par  . Évalué à 3.

          Il me semble que dans la charette de licenciements se trouvait un des principaux développeurs de radeonhd. Donc effectivement, ça sent même très mauvais.

          • [^] # Re: Novell... toxique pour le libre?

            Posté par  . Évalué à 3.

            Sur ce coup là, si ce gars n'y arrive pas avec les specs alors que d'autres y arrivent sans specs et à coup de reverse engineering... je ne vais pas jeter la pierre à Novell...

    • [^] # Re: Novell

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

      tu laisserais entendre que le chômage profite au libre ?

      mais qu'attend le pôle emploi pour réintroduire tout le monde et nous fournir 4 000 000 de libristes en plus ?

      • [^] # Re: Novell

        Posté par  . Évalué à 6.

        Pourquoi payer des développeurs qui acceptent de travailler gratuitement ? ;-)


        --
        ça va trancher

      • [^] # Re: Novell

        Posté par  . Évalué à 2.

        Le Pôle Emploi attend peut-être tout simplement les effectifs nécessaires pour traiter l'arrivée massive de chômeurs de ces derniers mois. si j'en crois les derniers Canard, les agences sont au bord de l'implosion, "du nervous breakdown comme on dit de nos jours".

  • # un amélioration très notable de la rapidité

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

    un amélioration très notable de la rapidité.

    Comment se fait-ce ? Je croyais que grace au JIT le code C# était mieux optimisé en profondeur alors que le c++ qui est optimisé statiquement ne peut rivaliser ? On nous aurait bourré le mou pendant toutes ces années ?

  • # Mono

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

    Serait-ce la fin de mono dans Gnome?

    ;-)

    • [^] # Re: Mono

      Posté par  . Évalué à 4.

      non c'est la fin de Tomboy dans Gnome…

      • [^] # Re: Mono

        Posté par  . Évalué à 2.

        et comme c'était la seul application C# officiel dans Gnome...

        Enfin il y a les officieuses tel que banshee ou f-spot.

        • [^] # Re: Mono

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

          À ce propos, est-ce qu'il y a quelqu'un qui arrive à utiliser F-Spot ? À chaque fois j'essaye et je n'y comprends rien. En plus il fait n'importe quoi, me copie mes photos où je veux pas. Je n'ai jamais compris la hype autour de F-Spot car chez moi, c'est simplement inutilisable.

          Mes livres CC By-SA : https://ploum.net/livres.html

          • [^] # Re: Mono

            Posté par  . Évalué à 6.

            Euh idem j'utilise digikam bien plus puissant et bien plus dans ma logique à moi...

          • [^] # Re: Mono

            Posté par  . Évalué à 3.

            Ecoute moi je m'y retrouve très bien avec F-Spot, c'est une excellente application pour la gestion des photos. En plus je l'ai mise entre les mains de ma mère qui débute en informatique et elle arrive très bien à gerer ses photos. Il y a tout de même quelques trucs génant comme le fait qu'il reclasse toutes les photos.

            • [^] # Re: Mono

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

              idem pour f-spot. Comme toute application il faut un temps d'adaptation mais si tu le laisse gérer à 100% tes photos (ce pourquoi il est fait) c'est un très bon équivalent libre à picasa. Après que ce soit du mono ou du c++ ou que sais-je, a partir du moment ou il est :
              :
              1.Libre
              2.Bien intégré à l'environnement
              3.Ne bouffe pas trop de ressources ...

              Je vois pas où est le problème.

              • [^] # Re: Mono

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

                Peut-être dans le fait que même en réglant tout les menus par défaut de gnome (dans une ubuntu 8.04 par exemple) pour ne pas le démarrer ce truc persiste à se lancer à chaque branchement de carte mémoire d'appareil photo ? Ou alors là :
                « ...si tu le laisses gérer à 100% tes photos... »

                « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

              • [^] # Re: Mono

                Posté par  . Évalué à 8.

                Personnellement je n'ai pas l'utilité de ce genre d'appli, mais ma mère (la madame michu de référence de tout geek n'est-ce pas) si, et, confiant, je lui ai mis f-spot sur sa machine. Quelques temps plus tard, elle me glissa subtilement ("tu fais chier avec tes trucs que personne ne connaît") que sa copine elle, avait un truc qui s'appelait picasa et que c'était vachement mieux. Évidement, j'ai pensé (poils au menton oblige): ah l'attraction du bling bling et de la marque! ah la moutonnerie des consommateurs ignorants! Ah ça pu, c'est pas libre!
                Bon, par acquis de conscience, j'ai testé picasa (v3) pour montrer à ma mère que tu vois, grosso merdo c'est la même chose en pas pareil, et éventuellement chercher à améliorer la configuration de F-spot.

                Las, même avec une dose raisonnable de mauvaise foi, je n'ai pas pu me persuader que f-spot est "un très bon équivalent libre à picasa". libre et bien intégré à l'environnement, tu as cité les 2 seules arguments (important pour moi, pas pour ma mère) que l'on peut citer en faveur de f-spot, mais il est désespérément inférieur sur tous les autres points et principalement sur un point qui me semble important pour ce genre d'application: gérer et retrouver ses photos rapidement et sans prise de tête :)

                • [^] # Re: Mono

                  Posté par  . Évalué à 2.

                  Sans parler de l'esthétique et de la facilité d'utilisation, pas que sur le fait de retrouver ses photos rapidement...

                  à quand l'ouverture de Picasa ?

                • [^] # Re: Mono

                  Posté par  . Évalué à 5.

                  Tu as essayé digikam?

          • [^] # Re: Mono

            Posté par  . Évalué à 3.

            Moi !

            Je me contente de classer mes photos par "album", avec des tags supplémentaires si besoin.
            J'aime bien la "ligne de temps", et quelques options sympas comme la synchronisation avec des galleries en ligne.
            J'apprécie également le fait qu'on puisse conserver différentes versions de photos, selon qu'elles soient retouchées ou pas.
            Digikam & cie font certainement tout ça très bien, et même bien plus, mais pour simplement gérer mes photos je n'ai vraiment pas besoin de plus.
            Et en plus c'est en GTK, parfait pour mon bureau Gnome :)

          • [^] # Re: Mono

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

            GThumb est vraiment plus simple à utiliser et, avantage important, il n'utilise pas Mono.

            • [^] # Re: Mono

              Posté par  . Évalué à 1.

              Après avoir essayé Digikam, F-Spot, Jbrout et Picasa j'en suis venu à Gthumb également. Il est simple, rapide et intégré à Gnome. Si j'étais sous KDE j'utiliserais Digikam.

              J'ai un seul regret : je ne trouve pas le développement très actif comparé aux autres. J'ai l'impression que le projet est plus en mode 'bug fix' qu'en mode 'enhancement'.

              Dans tous ces logiciels de photos j'attend une killer feature qui me fera basculer vers l'un ou l'autre : la reconnaissance des visages comme sur picasaweb.

  • # Sacré Hubert !

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

    Il a annoncé cela sur son blog le 1er avril et beaucoup, moi y compris, ont pensé "trop gros pour un poisson mais bien essayé". Je l'ai même vu dans certaines petites sélections des meilleurs poissons d'avril du libre ;-)

    Mes livres CC By-SA : https://ploum.net/livres.html

  • # Vala ?

    Posté par  . Évalué à 6.

    Perso j'aurais plus vu un portage vers vala, le langage pour gobject qui déchire sa race. Mais bon, ça doit être mon côté qui ne comprend rien au C++ qui parle. :p

    Je suis tout de même content qu'on développe des équivalents aux programmes écrits en C# (ou tout autres langages .net). Ce n'est pas pour faire du troll.net, juste parce que ça permet d'avoir à installer tout le bazar mono alors qu'on a déjà tout ce qu'il nous faut par ailleurs.

    PS: genie¹ a aussi l'air très sympa.

    [1] http://live.gnome.org/Genie et http://puppylinux.com/genie/

    The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

    • [^] # Re: Vala ?

      Posté par  . Évalué à 2.

      Le C++ est perçu par beaucoup comme "overly complex".

      Il est très facile de tomber dans le bloat brainfucké avec le C++ dans un effort d'exploiter la "beauté" de ce langage bardé d'algos génériques saupoudrés de pleins de templates surchargés virtuellement d'opérateurs.

      D'ailleurs, il suffit de regarde le front-end C++ de GCC, la libstdc++ et l'abi C++ pour se rendre compte que ce langage n'est qu'a peine plus compliqué que le C a implémenté... c'est bien connu!

      (mouhahaha!)

      • [^] # Re: Vala ?

        Posté par  . Évalué à 1.

        Il est très facile de tomber dans le bloat brainfucké avec le C++ dans un effort d'exploiter la "beauté" de ce langage bardé d'algos génériques saupoudrés de pleins de templates surchargés virtuellement d'opérateurs.

        très joli troll! pourtant je trouve la logique et la puissance qu'amène tout ce foutoir des templates tellement puissante que je l'utilise de plus en plus (via std/boost/gtkmm). Mais c'est vrai, débugger des template c++ c'est le cauchemard...

        • [^] # Re: Vala ?

          Posté par  . Évalué à 1.

          Et la complexité d'implémentation?

          • [^] # Re: Vala ?

            Posté par  . Évalué à 2.

            C'est pas tant un problème que ça, si t'as un truc super efficace mais compliqué à implémenter, une fois le coût d'implémentation payé, c'est tout bon ...

            • [^] # Re: Vala ?

              Posté par  . Évalué à 2.

              C'est une question de compromis entre ce que ça apporte, et son "cout logiciel" (taille/complexité/qualité).
              Perso (et je ne suis pas le seul), le C++ n'est pas un bon compromis.

              • [^] # Re: Vala ?

                Posté par  . Évalué à 4.

                Au boulot, c'est C. Et j'ai besoin de tableau pour accéder vite aux données, mais je veux aussi pouvoir insérer, effacer rapidement un élément à partir de son index.
                J'ai donc fait une sorte de liste chaînée par index et pas par pointeur. Le problème c'est que l'appliquer à des nouveau type et un cauchemar en macro, faire du copier coller c'est bien, sauf pour une évolution, correction de bug, quand il y a dix type utilisé. Là où un jeu de fonction, structure "patron" serait très utile. Même pas besoin d'aller à la classe, le C++ c'est bien plus que la réduction habituelle à la classe.

                • [^] # Re: Vala ?

                  Posté par  . Évalué à 2.

                  L'intérêt des templates pour les structures de données est évident ...

                  Après j'ai du mal à voir l'intérêt d'implémenter une liste chaînée dans un tableau ...

                  Tu ordonnes tes éléments ? C'est pour parcourir l'ensemble de tes éléments en une seule passe comme avec une liste chaînée sans tester si une case est vide ?

                  C'est pour éviter les allocations / désallocations mémoires ? Parce que si c'est ça t'as des techniques genre les "memory chuncks" ou memory pool qui sont adaptées, par exemple dans glib : http://www.gtk.org/api/2.6/glib/glib-Memory-Chunks.html - et ça reessemble peut

                  Parce que pour l'accès rapide,
                  * soit tu as déja un indice dans le tableau et là c'est la même chose avec un pointeur ou un iterateur sur une liste chainée pour l'accès. Donc ça ne change rien, tableau ou liste.
                  * soit t'en as pas t'as besoin de rechercher ton élément, et là ce qu'il te faut c'est plus une table de hachage (on se rapproche du tableau), ou un arbre de recherche si tu ordonnes tes éléments (un set en C++ par exemple), sinon t'es obligé de parcourir toute ta liste ou tout ton tableau (et on se ramène au cas de la liste)

                  Donc la question principale, ça t'apporte quoi d'insérer / supprimer comme dans une liste ? une petite optimisation du temps de recherche ?

                  • [^] # Re: Vala ?

                    Posté par  . Évalué à 2.

                    Après j'ai du mal à voir l'intérêt d'implémenter une liste chaînée dans un tableau ...
                    Le seul intérêt, c'est de trouver un élément libre en O(1) et d'y accéder en O(1).

                    Tu ordonnes tes éléments ?
                    Non.

                    C'est pour parcourir l'ensemble de tes éléments en une seule passe comme avec une liste chaînée sans tester si une case est vide ?
                    Non plus. Je chaine juste les élément de façon a facilité l'usage de champ généraux : first_free_index, first_use_index et last_use_index.
                    J'obtiens un truc du genre :
                    struct
                    {
                    int first_free_index;
                    int first_use_index;
                    int last_use_index;
                    struct {
                    ...
                    int prev_index;
                    int next_index;
                    }
                    };

                    Pour ajouter un élément, je prends le first free, et je le chaine avec le first use, je déchaine avec le next du first free.
                    Pour enlevé un élément, je rechaine ensemble le prev et le next, je le note en first free, je le rechaine avec l'ancien first free.

                    C'est pour éviter les allocations / désallocations mémoires ?
                    Oui. Contrainte produit :-(

                    • [^] # Re: Vala ?

                      Posté par  . Évalué à 3.

                      D'ac, donc c'est du côté des "memory pool" qu'il faut chercher ...

                      Dans ces trucs pour faire générique, t'as besoin en gros de connaître la taille des trucs que tu veux stocker, t'as des fonctions genre "get next free elem" ou "free elem" qui te retournent un "void *" que tu n'as plus qu'à caster dans un pointeur vers le type en question. Du coup pour un type donner tu peux te limiter à faire des macros qui castent.

                      http://www.codeproject.com/KB/cpp/MemoryPool.aspx par exemple

                • [^] # Re: Vala ?

                  Posté par  . Évalué à 1.

                  Pour tes listes chaînées en C, tu as déjà regardé ce qu'ils font dans le kernel ? J'ai souvenir d'avoir vu un système de listes chaînées utilisant des macros. Ça avait l'air assez au point... Après, si j'ai bien compris, des fois, ils utilisent des extensions gnu (du coup, c'est pas du C pur).
                  Je suis sûr qu'il doit bien y avoir un dev kernel dans le coin qui décrira ça bien mieux que moi.

                  • [^] # Re: Vala ?

                    Posté par  . Évalué à 1.

                    En général, avec des listes chaînées, j'essaye (ça veut dire pas tout le temps) d'utiliser celles de Linux qui utilisent l'extension gnu qui consiste à trouver le pointeur du début d'une structure à partir du pointeur d'un des membres. En effet, le savoir du layout mémoire d'une structure est connu du compilateur (alignement, padding etc etc...), sauf si il est utilisé l'extension "packing de structure" où là il est possible de tout calculer sans le compilo, mais attention aux pertes de performances à cause des pbs d'alignement en mémoire (Ulrich Drepper, codeur de la libc et membre de POSIX, a fait des tests y a pas si longtemps, et à titre d'exemple le performance hit était de grosso modo 4x pour des structures pas correctement alignées).
                    J'ai utilisé directement le header de linux avec les 2-3 modifs qui vont bien pour qu'elles marchent en user space. Bon... c'est pas les listes protéger par RCU... ça serait trop beau.

      • [^] # Re: Vala ?

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

        Je vois souvent des commentaires du genre le C++ c'est truffé de trucs incompréhensibles, etc... mais rien ne vous oblige à utiliser toutes les features du C++
        Tu peux très bien coder en C++ comme tu le ferais en Java par exemple en te limitant toi même à de l'héritage simple, pas trop de templates, etc...
        Un très bon exemple de ça, c'est Qt: Ils se limitent à un sous ensemble de C++ et le tout reste très simple et très compréhensible.

        • [^] # Re: Vala ?

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

          Qt ne se limite pas à un sous ensemble. Les templates et l'héritage multiple sont utilisés. Même des pointeurs vers des fonction membres à certains endroits.

          Qt est juste une bibliothèque simple d'utilisation qui rends le C++ plus simple car les trucs de bas niveau sont déjà implémenté, laissant au programmeur la liberté de se consacrer au choses de plus aut niveau. Le tout avec une belle API multi-platforme, intuitive et facile à apprendre.

        • [^] # Re: Vala ?

          Posté par  . Évalué à 1.

          Il y a effectivement le pb de la tentation d'utiliser un maximum toutes les fonctionnalités du C++... ce fameux syndrôme qui amène vite les programmes C++ à l'usine à gaz.

          L'autre aspect, que même une hygiène de code drastique en C++ ne peut éviter, est le "cout logiciel" du C++ en lui-même. Voir:
          - front-end C++ de GCC
          - libstdc++
          - ABI C++

    • [^] # Re: Vala ?

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

      Mouais "j'investirais" pas dans le language Vala. Quid dans 2 ans du programme que j'ai developpe ? je prefere "investir" dans un language normalise/standardise qui dans quelques annees n'aura pas completement change ni ne me petera au pif

      En meme temps, si c'est pour un petit projet perso pourquoi pas :)

      • [^] # Re: Vala ?

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

        > prefere "investir" dans un language normalise/standardise qui dans quelques annees n'aura pas completement change ni ne me petera au pif

        Ben oui, justement ! Pourquoi C++ et pas Scheme ou Common Lisp ?

    • [^] # Re: Vala ?

      Posté par  . Évalué à 4.

      ...ça permet *de ne pas avoir* tout le bazar mono alors qu'on a déjà tout ce qu'il nous faut par ailleurs.

      Relecture fail!

      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

  • # Superbe nouvelle

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

    tomboy était la dernière appli mono qui résidait sur mon poste ;-) ...
    Je suis maintenant mono-free ;-)
    C'est vraiment une excellente nouvelle ...

    • [^] # Re: Superbe nouvelle

      Posté par  . Évalué à 5.

      Maintenant il faut que mono ne soit plus installé par défaut dans les distros les plus populaires...

    • [^] # Re: Superbe nouvelle

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

      Je viens de migrer mes notes ;-)
      un simple "mv ~/.tomboy/*.note ~/.gnote", et un "sudo apt-get purge tomboy" ;-)

      ça se lance à la vitesse de la lumière, et ça prends rien en ressources (--> je vais le mettre en lancement au démarrage session ;-) )

      que du bonheur ;-)

      • [^] # Re: Superbe nouvelle

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

        et ça y est je suis mono-free ;-)
        j'ai poussé le vice jusqu'à un "sudo apt-get purge mono-common" ;-)
        (103Mo de libs mono en moins ... ça faisait cher pour juste tomboy)

        • [^] # Re: Superbe nouvelle

          Posté par  . Évalué à 5.

          Oui c'est une bonne nouvelle, car tomboy en plus de bouffer inutilement des resources me faisaient sans arrêt de erreurs de segmentation... Je ne sais pas si c'est un problème spécifique à ma distro ou pas mais toujours est-il que la version en c++ fonctionne à merveille !

        • [^] # Re: Superbe nouvelle

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

          C'est surtout qu'avoir des paquets inutiles installés, c'est autant de mises à jour inutiles à installer aussi...

          • [^] # Re: Superbe nouvelle

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

            et je le vois déjà ;-)
            car en pleine dist-upgrade de jaunty beta vers jaunty rc ...
            (ça doit pas faire loinde 100mo en moins à DL)

  • # C'est quoi ?

    Posté par  . Évalué à 3.

    Juste, c'est quoi tomboy ? Un jeu avec Tom écrit en C# ?*

  • # Python, Ruby, etc

    Posté par  . Évalué à 2.

    Ce n'est pas juste un troll. Mais quelle est la motivation de ce « fork » ? une plus grande rapidité, ou une indépendance aux technologies brevetées de Microsoft ?

    Parce que personnellement, j'aurai tendance à pense que le le c, c++ etc est plus adapté à du code demandant de fortes ressources (créations des libs, codecs, algorithmes de calculs, etc) et les languages de très haut niveau tels Python, Ruby et autres pour la création d'interface.

    En effet, quelles différences de performances pour la création d'une « boite à boutons » en c et en python ?
    La complexité de programmation (et donc de maintenances, etc) a-t-elle ici une utilité ?

    • [^] # Re: Python, Ruby, etc

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

      En tous cas on ne compte plus les langages de haut niveau installé sur nos distribs :

      python, ruby, perl, mono, quel sera le prochain ?

    • [^] # Re: Python, Ruby, etc

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

      L'idée est ancienne, et je pense que ce post de l'époque doit résumer un peu ses motivations:
      http://www.figuiere.net/hub/blog/?2006/07/26/428-porting-tom(...)

    • [^] # Re: Python, Ruby, etc

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


      Parce que personnellement, j'aurai tendance à pense que le le c, c++ etc est plus adapté à du code demandant de fortes ressources (créations des libs, codecs, algorithmes de calculs, etc) et les languages de très haut niveau tels Python, Ruby et autres pour la création d'interface.

      C'est sûr que l'avantage du c++ est plus marqué pour les trucs qui consomment beaucoup de ressources, mais même pour une application simple comme tomboy, ça fait une différence, et si tu comptes le nombre de petites applis qu'on a sur un pc standard et que tu les additionnes, tu verras l'intérêt de les écrire dans un langage qui permet une bonne vitesse à l'éxécution.

      Je n'ai rien contre les langages de haut niveau, mais à mon sens c'est plus pour faire du prototypage ou des projets limités que pour distribuer à la moitié de la planète.

Suivre le flux des commentaires

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