Sortie de Qt 5.11 Beta 2
La version finale devrait toujours arriver fin mai
Le 2018-03-17 19:41:56, par dourouc05, Responsable Qt & Livres
La préversion Beta 2 est maintenant disponible. Elle corrige une série de défauts depuis la précédente. Dix-sept problèmes majeurs doivent encore être corrigés avant la version finale. A priori, rien ne s'oppose à une publication fin mai !
Source : [Development] Qt 5.11 beta2 released.
Source : [Development] Qt 5.11 beta2 released.
-
Gojir4Membre avertiL'API QtWinMigrate, faisant partie de Qt-Solutions, est normalement prévu pour une migration de MFC à Qt. Il permet de mixer des fenêtre MFC avec des widgets. Visiblement (commentaire GitHub) c'est compatible au moins jusqu'à Qt5.8.le 22/05/2018 à 16:16
-
dourouc05Responsable Qt & LivresEffectivement, merci !le 20/06/2018 à 12:23
-
koala01Expert éminent séniorSalut,
A vrai dire, l'élément réellement déterminant pour évaluer le temps qu'il te faudra pour faire la migration est: à quel point le framework (quel qu'il soit) impregne-t-il tes données et ta logique métier
Je vais essayer d'exprimer les choses différemment:
Mettons que j'extraie de ton projet de plusieurs millions de lignes, que les fichiers qui définissent tes données métier et la logique qui y est associée, pour les placer dans un tout nouveau projet qui n'utilise pas MFC (du C++ "standard", voire, au pire, du C++/cli), et que j'essaye de compiler ce projet. Combien d'unités de compilation compileront sans problèmePour combien d'unités de compilation dois-je m'attendre à une erreur de compilation suite à l'absence de MFC
Si ton projet a été développé en suivant les "standards de l'époque", sans avoir été refactorisé au fil du temps, j'aurais tendance à penser qu'il n'y a pas une seule unité de compilation qui pourra compiler correctement, et donc que l'imprégnation de MFC est "maximale".
A l'inverse, si ton projet a été refactorisé au fil du temps, pour justement éviter cette imprégnation, il se peut tout à fait que 90 ou 95% (voir plus encore) des unités de compilation compilent correctement.
Dans le premier cas, la migration "d'une traite" de MFC ->Qt (ou vers n'importe quel autre framework, d'ailleurs) sera sans doute particulièrement douloureuse
Une étape intermédiaire qui consisterait à réduire le niveau d'imprégnation des MFC dans les données métiers serait sûrement la bienvenue mais risque de demander à elle seule un effort considérable.
L'alternative étant de décider de partir sur un projet complètement vierge en ne reprenant que l'analyse fonctionnelle... si tant est qu'elle existe bien sur
Dans le second cas, elle sera sans doute beaucoup plus "facile", car il "suffirait" de refaire... la partie Vue et la partie Controler/Delegate de l'application.
Et, bien sur, il y a toutes les possibilités comprises dans l'intervalle
PS: tu remarqueras les guillemets pour cette dernière phrase, car cela peut malgré tout représenter un boulot monstrele 12/04/2018 à 17:09 -
archqtMembre émériteLa LGPL impose simplement que le fournisseur du logiciel offre la possibilité à l'utilisateur de changer de version de Qt. Si vous proposer votre fichier objet une documentation pour expliquer la façon de faire le lien, vous avez le droit de distribuer votre programme.
Bonne fin de journée
J'aurais pas dit mieux ;-)
J'ai utilisé wxWidgets pendant longtemps, et honnêtement cela va quand même plus vite avec Qt. Néanmoins il faudrait voir jusqu'à quel niveau MFC est imbriqué dans le code C++. Et wxWidgets n'est pas compatible MFC il me semble, il reprend un certains nombre d'idées, notamment sur les tables d'événement mais pour le reste je ne suis pas compétent dessus.le 13/04/2018 à 15:31 -
Matthieu76Membre éclairéle 20/06/2018 à 10:43