Dirk Hohndel est "Chief Linux and Open Source Technologist" chez Intel… mais il est surtout le pote de plongée régulier de Linus Torvalds. C'est à ce titre qu'il a travaillé sur le logiciel Subsurface, créé par Linus et qui vise à enregistrer toutes les données d'une série de plongées sous-marines et à visualiser ces données dans une interface plaisante.
Alors que Subsurface utilisait depuis le début le toolkit Gtk, une transition vers Qt a eu lieu en 2013. Mais le plus intéressant est l'excellente conférence qu'il a tenu lors du Linux.conf.au 2014. Cette conférence porte sur les raisons de ce choix et sur les diverses leçons qui ont été tirées lors de la transition.
NdM : merci à patrick_g pour son journal.
Je recommande chaudement le visionnage de cette conf qui est bien menée et très informative. C'est parfois aussi fort drôle (cf. Linus critiquant l’inefficacité de certains algorithmes et harcelant Dirk pour gratter encore 200 cycles processeur).
Les aficionados de GTK et GNOME doivent toutefois prévoir un gilet pare-balles car ça dénonce grave ! Entre l'attitude détestable des devs Gtk/GNOME, l'absence de documentation, le support pourri des autres plates-formes que Linux et les diverses limitations techniques… à écouter Dirk on se demande qui peut encore opter pour ce toolkit.
Aller plus loin
- Journal à l'origine de la dépêche (775 clics)
- La vidéo de la conférence (Format MP4 - 125 Mo - 46'05") (1219 clics)
- LinuxFr.org : Wireshark passe à Qt (378 clics)
- LXDE, Razor-qt et Qt (et GTK+) (378 clics)
- L'annonce du projet de changement de toolkit sur G+ (304 clics)
# Bindings
Posté par paul . Évalué à 10.
C'est bien de comparer les librairies, c'est très instructif. Cela dit, ça aurait été plus accessible de le résumer sur une page web, plutôt que de passer des heures à troller avec son public comme le fait Dirk dans cette vidéo.
Moi j'aime bien Qt, c'est clean et ça fait du bon boulot. Mais dans la plupart des cas, les interfaces graphiques sont destinées à des applications de bureau. Je ne sais pas pour vous, mais moi ça fait belle lurette que je ne code plus ce genre d'applications avec C ou C++. L'informatique a évolué en quelques décennies.
Du coup se pose la question de la disponibilité des bindings requis pour faire fonctionner le toolkit graphique avec son langage. Et là, hélas, on a rarement le choix. Dans les langages que j'ai utilisés dernièrement, les bindings Gtk étaient fonctionnels et à jour, et les bindings Qt obsolètes ou absents.
Si Dirk, Linus, et leur pote de plongée mainteneur de Qt pouvaient par exemple, entre deux paliers de décompression, coder et maintenir des bindings Qt pour Haskell, on leur en saurait gré.
Merci à eux :)
[^] # Re: Bindings
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 13 janvier 2014 à 18:09.
Quel vieux con je suis, pendant que les gens s'amusent à changer de langage tous les x ans (la mode était Java, maintenant Python, et demain?) je reste sur C++ et je peux garder mon code à travers les ages de l'informatique (avec des binding Java et Python et futurs :) ).
Chacun son délire, ça dépend si on vise le court (ce n'est pas négatif, des fois des projets ont une durée de vie courte et il vaut mieux fourir rapidement que performant) ou long terme (et le perfs et/ou conso)
[^] # Re: Bindings
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 10.
Python à la mode ? Mais c'est déjà has been depuis longtemps : JavaScript, Ruby, Dart ou Rust sont des langages bien plus à la mode !
[^] # Re: Bindings
Posté par Zenitram (site web personnel) . Évalué à 10.
Ben oui, voila, ça change tellement souvent quelque soit le language tu choisis, tu es "has been" pour les autres :).
Alors, quand on critique les gens faisant du C++, ça fait sourire!
[^] # Re: Bindings
Posté par arnaudus . Évalué à 10.
Je ne pense pas que C++ soit "has-been" pour tout, mais c'est vrai qu'on peut se demander la pertinence d'un langage aussi contraignant si c'est pour faire une interface graphique autour de la lecture de données dans un fichier et une analyse triviale.
Le meilleur langage, c'est quand même celui que tu connais bien ET qui est adapté au type d'application. Dans le cas présent, à moins de vouloir faire des statistiques Bayesiennes infernales sur les temps des paliers de décompression, ou vouloir que le soft puisse aussi faire firewall et piloter une cafetière…
[^] # Re: Bindings
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 14 janvier 2014 à 10:20.
C’est vrai que le C++, c’est difficile, et qu’on devient rapidement moins efficace dès que l’on cesse d’en faire réguliérement.
Mais un des intérêts de Qt, c’est justement de simplifier le codage en C++ : même si on n’est pas un super-programmeur au top, la plupart des programmes C++ / Qt restent accessibles.
[^] # Re: Bindings
Posté par arnaudus . Évalué à 10.
L'autre vision, c'est de dire que Qt a carrément modifié en force le C++ de manière à faire rentrer des objets ronds dans des trous carrés, et que le résultat n'est pas vraiment du C++ :-)
Le C++ c'est vraiment bien pour faire ce que c'est censé faire : de l'objet sur des algorithmes ayant besoin de performances. Je m'en sers pour des programmes scientifiques, des simulations intensives et des trucs comme ça, et c'est un outil super pratique. Mais j'ai quand même l'impression d'être un bricoleur avec des outils pros dans les mains, sans avoir lu le mode d'emploi. Pour faire du C++ efficace et propre, il faut faire de l'objet nickel (designs patterns etc), il faut être très soigneux sur l'écriture des classes (bien overloader les opérateurs, être super strict sur les const, être super strict sur la gestion de la mémoire), il fau(-drait, parce que je ne le fais pas) gérer les exceptions comme il faut… Ça fait beaucoup de contraintes. Quand on voit le nombre de gens qui prétendent faire du C++ et qui ne produisent qu'un vague dialecte du C, je me dis que ça serait peut-être pas mal que moins de gens fassent du C++, parce que c'est un outil très puissant, mais très technique, et qui se prête très mal à des petits projets pas bien ficelés.
[^] # Re: Bindings
Posté par Philippe F (site web personnel) . Évalué à 4.
C'est un peu exagéré quand même. Je dirai ça plutôt de GObject. Pour Qt, c'est juste des objets ronds dans des trous ovals, c'est beaucoup plus raisonnable…
[^] # Re: Bindings
Posté par barmic . Évalué à 2.
Techniquement l'un se compile avec un compilateur C quelconque alors que l'autre ne se compile pas avec un compilateur C++… :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bindings
Posté par dave_null (site web personnel) . Évalué à 4.
Il y en a un où c'est le développeur qui doit faire le pré-processeur à coup de copier/coller de code sans intérêt.
[^] # Re: Bindings
Posté par Gof (site web personnel) . Évalué à 5.
N'importe quoi.
Du code Qt se compile avec un compilateur C++ quelconque.
Maintenant il est vrai que il y a les fichiers générés par le moc. Mais dans ton code en gtk, il y a aussi le fichier config.h généré par le configure, il a besoin de macro données par le système de build. Certains projet on même des dépendance à python pour générer du code.
Même subsurface avant qu'il soit porté vers Qt utilisait un générateur de code pour inclure les images dans le binaire: https://github.com/torvalds/subsurface/blob/Gtk/Makefile#L325
[^] # Re: Bindings
Posté par stopspam . Évalué à -3.
C# vaincra !
[^] # Re: Bindings
Posté par Zenitram (site web personnel) . Évalué à 5.
Je l'avais oublié celui la comme langage à la mode entre Java et Python (ou ailleurs dans la chronologie, je ne sais plus, les modes changent tellement souvent).
Même que Microsoft avait tenté le "meilleur des deux mondes" Java + C# = J#! :)
[^] # Re: Bindings
Posté par bunam . Évalué à 1.
M# !! ok je sors ;)
[^] # Re: Bindings
Posté par FantastIX . Évalué à 2.
Nan. Ten# .
Bon, ben, du coup -->[] aussi.
[^] # Re: Bindings
Posté par El Titi . Évalué à 10.
A force de C#er sur les langages, ça finira sur un coup de forth.
[^] # Re: Bindings
Posté par ariasuni . Évalué à 8.
Ça m'Eiffel pas Perl.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Bindings
Posté par Loïc Ibanez . Évalué à -2.
Chut… même de voir le mot m'irrite :-D
[^] # Re: Bindings
Posté par paul . Évalué à 4.
Salut Zenitram,
si tu connais bien le C++, que tu as fait des tas d'applications, que tu as tes librairies aux petits oignons, que tu as déjà rencontré toutes les situations compliquées … bref, si tu es super expérimenté, je comprends parfaitement que tu utilises ce langage même pour des applis utilisateur.
Moi qui n'ai pas cette compétence, et qui ai du mal à garder une vision claire de la sémantique de mon programme quand le code est rempli de boucles, de gestion de la mémoire, d'effets de bord variés … bref, moi qui manque clairement d'expérience en langages bas niveaux, je suis totalement improductif en C++.
Je fais la grande majorité de mes programmes en Haskell depuis 4 ans, et je n'ai pas prévu de changer avant longtemps. On peut être moderne et fidèle ;)
Un jour probablement, dans 15 ans de ça, je connaîtrai ce langage sur le bout des doigts, et malgré l'existence de nouveaux langages plus adaptés à mes besoins, je continuerai à démarrer des nouveaux projets en Haskell, par habitude. Mais ce n'est pas pour ça que ce sera un bon choix pour la nouvelle génération :)
[^] # Re: Bindings
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Des loops ? l'en-tête algorithm est ton ami.
De la gestion mémoire ? Les RAII sont tes amis.
Des effets de bord ? Les variables globales sont interdites sous peine de mort.
[^] # Re: Bindings
Posté par rewind (Mastodon) . Évalué à 4.
Oui, et avec l'ajout de
make_uniqueen C++14, on pourra désormais se passer de tous lesnewet lesdeletesans aucun souci, tout sera géré automatiquement.[^] # Re: Bindings
Posté par paul . Évalué à 1.
Pour la gestion de la mémoire sans tracasserie, un bon ramasse-miette reste ce qui se fait de plus simple pour le programmeur. Ça existe depuis un bon moment en plus, il n'y a pas besoin d'attendre la finalisation de C++14 :)
Je contrôle, occasionnellement, le taux de charge du ramasse-miette dans mes programmes. Ça ne dépasse généralement pas 2% de l'activité du programme. Ce n'est pas 0%, je suis bien d'accord. Mais en échange de ces 2%, je ne m'occupe de rien niveau mémoire, et je peux faire de la prog fonctionnelle l'esprit tranquille, notamment pour ce qui concerne la gestion des données référencées dans les fermetures lexicales.
[^] # Re: Bindings
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Un rammasse miette n'a aucun intérêt en C++, à moins d'avoir des objets dont la libération peut affecter les ressources et devrait donc être repoussé.
[^] # Re: Bindings
Posté par arnaudus . Évalué à 3.
Ça ne pose pas un problème quand le destructeur a des effets de bord? (écrire un truc dans un fichier, modifier une variable, n'importe quoi?). Bien sûr, on pourrait dire qu'il s'agit de méthodes de programmation contestables, mais implémenter un ramasse-miette en C++ pourrait changer le fonctionnement des programmes, et à part mettre le bazar, je ne vois pas l'intérêt du truc.
[^] # Re: Bindings
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Un destructeur ne devrait pas avoir d'effets de bord. Mais bon, les gens croient que la responsabilité d'un destructeur est de faire table rase :'(
[^] # Re: Bindings
Posté par barmic . Évalué à 2.
Des fois c'est pas toi qui les crée (comme
errnopar exemple). D'autre fois t'a pas besoin de variables global pour avoir des effets de bords complexes.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bindings
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
errno est bien défini, et les compilateurs modernes fournissent une version multithread safe.
Je suis bien d'accord que le monde n'est pas parfait, ce n'est pas une raison pour ne pas le nier. :-D
[^] # Re: Bindings
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 14 janvier 2014 à 14:57.
A part si ton langage est abandonné par ses promoteurs et que tu te retrouve sans compilo maintenu pour les nouveaux OS à la mode.
Je suis une bille complète (suffit de regarder mon code, il est public et hyper moche).
L'avantage est "juste ça tourne partout depuis 20 ans et dans 20 ans ça tournera encore" ce qui me permet d'être partout contraire à mes concurrents qui sont souvent dispos que sur quelques logiciels "utilisateur" faute de binding sur le language x / support sur cet OS y.
C/C++ ont une tonne de défauts, on peut faire n'importe quoi avec, mais au moins ça vit longtemps et ça bouffe pas toute ta mémoire/CPU/Batterie (quand je vois mon smartphone souffrir simplement à cause de 2-3 merdes en Java, ça fait peur, certes les gens s'en foutent mais quand même…).
[^] # Re: Bindings
Posté par Antoine . Évalué à 9.
Si ça se trouve tes merdes en Java passent tout leur temps dans les couches natives (genre bibliothèque rendu graphique) plutôt que dans les quelques routines de traitement de données écrites effectivement en Java.
[^] # Re: Bindings
Posté par paul . Évalué à 1.
Clair. Je suis bien d'accord pour dire que Java est un langage de merde, mais ce n'est pas franchement lent. Sur les tests du shootout, Java se situe dans une fourchette 1 à 3 par rapport à C++. Pourtant ces tests sont des sections de code extrêmement discriminantes sur le plan calculatoire. Sur un programme classique, je doute qu'on puisse percevoir une différence de vitesse d’exécution.
[^] # Re: Bindings
Posté par Alex . Évalué à 5.
Il ne parlait pas de la perf "pure" de java, mais de sa conso en ressource notamment sur smartphone.
En cas réel java est tout de même lourd, le GC est fortement pénalisant dès que la jvm est un peu chargé, et pour une raison que je ne connais pas les applis graphiques ont tendances a être peu réactive
[^] # Re: Bindings
Posté par soulflyb (Mastodon) . Évalué à 6.
En général les applis graphiques en Java sont peu réactives car les dev codent comme des pieds et foutent des calculs lourds dans l'EDT (event dispatch thread).
[^] # Re: Bindings
Posté par Antoine . Évalué à 4.
Faudrait essayer d'être précis un peu. Ça veut dire quoi ce charabia, "perf pure" vs. "conso en ressource" ?
Pour une appli type smartphone qui affiche trois boutons et manipule une dizaine de données téléchargées depuis un Web service, je ne vois pas comment un quelconque langage de programmation pourrait être "tout de même lourd".
[^] # Re: Bindings
Posté par cedric . Évalué à 10.
Et bien, suffit de comparer un truc entre deux extremes pour voir un peu la difference. Par exemple, tu prends une appli qui utilise une webview avec JQuery pour afficher les dits boutons. Je te mets au defis de reussir a faire tenir ca dans moins de 150Mo. Alors forcement, des que l'application affiche un peu plus ca va vite et puis tu n'es pas tout seul sur les 1Go de RAM de ton telephone. En comparaison la meme application aurait utilise moins de 3Mo avec les EFL. Et encore, je pense etre un peu large dans mes estimations.
Au final, c'est la difference entre du C natif et bien controle vs du JS simple mais sans controle possible de ce qui se place. Perso, je prefererais avoir des applications de 3Mo comme ca en multitache, elle ne passerait pas leur temps a redemarrer entre autre chose…
Ah, et pour ce qui est des perfs de Java vs C, je suis assez impressionne des resultats d'Android qui n'est que 30% plus consommateurs de ressources batterie que les EFL en C. Il est probable qu'avec un controle fin de la memoire, il n'y aurait pas autant de difference, mais ca n'empeche que c'est pas mal comme prouesse quand meme (Bon apres si on a une autonomie de 10h, ca represente quand 3h de batterie de perdu en Java…).
[^] # Re: Bindings
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Comment tu compares les deux?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bindings
Posté par cedric . Évalué à 4.
Un mixe de benchmark et d'application écrites pour les deux plateformes. ensuite tu utilise le même hardware, tu enlèves la batterie et tu fais tourner ça sur une alimentation qui te donne une trace numérique. Quand je dis le même hardware, je parle bien d'un même device en dual boot, car entre deux devices il peut y avoir de légère différence de consommation pour plein de petit détail.
[^] # Re: Bindings
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Et tu arrives à isoler ce qui relève de la conso mémoire, CPU, GPU, etc..?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bindings
Posté par cedric . Évalué à 7.
Malheureusement sur le hard auquel on a acces, on ne peut pas mesurer la consomation independante de chaque sous systeme (Systom On Chip avec memoire Package On Package). Par contre, on a acces aux spec precises de consomation en fonction de la frequence du CPU, memoire, GPU et de la bande passante utilise pour chaque niveau de la hierarchie memoire (qui sont toute mesurable en temps reel), on peut faire une estimation au doigt leve de ou part la consomation d'energie. Ensuite en ajustant un algo dans un sens ou dans un autre, on peut verifier si notre theorie est bonne et ameliorer les choses.
On avance un peu dans le noir, surtout avec les experimentations sur la compression, car globalement la regle est moins on en fait, moins on consomme. Sauf que lorsqu'on compresse la memoire, on fait tourner plus le CPU, mais on fait moins de transfert memoire et on attend aussi moins sur le sous systeme memoire. Avant d'experimente, on n'etait pas sur de gagner au final. Mais il semble que le plus simple c'est de d'abord optimiser pour les performances, puis la memoire, et apres d'ajuster pour la consomation batterie si necessaire. Cela semble pour l'instant toujours porter ses fruits comme strategie.
[^] # Re: Bindings
Posté par Antoine . Évalué à 3.
Bon, si je prends comme exemple ma tablette Android, les quelques applications lancées prennent largement moins de 150Mo chacune. Avec par exemple un client mail qui prend 30 Mo de RAM.
(selon le panneau de paramètres, un peu plus selon l'appli Moniteur Système)
[^] # Re: Bindings
Posté par GaMa (site web personnel) . Évalué à 4.
Le Garbage collector, prend du temps. Peu quand tu as beaucoup de mémoire, mais quand tu es dans un environnement un peu limite, ça coûte cher
Je vous conseil la lecture de cet article :
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
qui est certes long et en anglais, mais qui est relativement clair et bien fourni.
Matthieu Gautier|irc:starmad
[^] # Re: Bindings
Posté par dave_null (site web personnel) . Évalué à 1.
On peut résumer l'article ainsi :
Mais au final les processeurs ARM rattrapent bien vite les processeurs X86, ma tablette a 2go de mémoire et l'application HTML5 que je développe actuellement est plus fluide sur iPad air que sur le dernier Firefox avec un PC i7.
L'article est quand même très intéressant car il explique bien les différences et les raisons.
[^] # Re: Bindings
Posté par cedric . Évalué à 6.
Il n'y a pas que la vitesse brute et visible par l'utilisateur. Il y aussi la possibilite de laisser tourner d'autre application en tache de fond et d'avoir une duree d'utilisation sur batterie qui reste "invisible" a l'utilisateur. Tant que tu ne codes qu'une petite application que l'utilisateur ne va pas utiliser pendant des heures, ca ne pose pas de probleme.
Mais GMail, Facebook, Twitter ou G+, ceux sont les premieres choses que je coupe quand je passe sur batterie. Ca tue litteralement la batterie de mon PC (je n'ai pas d'iPad, mais les consequence seront les meme). L'HTML5, c'est un joli hack pour deployer une petite application rapidement sur plein de terminaux, mais ce n'est pas forcement la solution pour tous les cas…
[^] # Re: Bindings
Posté par barmic . Évalué à 3.
Les défauts de la jvm ne sont pas très gênant sur android (voir même pas très gênant du tout), mais c'est vrai que pour JavaME c'est plus problématique (ça intéresse encore quelqu'un ce truc ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bindings
Posté par Enj0lras . Évalué à 4.
Quel troll !
Haskell est quasiment aussi vieux que C++ (haskell début des années 90, C++ milieu des années 80), à 5 ou 6 ans près. Et le premier standard de Haskell date de la même année que le premier standard de C++.
[^] # Re: Bindings
Posté par paul . Évalué à 1.
C'est vrai, mais je pense que zenitram voulait surtout mettre en avant le côté mainstream de C++. C++ est tellement répandu dans l'existant et dans l'industrie qu'il est, de fait, indéboulonnable pour encore un bon moment. Un peu comme Java ou Python.
Ce n'est pas le cas de Haskell, qui ne pèse pratiquement rien dans l'industrie, et dont la communauté est tellement petite qu'il ne s'y trouve personne de suffisamment motivé pour faire des bindings pour Qt :)
Sinon j'ai l'impression que les bindings WxWidgets (également écrit en C++) sont bien plus courants que les bindings pour Qt. Une explication à cela ?
[^] # Re: Bindings
Posté par Lutin . Évalué à 2.
WxWidget a une philosophie assez proche des MFC de ce qu'on m'a dit (je n'ai jamais utilisé les MFC) que beaucoup de gens connaissent, ça peut être une des raisons.
[^] # Re: Bindings
Posté par woprandi . Évalué à 1.
Mieux vaut un bon programme Java qu'un mauvais programme C/C++
[^] # Re: Bindings
Posté par paul . Évalué à 6.
Oui oui, et puis mieux vaut un bon programme qu'un mauvais programme.
[^] # Re: Bindings
Posté par Philippe F (site web personnel) . Évalué à 3.
Un truc sympa avec Qt qu'on mentionne pas souvent, c'est que la gestion de la mémoire est bien foutue. Il y a un garbage collector basé sur du comptage de référence qui est bien en phase avec le besoin: comprendre, ça marche très bien et très discrètement quand on a besoin, mais c'est pas un Garbage Collector générique de la mort qui tue.
A l'époque surtout, c'était une vraie révolution de ne plus se torturer les méninges sur qui doit détruire l'objet string dont tu retournes le pointeur dans ta fonction. En Qt, tu retournes une string et elle sera détruite quand tu n'en aura plus besoin, même si tu sais pas quand ça arrive.
[^] # Re: Bindings
Posté par oao . Évalué à 3.
Ca a encore un intérêt, avec std::shared_ptr (ou boost, pour les versions pré C++11) ?
[^] # Re: Bindings
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Je crois qu'il fait référence à plusieurs techniques (copy on write, reference counting, implicit sharing, hiérarchie d'objets…) utilisés dans Qt qui ne sont pas du garbage collecting et qui ont parfois des équivalents dans std ou boost.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bindings
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
mmm.. Coder en nageant, c'est à mon avis très difficile :-) (oui parce qu'en plongée, quand on ne fait pas un palier de décompression, on nage, forcément).
Pendant un palier de décompression, pourquoi pas, même si ça doit être acrobatique et qu'il faut avoir du matos étanche :-) (Ou si le palier se passe hors de l'eau, ça devient plus facile, mais bon, dans ce cas, ça veut dire que l'on est en caisson, et si on est en caisson, c'est généralement qu'on n'est pas en bonne forme…)
Par contre, entre deux plongées, ça, facile ;-)
# Android est supporté
Posté par dsant69 . Évalué à 10.
Après Linux, Windows et MAC, Qt est aussi porté pour Android. Et iOS et Blackberry.
http://blog.developpez.com/gpu/?p=522
[^] # Re: Android est supporté
Posté par zebra3 . Évalué à 4.
Il existait déjà sur Symbian, c'est pas pour ça qu'il y a eu des applis…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Android est supporté
Posté par tanguy_k (site web personnel) . Évalué à 1.
C'est un mauvais exemple, quand Qt est sortie pour Symbian, Symbian etait deja a l'agonie (iOS et Android etaient deja la)…
Qt existe pour Windows CE depuis longtemps, difficile de juger de la popularite du truc, neanmoins "KDAB’s customers still showed a lot of interest in the platform we decided to step forward to fill the gap"
A mon avis Qt pour iOS et Android n'est pas inintéressant mais arrive un peu tard.
[^] # Re: Android est supporté
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pourquoi? Android et iOS vont s'incliner devant le succès de Firefox OS?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Android est supporté
Posté par tanguy_k (site web personnel) . Évalué à 0.
Je pensais à Qt vs toolkit iOS/Android (qui sont desormais bien etablies et maitrises).
Pour Firefox OS, les qqs retours utilisateurs sont malheureusement tres mauvais.
[^] # Re: Android est supporté
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Pour ne pas développer deux fois la GUI, c'est quand même pertinent!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Android est supporté
Posté par tanguy_k (site web personnel) . Évalué à 1.
Oui c'est vrai, j'avais complètement zappe cet aspect la !
[^] # Re: Android est supporté
Posté par barmic . Évalué à 3.
Je ne sais pas comment Qt gère ça mais ça risque d'être compliqué. L'intégration sur mobile est bien plus importante que sur desktop, Apple et Google définissent des bonnes pratiques qui sont assez écartées l'une de l'autre (manière d'organiser les menus, qu'est ce qui doit être dans un menu ou pas, comment faire de l'accès rapide à des fonctions, les notifications n'ont pas les même fonctionnalités sur les 2,…).
C'est peut pas impossible mais pour arriver à être générique entre les 2 je présume qu'il faut définir des interfaces de manière vraiment abstraite (tu ne défini pas une barre d'outil, mais liste les fonctionnalités qui doivent être en accès rapide et ainsi de suite).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Android est supporté
Posté par Zenitram (site web personnel) . Évalué à 2.
Je n'ai pas (encore) testé sur les smartphone, mais Qt gère déjà ce genre de choses avec Mac (menu hors fenètre, "About" qui doit être dans un menu spécial…)
C'est jouable.
Et surtout, si déjà on a un code commun pour l'affichage sans les menus, c'est toujorus ça en mieux par rapport à rien!
[^] # Re: Android est supporté
Posté par Gof (site web personnel) . Évalué à 4.
Va dire aux designers avec lesquels j'ai travaillé. Il te pondent un truc qui ne s'intègrent avec aucun mais et veulent que l'application soit exactement pareil sur toutes les platformes. Parfois le designer aime Apple alors tout les contrôle ressemble à ceux du iPhone mais pas exactement.
Personellement, je suis d'accord que l'intégration est importante sur mobile, mais je ne dirais pas plus importante que sur le desktop. Je dirais que l'intégration est importante dans les deux cas.
[^] # Re: Android est supporté
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
L'intégration, c'est une bonne blague:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Android est supporté
Posté par ariasuni . Évalué à 2.
Bah Firefox prend le look GTK, et globalement on a GTK/Qt. Qt prend le thème GTK si tu veux, ou alors sous un environnement Qt il y a oxygen-gtk2 et oxygen-gtk3. Même si l’intégration est tellement pourrie en dehors de l’apparence (types MIME et saloperie de sélecteur de fichiers GTK) que j’utilise firefox-kde-opensuse, qui par chance est présent dans un dépôts non-officiel d’Arch Linux — sinon vu le temps de compilation de Firefox je n’essaierais même pas.
Problème récurrent dans les applications Java, utiliser le thème moche par défaut de Java ou autre, qui sont souvent moches d’ailleurs, au lieu d’utiliser l’apparence native. De plus, sous KDE Java ne prend pas l’apparence GTK et n’a pas d’apparence Qt, du coup c’est moche.
Mais dans les UI pourries je pensait à Eclipse plutôt, qui prend a des menus au look GTK mais des composants graphiques personnalisés complètement horribles…
De plus en plus de sites utilisent un truc genre Bootstrap ou JQuery UI. En même temps, les sites web à la base sont des documents, et pas des applications. On attends donc pas grand chose côté fonctionnel, à part la navigation. Même si les sites web deviennent de plus en plus des usines à gaz…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Android est supporté
Posté par barmic . Évalué à 2.
Sur smartphone tu as beaucoup d'actions invisibles (qui viennent du tactile), il faut se conformer un minimum à ceux classiques de l'OS si tu veux pas que tes utilisateurs aient une mauvaise expérience utilisateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Android est supporté
Posté par ariasuni . Évalué à 2.
J’ai pas l’impression que ça soit différent de l’ordinateur… Par exemple, quand j’ai une saleté de boite de dialogue GTK qui apparait alors que suis dans KDE, bah je te peux te dire que le manque d’intégration je le sens passer.
Et je pourrais aussi parler des applications GNOME 3 qui ne s’intègre pas du tout dans KDE (bon c’est vrai que ça c’est pas mal amélioré récemment, par exemple Nautilus est vraiment bien).
Écrit en Bépo selon l’orthographe de 1990
# LXDE et Qt
Posté par 태 (site web personnel) . Évalué à 6.
Qu'en est-il vraiment de lxde ? Il y a six mois, on nous annonce que lxde passe à qt et absorbe razor-qt parce que c'est plus facile que de passer à gtk3.
Quand on regarde les logs de développement, il semble que lxde-qt, lximage-qt, lxappearance-qt n'ont, à part les traductions, pas bougé depuis juillet. Alors que lxappearance a eu trois releases pendant cette période et a un switch gtk3 dans le script configure, que gpicview a eu une release il y a deux mois et passe à gtk3…
Bref, est-ce que lxde-qt est mort avant d'avoir vécu. Ou est-ce juste une impression ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.