Ultracopier 0.4

Posté par  (site web personnel) . Édité par Benoît Sibaud, baud123, NeoX et claudex. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
24
30
déc.
2012
Linux

Pour ceux qui ne le connaissent pas, c'est un utilitaire de copie de fichiers, c'est-à-dire qu'il remplace la boîte de dialogue qui s'ouvre quand on fait un copier-coller.

La refonte introduit principalement la réécriture en Qt5 (nouvelles classes, nouveau système signal/slot…), le gain de performance à certains endroits est impressionnant. Le code n'est donc plus compatible Qt4.
Qt5 corrige le principal bug qui était l'absence d'interception de copie quand l'User Account Control (UAC) était actif sous Windows.

Plus de détails dans la suite de la dépêche.

Voilà les questions qui peuvent se poser :

Pourquoi faire le remake en Qt5 ?

Pour corriger un certain nombre de bugs qui traînent depuis Qt4 : pas d'interception de la copie avec l'UAC sous Windows car le pipe nommé pour faire le QLocalServer n'est pas initialisé avec les bons attributs de sécurité. Cela corrige aussi le lancement en mode administrateur.

Le portage a-t-il été facile ?

Le portage n'a pas été facile (compatibilité de certains connect() difficile car la surcharge n'est pas autorisée), greffon différent…

Quelles sont les nouveautés utilisées ?

Le module Qt5 QtSystem pour QtSystemInformation a été utilisé. Cela permet de garder une liste des points de montage en cache et de l'actualiser en cas de changement. Cela permet aussi d'avoir cette partie en multi-platforme. Le reste est en Qt essential, comme QRegularExpression

Quels sont les problèmes rencontrés avec Qt5 ?

Qt5 est très jeune. J'ai dû coder énormément de contournements pour Qt 5.0.0. Certains problèmes n'ont pas de solution : problème de chargement des greffons perso sous Windows en 32 bits, menu quand on fait un clic droit sur systray icon qui ne fonctionne pas sous mac, énormément de contournements pour mingw32 (désactivation de -O2 par exemple).

Pourquoi ne pas avoir utilisé QML/QtComponents ?

Car je ne connais que les widgets, et qu'il manque certains widgets dans QML/QtComponents.

Pourquoi ne pas garder le code compatible Qt4 ?

Car cela ferait beaucoup de complications et duplications de code.

Autre point de Qt5 ?

Qt5 alourdit fortement le poids/nombre des DLL qu'il faut. Je me retrouve avec mon application de 1 Mo, 20 Mo de DLL de Qt. Il faut aussi mettre le greffon/plateforme/qwindows.dll sous windows, c'est la première fois que j'ai dû livrer un greffon Qt avec mon application (pas compressible avec upx, sinon plantage).

La branche 0.4.0.X est réservée à la stabilisation. Les nouveautés sont en préparation.

Le développement de certains greffons a été financé par les achats, ils ont donc été placés en gratuit (ils étaient déjà sous GPL3 avec source accessible, comme tout ce qui est vendu). D'autres greffons sont à venir dans les prochains mois et viendront s'ajouter à cette liste de greffons gratuits.

Aller plus loin

  • # Compilation sur Linux??

    Posté par  . Évalué à 1.

    Le logiciel était très bon dans ces ancienne versions et j'imagine qu'il est toujours aussi bon. Malheureusement je n'arrive pas a l'essayer car aucune version precompiler, aucun tutoriel de compilation, aucun README fourni.

    Si quelqu'un peut m'aider a compiler installer les dépendances (QT5 et autres dépendance) ce logiciel sur Linux Mint 14 (Ubuntu 12.10)

    J'ai lu dans un vieux commentaire d'un autre article, que l'auteur a arrêter d’offrir des version precompiler, car c’était trop compliquer. Malgré tout je continue a penser que ça simplifierais beaucoup l'installation et donc inciterais plus de gens a l'utiliser et amènerais plus de dons!! Je prioriserais peut-être Debian/Ubuntu/Linux Mint (Qui sont a ce jour parmi les distributions grand public les plus utiliser.)

    Merci beaucoup pour votre aide

  • # Qt5

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

    Le portage n'a pas été facile (compatibilité de certains connect() difficile car la surcharge n'est pas autorisée),

    Euh… L'ancien connect est toujours là et n'est même pas déprécié. Le nouveau connect() est un ajout qui a ces avantages, mais l'ancienne méthode existe toujours et il n'est pas du tout nécessaire de changer tout ton code. Si tu as choisis de le faire c'est bien, mais c'est pas honnête de dire que ça rends le port vers Qt5 difficile.

    (Et la surcharge est autorisée, c'est juste que ça rend la syntaxe un peu (beaucoup) plus lourde)

    Je suis par ailleurs intéressé de connaître les autres difficultés rencontrées.

    • [^] # Re: Qt5

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

      Mais vu que mon code est Qt5, tirer partie de la vitesse des nouveaux connect() surtout pour accéléré les vitesses de démarrage (ça peu aller jusqu'as 50x plus rapidement), me semble très important.
      Et oui, comme tu l'as dit, surcharge beaucoup plus lourde. C'est presque impossible à faire pour ceux qui arrive dans Qt.

      Les difficultés ont pas été de réapprendre Qt5 (doc de qualité) -> c'est juste long, mais bien de faire face à tout les bugs, trouver un moyen de les contournés, correctement packager le tout.

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

      • [^] # Re: Qt5

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

        Tu as tant de connect() que ça pour que leurs remplacements accélèrent à ce point le démarrage de l'application ?

        • [^] # Re: Qt5

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 31 décembre 2012 à 18:41.

          250 au démarrage, 300+50*nombre de threads pour l'affichage d'une nouvelle fenêtre.

          Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

          • [^] # Re: Qt5

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

            Juste par curiosité, comment un programme qui affiche des copies de fichier peut avoir besoin de plus de 200 connexions o_O ?

            • [^] # Re: Qt5

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

              A cause de la partie thread surtout, mais il y as aussi la remonter des informations. Tout à été fait en programmation évènementiel, et le programme est assez complet (avec support des plugins, …). De mémoire 700 000 lignes de code, avec 800Ko juste de cpp/h. Après si ont change la traduction tout est automatiquement re-traduit, … bref, ça vas vite. Pour plus de détails, voir le code.

              Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

              • [^] # Re: Qt5

                Posté par  . Évalué à 3.

                700 000 lignes de code

                Tu veux dire que tu as codé (presque) tout seul un truc qui fait 5% du noyau Linux avec tous les pilotes ?
                Je n'ai pas regardé ton code, je ne suis pas bon à cela, mais cette métrique très imparfaite me fait penser que ton programme a un sérieux problème de conception.
                Ou que tu n'es trompé dans tes chiffres.

                • [^] # Re: Qt5

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

                  J'ai sortie ça d'une commande du net, donc c'est peu être faux. Avec cat *.cpp *.h | wc -l:
                  10K pour l'application principale
                  10K pour le moteur de copie principal (+10K pour l'autre)
                  2K pour les plugins listener
                  2K pour plugins annexe
                  8K pour les thémes
                  5K code annex
                  3K code pour le packaging

                  Total: 50K de ligne de code. Ce qui me semble + réaliste.

                  Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

                  • [^] # Re: Qt5

                    Posté par  . Évalué à 3.

                    Ou 31 644 lignes de code réelle.

                    http://www.dwheeler.com/sloccount/

                    Computing results.

                    SLOC Directory SLOC-by-Language (Sorted)
                    12310 plugins cpp=12310
                    7765 top_dir cpp=7765
                    7643 plugins-alternative cpp=7643
                    2158 lib ansic=1860,cpp=298
                    1502 tools cpp=1502
                    266 interface cpp=266
                    0 patch (none)
                    0 resources (none)

                    Totals grouped by language (dominant language first):
                    cpp: 29784 (94.12%)
                    ansic: 1860 (5.88%)

                    Total Physical Source Lines of Code (SLOC) = 31,644
                    Development Effort Estimate, Person-Years (Person-Months) = 7.52 (90.26)
                    (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
                    Schedule Estimate, Years (Months) = 1.15 (13.84)
                    (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
                    Estimated Average Number of Developers (Effort/Schedule) = 6.52
                    Total Estimated Cost to Develop = $ 1,016,126
                    (average salary = $56,286/year, overhead = 2.40).
                    SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
                    SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
                    SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
                    redistribute it under certain conditions as specified by the GNU GPL license;
                    see the documentation for details.
                    Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

                    http://cloc.sourceforge.net v 1.56 T=1.0 s (232.0 files/s, 41165.0 lines/s)

                    Language files blank comment code

                    C++ 80 1960 1624 24409
                    C/C++ Header 106 825 2594 5698
                    C 4 441 635 1537
                    XML 30 0 344 583

                    IDL 12 31 0 484

                    SUM: 232 3257 5197 32711

                  • [^] # Re: Qt5

                    Posté par  . Évalué à 3.

                    50K de ligne de code. Ce qui me semble + réaliste

                    Cela semble effectivement beaucoup plus raisonnable :-)
                    C'est tout de même une sacrée masse de boulot !

                    • [^] # Re: Qt5

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

                      5ans de taff, j'ai acquis énormément d’expérience dans la manipulation d'inode, de donnée, en fonction des FS et des OS, compensation des erreurs, garder l'intégrité même quand le FS corrompt les fichiers…
                      Un vrai copier, c'est pas juste un boucle while(read,write) comme le croi les gens…

                      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

            • [^] # Re: Qt5

              Posté par  (Mastodon) . Évalué à 3.

              besoin de plus de 200 connexions o_O ?

              Codé à Bugarach un soir de pleine lune.

              • [^] # Re: Qt5

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

                10 threads * 30 connect par thread, ce juste pour classes principal qui connecte les threads de copie au thread de coordination et au thread de manip de contenu de fichier. Et ceux rien que pour le moteur principal.

                Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

      • [^] # Re: Qt5

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

        J'ai du mal à croire au fait que ça améliore tant que ça la vitesse de ton appli en général.
        Mais le problème est que tu dis dans ta dépêche que le port à Qt5 était compliqué à cause de ça alors que c'était pas du tout nécessaire de changer tout les connect()

        • [^] # Re: Qt5

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

          Voir message + haut. Si à l'améliore, je passe d'un temps de lancement souvent supérieur à 500ms, à <100ms, et encore plus pour l'ouverture d'une fenêtre.
          Et sur une application du type serveur où l'objet du client est connecté pour chaque client, ça fait une grosse différence:
          http://pokecraft.first-world.info/wiki/Benchmark_for_conception

          Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Qt5

      Posté par  . Évalué à 3.

      (Et la surcharge est autorisée, c'est juste que ça rend la syntaxe un peu (beaucoup) plus lourde)

      Pour ceux que ça intéresse, on peut voir un exemple ici : http://qt-project.org/wiki/New_Signal_Slot_Syntax#45f5369b0d8445adbaf54cd74a36b823

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Bugs, etc

    Posté par  . Évalué à 2.

    Qt5 est très jeune. J'ai dû coder énormément de contournements pour Qt 5.0.0.

    Ce pourquoi KDE va attendre un peu avant de l'intégrer… On aura la 4.10 et probablement une 4.11.

    Certains problèmes n'ont pas de solution : problème de chargement des greffons perso sous Windows en 32 bits, menu quand on fait un clic droit sur systray icon qui ne fonctionne pas sous mac, énormément de contournements pour mingw32 (désactivation de -O2 par exemple).

    C'est moi où tous les problèmes sont sur Windows/Mac? Un peu comme Firefox Windows 64 bits qui bugue alors que ça fait des années que l'on tourne pépère en 64 bits sous GNU/Linux et autres Unix libres?

    Même chose pour LibreOffice, il semblerait qu'il y ai moins de bugs sous GNU/Linux. VLC supporte plus de formats sous GNU/Linux.

    Serait-ce du aux utilisateurs? À la plateforme? Je me pose fortement la question.

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Bugs, etc

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

      Je confirme, j'ai pas eu le moindre problème sous linux. Les problèmes ne sont que sous Windows/Mac.

      C'est moi l'utilisateur 1er d'ultracopier, donc non c'est pas l'utilisateur :).
      C'est due à mingw (bug du -O2 spécifique à gcc 4.7.2, corrigé en 4.7.3) sous windows (effort pour MSVC et peu pour mingw), et peu d'effort pour mac (testé et compilé sous 10.6).
      Mais dans des systèmes fermés, tu as du mal à faire évoluer, changer les appelles systèmes pour le 64Bits, … alors que sous linux, une modification, et toutes les libs sont modif pour continuer à fonctionner.

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Bugs, etc

      Posté par  . Évalué à 1.

      A mon humble avis ce sont les développeurs qui causent cette tendance.

      Il est plus agréable de travailler sous linux, et c'est douc sous linux que l'on teste et que l'on trouve les bugs.
      Lorsqu'un client nous a demandé une appli windows basé sur notre logiciel open-source, j'ai trouvé une quantité assez ahurissante de bugs spécifiques windows dans notre code.

      Tous les développeurs préféraient linux pour la simplicité de mise en place de l'environnement de compilation.

      Sous windows, installer mingw nécéssite de comprendre quelle est la différence entre mingw, mingw-w32, mingw-w64, …

      • [^] # Re: Bugs, etc

        Posté par  . Évalué à 1.

        logiciel open-source

        et

        Il est plus agréable de travailler sous linux

        C'est pas très RMS-friendly tout ça! :D

        Sous windows, installer mingw nécéssite de comprendre quelle est la différence entre mingw, mingw-w32, mingw-w64, …

        Même si c'est un peu hors-sujet, c'est quoi la différence?

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Bugs, etc

          Posté par  . Évalué à 1.

          Même si c'est un peu hors-sujet, c'est quoi la différence?

          • mingw c'est le project original.
          • mingw-w64 c'est un 'fork' pour rajouter le support 64 bits
          • mingw-w32 c'est la version 32bits du compilo fourni par le project mingw-w64

          Chaque projet a sa propre version des libs/headers pour windows, avec comme ancetre commun une vieille version de mingw, les deux ayant diverge grandement depuis. Suivant le projet, ca utilise des versions plus ou moins recentes de GCC (entre le vieux GCC antediluvient bugge jusqu'a la moelle et le 'ca compile hello world chez moi, SHIP IT!'). Mingw a 2 versions de retard pour le support de l'OS, mingw-w64 un peu moins (se trimballer des headers de compat pour mingw dans tes sources juste pour utiliser les fonctionnalites d'un OS qui date de 5 ans, c'est toujours tres agreable) et sont bien entendu d'une effroyable lenteur par rapport aux compilos natifs (c'est une feature(TM) depuis 10 ans…).

      • [^] # Re: Bugs, etc

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

        C'est le même chose sous linux. Sauf que sous linux c'est packager, et c'est le packager qui font le taff.

        Entre mingw 32Bits et mingw64 c'est la même diff qu'entre gcc 32Bits et 64Bits sous linux. La marche entre OS est plus grande.

        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # Dons ?

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

    Sans être indiscret, tu arrives à générer un peu de revenu avec les dons / achats ?

    • [^] # Re: Dons ?

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 31 décembre 2012 à 18:53.

      Oui, mais juste assez pour rentrer dans les frais. J'aimerai gagner ma vie avec mes logiciels (Ultracopier est devenu un logiciel pro qui as quitter l'amateurisme). Mais pour l'instant Ultracopier c'est que 1% des recherches mondiale dans google, après Supercopier (20%) et Teracopy (76%, très rechercher au niveau mondiale).

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # Captain Bloatvious

    Posté par  (Mastodon) . Évalué à 4.

    Je me retrouve avec mon application de 1 Mo, 20 Mo de DLL de Qt.

    Et dire que dans l'ancien temps, les OS au complet étaient plus petit que ça…
    Sans déconner, il faut 21 Mo de binaire pour copier un fichier ?

Suivre le flux des commentaires

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