Technologie Sortie d'UltraCopier 0.2 et Catchcopy

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
16
14
nov.
2009
Technologie
UltraCopier est un logiciel multi-plateforme permettant de faire des copies/déplacements de fichiers avec un certain nombre de particularités : pause/reprise, limitation de vitesse, gestion de la liste de copie, etc.

La version 0.2 apporte l'option « write with thread » qui accélère les transferts de fichiers, supporte Windows Seven et Mac OS X, supporte les KIO dans la version KDE pour le multiprotocole, ajoute une version 64 bits pour Windows, permet la recherche dans la liste de copie, et regroupe les fenêtres de copie.

Chaque avis des utilisateurs a été soigneusement étudié pour que UltraCopier corresponde au besoin de chacun et pour créer une communauté active autour de ce logiciel. Par exemple une version portable optimisée pour les clefs USB a vu le jour avec les critères qui ont été demandés par cette catégorie d'utilisateurs. Le site a aussi été refait pour mieux coller à la thématique générale (UltraCopier, forum), et pour fournir un certain nombre de fonctionnalités (ex: RSS).

NdM : UltraCopier est écrit en C++ avec la bibliothèque Qt4 (il est adapté à KDE, mais celui-ci n'est pas obligatoire, la version Qt permettant de se passer des bibliothèques KDE), et distribué sous licence GNU GPLv3+. Il est disponible pour Windows (2000, XP, Vista et Seven, en 32 ou 64 bits), Linux (paquets Debian/Ubuntu, Gentoo) et Mac OS X. Voir également les projets MiniCopier (écrit en Java, licence GNU GPL) et SuperCopier (Windows uniquement, écrit avec Delphi, licence GNU GPLv2+). L'interception de la copie sous Windows est maintenant correcte grâce au projet Catchcopy, initié par le même auteur. Ce projet a pour but d'écrire un protocole standard entre tous les copieurs et explorateurs existants. Il est développé par un freelance financé exclusivement par les dons. Il est possible d'utiliser la version 64 bits de Catchcopy sur une application 32 bits (ex: logiciels libres compilés avec gcc 3 sous Windows).

L'auteur d'UltraCopier cherche un bénévole/freelance pour faire la conversion en KDE, qui permettra l'intégration totale dans KDE. Une intégration Gnome et Mac est aussi très attendue par les utilisateurs, mais personne ne semble capable de développer un greffon pour ces environnements.

Tous les testeurs, bénévoles et donateurs sont les bienvenus.
  • # Excellent logiciel

    Posté par . Évalué à  8 .

    Je l'utilise sous Windows et j'en suis très satisfait.
    Fini les copies foireuses http://xkcd.com/612/
  • # UltraCommentaire

    Posté par (page perso) . Évalué à  7 .

    La copie de fichier est ce qui s'accommode le moins bien d'interfaces graphiques.

    C'est avec les problèmes de sélection de fichiers que j'ai trouvé ma motivation à l'apprentissage du shell.

    Pour une copie simple, point besoin d'autre chose que cp (j'avoue que j'utilise MidnightCommander, mais surtout pour examiner les fichiers avant copie/suppression/déplacement).

    Pour les cas plus compliqués, rsync est une commande à ne pas sous-estimer.
    Elle fait déja la majorité de ce que propose UltraCopier, et l'avantage, c'est qu'on n'a pas besoin de cliquer partout.

    ps: qu'appellez-vous "disponible en paquet Gentoo" ?
    (avec un sync portage juste avant)
    ~$ eix ultracopier
    No matches found.
    • [^] # Re: UltraCommentaire

      Posté par . Évalué à  3 .

      ps: qu'appellez-vous "disponible en paquet Gentoo" ?
      (avec un sync portage juste avant)
      ~$ eix ultracopier
      No matches found.

      Je suppose qu'il s'agit de rajouter un ebuild disponible sur le site à son overlay personnel pour le moment. :-)
      • [^] # Re: UltraCommentaire

        Posté par (page perso) . Évalué à  1 .

        Hélas l'article à été réécrit avant ça publication, par exemple ultracopier utilise au choix la lib Qt ou Qt+KDE, j'avais pas préciser volontairement dans l'article.
        Pour l'instant il faut ajouter l'ebuild à sont overlay, mais j'ai fait une demande d'intégration dans l'arbre portage principal, vous pouvez relancer la demande.

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

        • [^] # Re: UltraCommentaire

          Posté par (page perso) . Évalué à  9 .

          Hélas l'article à été réécrit avant ça publication
          Hélas l'article a été réécrit avant sa publication

          oui, il était blindé de fautes qui piquent les yeux (bon c'est notre boulot aussi) ; n'hésite pas à proposer des rectifications dans les commentaires, c'est fait pour cela (et continue de proposer des dépêches, ça permet une relecture et d'ajouter des précisions au besoin).
        • [^] # Re: UltraCommentaire

          Posté par (page perso) . Évalué à  8 .

          Hélas l'article à été réécrit avant ça publication

          Il était incompréhensible, incomplet et bourré de fautes. J'ai par exemple très largement complété la liste de nouveautés de la version 0.2.

          par exemple ultracopier utilise au choix la lib Qt ou Qt+KDE

          Comme je n'avais pas vu de fichier INSTALL, j'ai testé héroïquement la compilation avec cmake (qui a foiré à plusieurs endroits : cmake puis dans le code). Le système de compilation basé sur cmake exige KDE.

          À l'instant, je viens de découvrir le fichier docs/readme.txt et qu'il existe un 2e système de compilation (étonnant). UltraCopier ne respecte pas trop les "standards" du logiciel libre :
          - l'archive ne contient pas dossier "ultracopier-x.y" : tar -xf ultracopier-src.tar.bz2 crée plusieurs sous-dossiers dans le dossier courant. Je me suis fait avoir, oups ! "tar -tf ultracopier-src.tar.bz2|xargs rm -rf" pour supprimer la polution.
          - il n'y pas de fichier INSTALL, mais il y a des infos dans docs/readme.txt (découvert après-coup, trop tard)
          - le nom des fichiers est assez inhabituel, je proposerai : docs/readme.txt => README, docs/version.txt => ChangeLog, docs/gpl-3.0.txt => COPYING

          j'avais pas préciser volontairement dans l'article

          Le problème est que ce n'est pas clair du tout. Je pensais qu'UltraCopier dépendait de KDE, et j'ai préféré que la dépêche soit explicite.
          • [^] # Re: UltraCommentaire

            Posté par . Évalué à  10 .

            - l'archive ne contient pas dossier "ultracopier-x.y" : tar -xf ultracopier-src.tar.bz2 crée plusieurs sous-dossiers dans le dossier courant. Je me suis fait avoir, oups ! "tar -tf ultracopier-src.tar.bz2|xargs rm -rf" pour supprimer la polution.

            Attention à cette méthode du tar tf | xargs rm -rf (ou son homologue rm -rf `tar tf`) qui est très très dangereuse. Ca n'est pas toujours le cas, mais il arrive que les tar contiennent le dossier "./", s'il ont été créés avec un "tar zcf .". La commande provoque alors la suppression de tout le dossier courant. Dans le cas des tarball extraits à la racine, ça revient à taper "rm -rf /". Si on était dans son home, on supprime son home.
          • [^] # Re: UltraCommentaire

            Posté par (page perso) . Évalué à  3 .

            Merci pour tout ces conseilles, j'en prends note, je vais corrigé tous ça pour la prochaine version.
            Oui dsl pour minimisé les dépendances j'ai utilisé qmake pour la version Qt (pour que ce sois simple sous qt creator sous windows par exemple) et cmake pour la version KDE n'étant largement pas fini (un peu commencé).

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

          • [^] # Re: UltraCommentaire

            Posté par (page perso) . Évalué à  3 .

            Vive "atool" pour ne plus se soucier des tar bomb !
    • [^] # Re: UltraCommentaire

      Posté par . Évalué à  10 .

      A chaque news sur ce logiciel c'est le meme topo y a un (des) gars qui sortent la ligne de commande comme le messie, sans comprendre tout ce que fait le logiciel.
      Lance tes copies comme tu veux d'un dur a l'autre et inversement, et tu verras tout ton systeme ramer car il y aura des entrees sorties simultanees dans les deux sens, a moins de faire un script etc.
      Au lieu de deux clics et c'est bon, ultracopier organisera la queue comme un ftp et les fichier seront finies d'etre copie alors que ton systeme continuera a ramer avec tes 'simples' lignes de commandes.
      Ultracopier permet d'eviter ce genre de goulot d'etranglement sans avoir besoin de reflechir soit meme a l'ordre dans lequel lancer la copie de fichier.
  • # Rien à voir ?

    Posté par (page perso) . Évalué à  5 .

    Simplement pour dire que le site du projet est esthétiquement superbe par sa simplicité. Cependant la lisibilité est particulièrement réduite à cause de la police grise très claire sur fond blanc.
    Sinon, le projet est plutôt intéressant, bonne continuation.

    Olivier

    - Dans la vie, il faut toujours se fier aux apparences. Quand un homme a un bec de canard, des ailes de canard et des pattes de canards, c’est un canard. C’est vrai aussi pour les petits merdeux.

    • [^] # Re: Rien à voir ?

      Posté par (page perso) . Évalué à  -1 .

      Normalement il utilise les couleurs et la police utilisé dans les autres applications, me le reporter si c'est pas le cas.

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

      • [^] # Re: Rien à voir ?

        Posté par (page perso) . Évalué à  2 .

        Normalement il utilise les couleurs et la police utilisé dans les autres applications, me le reporter si c'est pas le cas.

        Qui ça, « il » ? Le site web ou l'application UltraCopier ? mcdoil74 parle du site web, et j'ai la même remarque : gris clair sur fond blanc, ce n'est pas lisible. J'utilise Konqueror sous KDE4 et Debian Sid. Je pense que c'est un soucis CSS.
        • [^] # Re: Rien à voir ?

          Posté par (page perso) . Évalué à  2 .

          J'avais pas compris, je corrige cette aprem...

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

  • # Fonctions

    Posté par . Évalué à  4 .

    J'adore le Fait en C++, pour que tous les développeurs puissent développer
    sur le site

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Fonctions

      Posté par (page perso) . Évalué à  5 .

      J'avais aussi tiqué. En même temps, MiniCopier est écrit en Java et SuperCopier en Delphi !
      • [^] # Re: Fonctions

        Posté par (page perso) . Évalué à  2 .

        C'été surtout dans cette optique que j'avais écrit ça

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

  • # NdM

    Posté par (page perso) . Évalué à  4 .

    Remplacer "avec la bibliothèque KDE4" par "avec la bibliothèque Qt4"

    Qt4 n'est pas KDE.
    • [^] # Re: NdM

      Posté par (page perso) . Évalué à  2 .

      +1 La version KDE n'est pas encore réalisé, pour l'instant seule la version Qt est publié.

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

    • [^] # Re: NdM

      Posté par . Évalué à  -9 .

      T'es modérateur ici toi, maintenant ?
  • # Compatible avec Debian

    Posté par . Évalué à  1 .

    Oui mais pas avec Debian Lenny.
    Il semble que le package est compilé avec libqt4-core (>= 4.5.0)
    Sous Debian Lenny, j'ai uniquement la version antérieur, dommage pour moi.
    J'ai pas envie de compiler c'est mon coté débianiste fainéant ;)
    Librement votre
    • [^] # Re: Compatible avec Debian

      Posté par . Évalué à  1 .

      Lenny est sortie depuis le 14 février et les versions des logiciels inclus sont figés (c'est le principe même de la branche stable) ; c'est donc normal de ne pas y trouver cette version de la libqt4-core d'une part et ultracopier d'autre part.

      THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

      • [^] # Re: Compatible avec Debian

        Posté par (page perso) . Évalué à  5 .

        Le packet semble parfaitement compatible avec Qt 4.4, j'ai donc refait correctement le packet debian, il sera à jour pour la version 0.2.0.5

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

      • [^] # Re: Compatible avec Debian

        Posté par . Évalué à  2 .

        Loin de moi, l'idée de lancer un troll. J'exposais juste un état de fait pour un utilisateur d'une debian à la maison que je suis.
        Je sais bien que debian lenny est sortie en début d'année et que la philosophie debian est d'avoir une branche stable avec des logiciels/librairies éprouvés longuement mais avec un léger coût : la relative obsolescence des paquets. C'est tous.

        Ce post a eu au moins l'avantage de d'avertir le mainteneur (que je salue pour sa réactivité) du paquet SuperCopier afin de lui indiquer que son paquet n'était pas compatible en l'état avec la debian stable c'est à dire lenny.

        Je vais pouvoir tester pour voir exactement ce que ca donne sous Linux (déjà testé sur un windaube...)
        • [^] # Re: Compatible avec Debian

          Posté par (page perso) . Évalué à  2 .

          Voila, ça devrai marcher nikel sur ta debian lenny ;)

          J'essaye d'être le plus réactif possible (plein de plasmoid sur le bureau pour m'avertir de tout post et bug signalé sur le site ultracopier) pour monté un vraie communauté. Et parce que si l'utilisateur/testeur attends trop longtemps il ce lasse.

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

  • # vérification par chechskum des copies réalisées ?

    Posté par . Évalué à  4 .

    il y a quelques temps j'avais fait un backup assez sauvage d'un ordi (ou plutot disque) bien malade chez une amie. un backup sauvage et assez informel, je sentais que ça pêterait bientot et je n'avais pas envie de la terroriser sur le thème "tu vas perdre toutes tes photos tout ça tout tout tout, peut-être demain", c'était pas le bon moment pour elle. du tout.

    bref j'ai foutu un disque dur dedans, j'ai lancé une copie et je lui ai dit de laisser tourner ça la nuit

    deux mois plus tard, tout explose, et une partition (FAT32 ou NTFS, chépu) ressemblait même à ça : http://imgur.com/g3eIe.png

    je passe sur divers détails (TestDisk a bien servi, et sur le moment j'avais même oublié que j'avais fait une sauvegarde...), je récupère tout entre ce qui restait et ma copie, sauf que...

    ...j'avais moult fichiers en deux exemplaires (la version originelle, enfin celle réssucitée, et mon backup), et sur beaucoup de plutot gros fichiers (grosses images, 10 à 20 Mo...) il y avait de ci de là quelques octets qui changeait en plein milieu, bien que la taille et autres métadonnées (dates...) étaient identiques. un examen des sommes de controle (md5sum) m'a permis de lister un certain nombre de fichiers différents au final. vraiment du genre 4-5 octets qui changeaient subitement en plein milieux de gros fichiers.

    certes le reste de l'ordi était bien malade alors je me doute que des problèmes matériels ont salopé ma première copie (un simple cp -ax et normalement je fais une verif des checksum à la fin (sans anomalie d'ailleurs, en général), mais là je n'avais pas pu)

    du coup euh là lui il pourrait ?
  • # Surtout utile pour Windows

    Posté par . Évalué à  3 .

    Sous Windows je peux comprendre l'intérêt de ce type d'outil; la ligne de commande est très pauvre. En revanche sur *nix (dont Mac OSX) la ligne de commande propose des outils très efficaces. Il suffit de lire le manuel de la commande rsync, par exemple, pour s'en convaincre (vitesse de copie réglable, vérification automatique par somme de contrôle md5, copie de machine à machine... ). Quand une interface graphique est nécessaire, je préfère qu'elle s'appuie sur les outils en ligne de commande. C'est plus dans la philosophie unix: on fait qu'une chose à la fois, mais on le fait bien.

    Même si UltraCopier peut s'utiliser en ligne de commande, il reste dépendant de bibliothèques graphiques, ce qui sur un serveur peut devenir rédhibitoire. S'il ne peut s'utiliser partout alors il faudra apprendre à utiliser un outre outil... Autant connaître le plus universel. Du coup, dans un environnement graphique, je préfère une approche comme celle de grsync (http://www.opbyte.it/grsyn). L'interface graphique est séparée de l'outil. Pas besoin de réinventer la roue une énième fois.
    • [^] # Re: Surtout utile pour Windows

      Posté par . Évalué à  4 .

      Je ne suis pas trop d'accord avec toi:
      l'utilisateur standard n'a pas toujours envie de s'ennuyer avec la ligne de commande ou de se taper un man de plusieurs pages sur la commande rsync, CTRL+C, CTRL+V va plus vite.
      Concernant la réutilisation de rsync dans une GUI, je préfère l'approche Ultracopier qui se veut multi-plateformes. rsync ne se trouve pas en standard sur Windows. L'utilisateur doit donc se taper en plus de l'install du GUI, l'install de rsync (avec cygwin ?!?).

      Je préfère l'approche Ultracopier, codé une fois utilisé de la même manière sur toutes les plate-formes.
      • [^] # Re: Surtout utile pour Windows

        Posté par (page perso) . Évalué à  3 .

        Perso je pense que tout les points de vu ce défende (j'utilise énormément rsync et autre outils sur des serveurs, et un peu moins sur des desktop).
        Mais je pense qu'il faut toujours 2 type de soft pour faire la même chose:
        - Cli pour les script, les geek, et ceux aimant le cli
        - Gui pour la mémé du coin, les débutants, et ceux aimant le gui
        Ultracopier n'est pas en reste coté fonctionnalité comparé à rsync et autre, limitation de vitesse (pour ne pas saturer réseau ou hdd), reprise d'un fichier la ou l'erreur est survenu, ... je pense avoir bien repris l'espris, fait peu de chose (juste la copie) mais bien fait.

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

      • [^] # Re: Surtout utile pour Windows

        Posté par . Évalué à  -4 .

        Nous sommes sur linuxfr. C'est quoi un utilisateur "standard" de GNU/Linux ? Un utilisateur qui veut faire comme sur Windows ? Ca signifie pour lui qu'il passe à coté de tout ce qui fait la différence et la puissance de son système GNU/Linux. M'est d'avis que cet utilisateur là profite plus à Microsoft/Apple qu'au monde du libre.

        cygwin est installé sur tous les WinXP de mon entreprise. Difficile d'imaginer le plaisir que ça procure de faire un ssh sur un XP et se retrouver sous bash . Puis de là pouvoir administrer quantité de chose... automatiquement. C'est, par exemple, de cette façon que je déploie des logiciels sous Windows.
        • [^] # Re: Surtout utile pour Windows

          Posté par (page perso) . Évalué à  2 .

          C'est un débat dans le quel je ne veux pas rentrer.
          Mais un utilisateur de linux ne doit pas non plus faire forcement l'inverse de windows. Certain on envie de gui, d'autre non, certain diront peut étre que le monde serai parfait qu'avec des ordinateur sous linux avec seulement la console pur et aucune interface graphique...

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

        • [^] # Re: Surtout utile pour Windows

          Posté par . Évalué à  5 .

          Je suis un utilisateur de la ligne de commande. Mais je pense qu'on ne devrait pas pousser les néophites à utiliser la ligne de commande et se taper des pages de man au risque de rebuter et de nourrir une idée recue (qui selon moi n'a plus lieur d'être depuis au moins 5 ans) comme quoi les utilisateurs de Linux sont des geeks.
          Je pense qu'il ne faut pas dénigrer Mme Michu, car c'est grâce à elle que Linux sur le Desktop progresse et que des grandes multinationales comme Dell propose des ordinateurs sous cet OS (assurant une compatibilité à 100% avec le système).

          Si on avait continuer à vouloir faire les autistes on serait toujours avec des ordinateurs dont la carte son ne marche qu'en recompilant sa kernelle, et en train de configurer son .fvwm2rc à la main.
          • [^] # Re: Surtout utile pour Windows

            Posté par . Évalué à  10 .

            Attention, je n'oppose pas IHM contre ligne de commande, ce serait complètement idiot. Je pense simplement qu'il est plus judicieux que l'IHM s'appuie sur un outil accessible en ligne de commande lorsque celui-ci existe. C'est totalement équivalent pour MMe Michu qui ne s'intéresse pas à ce qui se passe sous le clavier.
            En revanche ça laisse toute latitude à celui qui veut faire de l'informatique et outiller ses processus.
            UltraCopier pourrait parfaitement être un outil en ligne de commande accompagné d'un frontend graphique multi-plateforme comme il en existe déjà. De sorte on conserve le meilleur des deux mondes et tout le monde est content.

            Utilisateur d'Ubuntu j'utilise Synaptic régulièrement sur mon desktop. Pour autant je ne pourrais pas me passer de la commande apt-get & Co.
            Ce que j'aime avec ce principe c'est que je peux adapter le système à mes besoins. Alors que sous Windows c'est à moi de m'adapter au système et ses limitations. C'est peut-être purement conceptuelle, mais je crois pourtant que c'est une différence fondamentale entre la vision de l'ouvert (la réutilisation par tous) et du fermé (rendre captif).
            • [^] # Re: Surtout utile pour Windows

              Posté par . Évalué à  1 .

              je suis d'accord avec toi. Je ne sais pas comment se comporte ultracopier, mais les explorateurs de fichiers genre nautilus ou dolphin ne sont pas super à ce niveau :
              - dolphin ne sait pas lire les fichiers avec un autre encodage (genre iso8859), et bloque complètement dessus.
              - nautilus indique dans le nom du fichier, y compris la copie "encodage non valide"
              - un jour que je copiais un gros fichier avec dolphin, en fermant un autre programme cela a fait planter dolphin, le fichier ne s'est pas copié et le fichier source a disparu...

              Je préfère donc utiliser la ligne de commande pour copier de gros répertoires.

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Surtout utile pour Windows

          Posté par . Évalué à  3 .

          Il faut peut être distingué les types d'usages, toi tu déploies sur un grand
          parcs donc la ligne de commande te facilite la vie.

          L'utilisateur desktop lui souhaite utiliser un outil sur lequel il ne se
          prend pas la tête, si l'outil de alpha_one_x86 couvre 99% de ces besoins il
          sera satisfait. L'objectif du gui est principalement de simplifier la vie (néophyte ou non).

          Pour des usages ponctuelles un gui bien pensé est très util.
          • [^] # Re: Surtout utile pour Windows

            Posté par . Évalué à  2 .

            En effet il faut distinguer les types d'usage et bien les considérer.

            o Il y a l'utilisateur occasionnel d'un outil graphique
            o et "l'informaticien" qui veut automatiser un processus.

            J'essaie de faire comprendre que ces deux types d'usage ne sont pas incompatibles. Il suffit juste d'une bonne conception au départ; consistant ici à ne pas fortement coupler l'IHM et la fonction. Pourquoi ne pas écrire une bibliothèque (libUltraCopier) ? Elle pourrait ainsi être liée, au choix, à un outil en ligne de commande ou de type 100% IHM "pas prise de tête (!)". Mieux, elle pourrait même être utilisée dans des situations que l'auteur n'a pas imaginé... Quoi de plus valorisant de plus ?
            • [^] # Re: Surtout utile pour Windows

              Posté par (page perso) . Évalué à  1 .

              Pour plusieurs raisons:
              tout est fait en signal/slot qui oblige d'utilisé Qt
              car avoir un outils en ligne de commande dépendant de Qt (juste le coeur) est assez dommage
              Il faudrait tout refaire...
              Dans la prochaine version du protocole de communication seront implémenté tout ce qui permet le controle et les informations de la copie.

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

              • [^] # Re: Surtout utile pour Windows

                Posté par . Évalué à  -2 .

                tout est fait en signal/slot qui oblige d'utilisé Qt
                C'est le couplage fort dont je parlais == erreur de conception == mauvaise méthode de développement

                car avoir un outils en ligne de commande dépendant de Qt (juste le coeur) est assez dommage
                Je doit manquer de clarté. Ou alors il vous manque quelques fondamentaux en matière de développement. A l'évidence vous n'avez rien compris, une bibliothèque de fonction n'a naturellement pas de dépendance avec un toolkit graphique. Bien sur qu'il faut refaire le mur s'il dépend d'un bout de bois pour tenir debout! Regardez le concept MVC [http://fr.wikipedia.org/wiki/Mod%C3%A8le-Vue-Contr%C3%B4leur] par exemple.
                • [^] # Re: Surtout utile pour Windows

                  Posté par (page perso) . Évalué à  5 .

                  Bien, maintenant tu répètes 30 fois tout haut:
                  "QT n'est pas qu'un toolkit graphique mais aussi un framework C++ complet"

                  Rien n'empêche de faire correctement son application mais de quand même utiliser QT pour tout ce qui est gestion des évènements, librairies I/O, et toutes les joyeusetés qui prennent 2 ans à faire marcher sous windows quand on est un dev Unix.
                  • [^] # Re: Surtout utile pour Windows

                    Posté par . Évalué à  -2 .

                    "QT n'est pas qu'un toolkit graphique mais aussi un framework C++ complet"Bien, maintenant si tu pense que ton argument suffit tu n'auras aucune difficulté à me le démontrer. Tiens, trouves mois trois ou quartes exemples de programme en ligne de commande utilisant qt-core pour faire de la copie de fichier... et je serais convaincu. Pourquoi pas eclipse aussi, en pilotant la fonction Open/Rename/Save AS, on doit pouvoir faire un super copieur de fichier avec ce framework!

                    (...)utiliser QT pour tout ce qui est gestion des évènements, librairies I/O, et toutes les joyeusetés qui prennent 2 ans à faire marcher sous windows quand on est un dev Unix.Tu vois, on en revient au sujet du fil: "Surtout utile pour Windows".
            • [^] # Re: Surtout utile pour Windows

              Posté par (page perso) . Évalué à  1 .

              Et une lib ferai que chaque copie ce ferai dans chaque processus, hors pour grouper les copies pour un max d'efficacité il est plus judicieux d'utiliser un soft fessant cela et des application voulant copier, passant les ordres à faire à ce soft.

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

      • [^] # Re: Surtout utile pour Windows

        Posté par (page perso) . Évalué à  5 .

        Mauvaise réponse, Qt n'est pas en standard sous Windows... Donc si tu met Qt, tu peux mettre la librsync dans le paquetage que tu distribues.
        • [^] # Re: Surtout utile pour Windows

          Posté par . Évalué à  2 .

          Mauvaise foi detected.

          Il livre les libs Qt avec son paquet. Jusqu'à présent il n'était pas question de librsync, mais de rsync, qui nécessite un environnement cygwin complet pour fonctionner.
  • # Correction

    Posté par (page perso) . Évalué à  1 .

    Il faudrai corrigé sur l'article:
    supporte les KIO (dans la version KDE pour le mulitprotocole)

    UltraCopier est écrit en C++ avec la bibliothèque Qt et KDE, la version Qt est utilisé pour ce passer de toutes les libs KDE si besoin.

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

  • # Erreurs de compilation sous Debian Sid

    Posté par (page perso) . Évalué à  3 .

    Erreur cmake 2.6 :
    marge$ mkdir build
    marge$ cd build
    marge$ cmake -C ..
    loading initial cache file ..
    (...)
    CMake Error at /usr/share/cmake-2.6/Modules/FindKDE4.cmake:84 (MESSAGE):
    ERROR: cmake/modules/FindKDE4Internal.cmake not found in
    /home/haypo/.kde/share/apps;/usr/share/kde4/apps
    Call Stack (most recent call first):
    CMakeLists.txt:3 (find_package)


    CMake Warning (dev) in CMakeLists.txt:
    No cmake_minimum_required command is present. A line of code such as

    cmake_minimum_required(VERSION 2.6)

    should be added at the top of the file. The version specified may be lower
    if you wish to support older CMake versions for this project. For more
    information run "cmake --help-policy CMP0000".
    This warning is for project developers. Use -Wno-dev to suppress it.

    -- Configuring incomplete, errors occurred!

    Euh, tout ça pour me dire que les outils de développement KDE ne sont pas installés ! Après un "sudo apt-get install kdelibs5-dev" :
    (...)
    CMake Error at /usr/share/kde4/apps/cmake/modules/FindQt4.cmake:1258 (FILE):
    file Internal CMake error when trying to open file:
    /home/haypo/ultra/src/resources_X11.qrc for reading.
    Call Stack (most recent call first):
    src/CMakeLists.txt:33 (QT4_ADD_RESOURCES)

    Après avoir bidouillé un fichier ../src/resources_X11.qrc bidon (fichier RCC vide) :
    CMake Error in src/CMakeLists.txt:
    Cannot find source file "AddFolderThread.cpp". Tried extensions .c .C .c++
    .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

    Effectivement, le fichier en question n'existe pas. En remplaçant AddFolderThread.cpp par AddFolder.cpp dans src/CMakeLists.txt ça a l'air enfin ok ;-)

    --

    avec qmake :
    marge$ cd src
    marge$ qmake -project
    marge$ qmake
    marge$ make
    (...)
    In file included from CopyThread.h:26,
    from CopyThread.cpp:14:
    structDef.h:16:24: error: QLocalSocket: Aucun fichier ou dossier de ce type

    Il s'agit de Qt 4.5.3 sous Debian Sid.
    • [^] # Re: Erreurs de compilation sous Debian Sid

      Posté par (page perso) . Évalué à  2 .

      Seul le qmake est officiellement supporter, pour la compilation sous debian:
      http://ultracopier.first-world.info/forum/annonces/complier-(...)

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

      • [^] # Re: Erreurs de compilation sous Debian Sid

        Posté par (page perso) . Évalué à  5 .

        Si tu espères « créer une communauté active autour de ce logiciel », je te conseille de mettre un point d'honneur sur la documentation (expliquant l'installation). Je n'aurai jamais pensé à aller voir sur le forum pour savoir comment compiler UltraCopier.

        Pour info, après plusieurs corrections (listées dans mon précédent commentaire), j'ai réussi à compiler avec cmake, alors que la compilation avec qmake fait une erreur que je ne sais pas résoudre (structDef.h:16:24: error: QLocalSocket: Aucun fichier ou dossier de ce type). Si la compilation avec qmake est la méthode officielle, il va falloir corriger le bug.
        • [^] # Re: Erreurs de compilation sous Debian Sid

          Posté par (page perso) . Évalué à  1 .

          Les packets: build-essential qt4-dev qt4-qmake sont bien installé?
          La compilation avec qmake devrai marcher, mais pas celle avec cmake.

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

  • # Diverses remarques sur UltraCopier

    Posté par (page perso) . Évalué à  6 .

    Si le nom d'un fichier contient un caractère invalide (ex: nom de fichier ISO-8859-1 sur un système de fichier UTF-8), la copie échoue. Bug bloquant pour un logiciel de copie :-(

    Si la copie d'un fichier échoue, le dossier source n'est pas indiqué. Or là j'ai testé avec un dossier contenant 1325 sous-dossiers et je n'arrive pas à trouver le fichier en question (peut-être qu'il y a un bug dans l'affichage du nom du fichier).

    Les erreurs bloquent directement l'ensemble de la copie plutôt que de continuer à copier les autres fichiers. Du coup, si l'erreur apparait tôt lors de la copie et qu'on clique sur Annuler, seuls les premiers fichiers seront copiés. Il serait plus agréable pour l'utilisateur d'afficher l'erreur à la fin.

    S'il y a 50 erreurs, UltraCopier va poser 50 questions (ex: recopier un dossier qui était déjà copié : UltraCopier va poser la question pour _chaque_ fichier !). C'est vite énervant. Il serait plus sympa d'afficher un dialogue listant toutes les erreurs et permettant de les corriger toutes en même temps. C'est un défaut d'ergonomie typique des applications graphiques.

    Le débit de la copie semble être une mesure instantanée plutôt qu'une moyenne des dernières valeurs. Exemple de débit (en Mo/sec) sur une dizaine de secondes : 41, 32, 5, 40, 0, ... Du coup la valeur est difficile à lire (suivre) car change sans arrêt (la vitesse de rafraichissement semble inférieur à la seconde). Problème lié à ça : l'estimation du temps restant est très mal calculée. En 10 secondes il m'affiche : 1h51... 58min ... 1h51... 58min ... 33 min... 9 min ... 1h51 .. 0 sec.

    UltraCopier segfaulte parfois quand j'interrompt le "scan" (la 1ère étape d'une copie). Ca arrive quand je copie un dossier contenant beaucoup de sous-dossiers et beaucoup de fichiers. Peut-être un problème lié aux threads (objet QDir détruit par un thread et utilisé par un autre thread ?).
    • [^] # Re: Diverses remarques sur UltraCopier

      Posté par (page perso) . Évalué à  1 .

      Qt ne liste pas les fichiers de ce type, je me suis déjà plain mais rien n'as changer.

      On peu cliquer sur passé, ce qui passe juste le fichier courant, les utilisateurs souhaite ce fonctionnement, et faire le fonctionnement que tu à évoquer peu être très difficile.

      Non, l'utilisateur peu sélectionner: toujours faire cette action

      En instantané sur linux j'ai 0Mo/s 500Mo/s 300Mo/s 10Ko/s 1500Mo/s, ... le temps restant ne ce base pas sur la vitesse, et c'est possible qu'il y ai un bug.

      J'ai vu ce bug assez tardivement, il sera corrigé dans la version 0.2.0.5 qui arrive sous 2j

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

      • [^] # Re: Diverses remarques sur UltraCopier

        Posté par (page perso) . Évalué à  4 .

        Qt ne liste pas les fichiers de ce type

        De quoi tu parles ?

        On peu cliquer sur passé, ce qui passe juste le fichier courant, les utilisateurs souhaite ce fonctionnement, et faire le fonctionnement que tu à évoquer peu être très difficile.

        Oui on peut cliquer ignorer un fichier, mais ce n'était pas ce que je demandais. Peut-être que ce que je demande est compliqué à implémenter, mais ça serait un vrai plus pour ton logiciel (parce que pour l'instant, je n'en ai toujours pas trouvé d'utilité à ce logiciel et il semble pas mal bogué).

        En instantané sur linux j'ai 0Mo/s 500Mo/s 300Mo/s 10Ko/s 1500Mo/s,

        Ces valeurs me semblent tout simplement fausses (ou alors ton disque dur peut écrire à 1,5 Go/sec ?). Et puis, passer de 10 Ko/s à 1500 Mo/s en un instant ... Calcule une moyenne sur les 5 dernières secondes par exemple, ça sera plus sympa pour l'utilisateur.
        • [^] # Re: Diverses remarques sur UltraCopier

          Posté par (page perso) . Évalué à  1 .

          Qt ignore (dans les boites de dialogue et dans le listage des dossiers) tout les fichiers ayant des problèmes d'encodage, il fait comme si il n'existe pas.

          Pour l'instant je me concentre sur les corrections de bug, mais ce que tu as demander semble très compliquer à implémenter.

          Ces valeurs me paraisse bizard, mais c'est ce qui semble étre fait, je ne comprends pas pourquoi... à cause de l'ordonanceur deadline?

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

  • # Nautilus et KDE4

    Posté par (page perso) . Évalué à  5 .

    Cette semaine, j'ai copié 3 gros fichiers sur une clé USB, puis je me suis perdu dans mes fenêtres. Ensuite j'ai copié 10 autres gros fichiers vers la même clé USB. Gnome a alors rajouté ces nouveaux fichiers en queue de la copie précédente (oups ! la 1ère copie n'était pas encore terminée). C'est malin car lancer deux copies en même temps depuis le même média source et le même média destination a de fortes chance de ralentir les deux copies. Il vaut mieux les faire séquentiellement.

    Du côté de KDE4, les copies de fichier apparaissent dans la barre des tâches avec une barre de progression, peuvent être mis en pause et annulées. La durée restante estimée est affichée dans le titre. Si on affiche les détails, on peut voir :
    octets copiés / octets restants
    nombre de fichiers copiés / nombre de fichiers totaux
    nombre de dossiers copiés / nombre de dossiers totaux

    S'il y a plusieurs copies (ou plus généralement, plusiseurs tâches) en cours, la zone de notification affiche l'estimation du temps restant total.
  • # Réponse de Qt pour les mauvais encodage dans les nom de fichiers

    Posté par (page perso) . Évalué à  1 .

    Voila ce que me réponds Qt:
    http://bugreports.qt.nokia.com/browse/QTBUG-5832
    En gros, démerdez vous dans ce genre de cas.

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

    • [^] # Re: Réponse de Qt pour les mauvais encodage dans les nom de fichiers

      Posté par (page perso) . Évalué à  2 .

      Si QT détecte le mauvais encodage, tu devrais leur demander s'il est au moins possible de signaler le problème dans une boite de dialogue. Bref, prévenir l'utilisateur quoi.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Réponse de Qt pour les mauvais encodage dans les nom de fichiers

        Posté par (page perso) . Évalué à  1 .

        Il ne veulent strictement rien faire.
        Et si il importer le nom de ces fichier en brute ce ne serai pas affichage mais l'ouverture de fichier marcherai et le développeur d'un soft aurai au moins la main pour agir en conséquence (et corrigé l'encodage si il le veux)

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

    • [^] # Re: Réponse de Qt pour les mauvais encodage dans les nom de fichiers

      Posté par (page perso) . Évalué à  4 .

      Il n'y a pas de problème, Qt fonctionne très bien avec des noms de fichier mal encodés. Le bug est dans ton code, pas dans Qt (ni dans Linux :-)). Exemple en Python :
      from PyQt4.QtCore import QDir, QFile, QIODevice
      cwd = QDir('.')
      entries = cwd.entryInfoList()
      for entry in entries:
      .. name = entry.fileName()
      .. if unicode(name).startswith(u"."):
      .... continue
      .. file = QFile(name)
      .. file.open(QIODevice.ReadOnly)
      .. data = file.read(10)
      .. file.close()
      .. bytes_name = str(QFile.encodeName(name))
      .. print "%r: content=%r" % (bytes_name, data)

      Pour créer un fichier avec un nom invalide sous Linux : echo "pouet" > $(echo -ne "b\xff--").
  • # Sortie de la version 0.2.0.7

    Posté par (page perso) . Évalué à  1 .

    Bonjour, Sortie de la version 0.2.0.7
    Elle active par défaut les options "preallocate" et "write thread" et corrige tout les derniers bug connut. J'ai en plus veillé à faire des testes pour trouvé et corrigé les bug qui n'ont encore été vu par personne.
    Donc après de moult heures de réflexion notamment sur le dernier bug, cette version devrai être 100% fiable. Prochaine version j'ajoute le support d'ajout/suppression de plugin local et internet comme firefox et kde.

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

Suivre le flux des commentaires

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