Je passe outre l'histoire sur les versions des libs, il y a pas vraiment de solution
Ah bon? Et ils font comment osx/ios/windows (je met pas android, trop facile avec des jars).
QSettings quand les os viennent tous avec une keychain, c'est un peu ballot quand meme, surtout dans le contexte actuel.
Effectivement pour les qdesktop et qtraymachin (c'est a ca que je pensais avec les notifications).
Dans le cas de Qt, je te conseille (à tout hasard, peut être est-ce déjà le cas) de ne jamais distribuer de binaire compiler avec une version de Qt spécifique à ta distribution, mais utiliser les archives fournies par Digia qui sont plus génériques.
Et voila, ca commence. Fait pas ci, fait ca, parce que t'as aucune idee de ce qui va etre dispo sur la machine cible, dans quelle version, sous quel nom de package.
mais à version de Qt équivalente le résultat est le même, faut pas déconner.
Equivalente est le mot cle. Comme tout le monde integre une version differente, et que different desktop ont un niveau d'integration different, tu te retrouve a gerer des problemes a la con.
Alors après effectivement d'une version à l'autre ça change, mais dans ce cas, ce que tu reproche à Qt, c'est d'évoluer et d'avancer
Ios et osx evoluent beaucoup mais ne petent JAMAIS la compat binaire. Apple met un effort monstrueux a maintenir la compat d'appli en fonction du framework auquels elles ont ete linkees, et ca monte en version facile.
Quand tu rebuildes, au pire t'as tres tres peu de modif a faire, et qq warnings de deprecation qui apparaissent.
Windows est connu pour garder 100% de compat sur des decennies
On peut visiblement pas en dire autant du passage gtk 2->3 ou de qt 3->4, meme la migration 4->5 pete des trucs si j'en croit leur docs.
Donc insulter un logiciel qui demande tant de travail
Ola! Stop ton char. J'insulte nullement qt/gtk. Je reponds a un commentaire qui disait que l'interet de swift, c'etait les frameworks gui, et insinuait que ca ne servait a rien sur linux.
Mon point c'est que le language n'importe pas tant que ca, que swift sera ravi de lier du c (et dans le futur du c++), et wu'il faut peut etre chercher ailleurs, notamment le fait que developer pour le desktop linux est un enfer qui n'a strictement rien a voir avec le langage.
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par groumly . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 2.
Ah bon? Et ils font comment osx/ios/windows (je met pas android, trop facile avec des jars).
QSettings quand les os viennent tous avec une keychain, c'est un peu ballot quand meme, surtout dans le contexte actuel.
Effectivement pour les qdesktop et qtraymachin (c'est a ca que je pensais avec les notifications).
Et voila, ca commence. Fait pas ci, fait ca, parce que t'as aucune idee de ce qui va etre dispo sur la machine cible, dans quelle version, sous quel nom de package.
Equivalente est le mot cle. Comme tout le monde integre une version differente, et que different desktop ont un niveau d'integration different, tu te retrouve a gerer des problemes a la con.
Ios et osx evoluent beaucoup mais ne petent JAMAIS la compat binaire. Apple met un effort monstrueux a maintenir la compat d'appli en fonction du framework auquels elles ont ete linkees, et ca monte en version facile.
Quand tu rebuildes, au pire t'as tres tres peu de modif a faire, et qq warnings de deprecation qui apparaissent.
Windows est connu pour garder 100% de compat sur des decennies
On peut visiblement pas en dire autant du passage gtk 2->3 ou de qt 3->4, meme la migration 4->5 pete des trucs si j'en croit leur docs.
Ola! Stop ton char. J'insulte nullement qt/gtk. Je reponds a un commentaire qui disait que l'interet de swift, c'etait les frameworks gui, et insinuait que ca ne servait a rien sur linux.
Mon point c'est que le language n'importe pas tant que ca, que swift sera ravi de lier du c (et dans le futur du c++), et wu'il faut peut etre chercher ailleurs, notamment le fait que developer pour le desktop linux est un enfer qui n'a strictement rien a voir avec le langage.