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
- Site officiel d'ultracopier (1780 clics)
- Site officiel de supercopier (312 clics)
- Comparatif d'ultracopier avec les autres copiers (452 clics)
- Plugins d'ultracopier (142 clics)
- DLFP : SuperCopier 2.3 (73 clics)
- DLFP : UltraCopier 0.3 (64 clics)
# Compilation sur Linux??
Posté par rk5000 . É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
[^] # Re: Compilation sur Linux??
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Répondu sur le forum. Version précompilé:
http://files.first-world.info/ultracopier/0.4.0.0/ultracopier-linux-x86_64-pc-0.4.0.0.tar.xz
Tuto pour la compilation en anglais dans le wiki:
http://ultracopier-wiki.first-world.info/wiki/Compilation_of_Ultracopier
Ultracopier 0.3 et 0.4 sont bien supérieure au 0.2 (souvent livré dans les distros).
Par contre les packets .deb/.rpm ne sont plus fait voir FAQ (perte de temps, incompatilibté, les distrib préfère faire leur propre packet depuis les sources…), juste une version précompilé générique. Et quand il y avais ces packets, je n'avais strictement aucun dons. Et je préfère que KDE/Gnome autorise l'interception de la copie, cela amènera plus d'utilisateur (et je pourrai enfin l'utilisé en tout transparence sous linux), et sera plus utile que de simple dons.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Qt5
Posté par Gof (site web personnel) . Évalué à 6.
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 alpha_one_x86 (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 Guillaume Denry (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 alpha_one_x86 (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 Guillaume Denry (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 alpha_one_x86 (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 Kerro . Évalué à 3.
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 alpha_one_x86 (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 Kangs . É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 Kerro . Évalué à 3.
Cela semble effectivement beaucoup plus raisonnable :-)
C'est tout de même une sacrée masse de boulot !
[^] # Re: Qt5
Posté par alpha_one_x86 (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 Tonton Th (Mastodon) . Évalué à 3.
Codé à Bugarach un soir de pleine lune.
[^] # Re: Qt5
Posté par alpha_one_x86 (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 Tonton Th (Mastodon) . Évalué à 2.
[^] # Re: Qt5
Posté par Gof (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 alpha_one_x86 (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 claudex . Évalué à 3.
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 ariasuni . Évalué à 2.
Ce pourquoi KDE va attendre un peu avant de l'intégrer… On aura la 4.10 et probablement une 4.11.
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 alpha_one_x86 (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 packadal . É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 ariasuni . Évalué à 1.
et
C'est pas très RMS-friendly tout ça! :D
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 Littleboy . Évalué à 1.
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 alpha_one_x86 (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 Philippe F (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 alpha_one_x86 (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 Tonton Th (Mastodon) . Évalué à 4.
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 ?
[^] # Re: Captain Bloatvious
Posté par Gui13 (site web personnel) . Évalué à 4.
Ou alors tu compiles en statique, mais ouais, QtGui est énorme.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.