• [^] # Re: Qt

    Posté par . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 7.

    Le seul toolkit que je connaisse qui s'approche, de loin, de l'idée d'abstraire les autres framework est WxWidgets. Il est possible de faire se reposer wx sur l'API win32, sur Xorg, sur Gtk (le défaut sous linux) et il me semble qu'il y à eu à un moment des efforts pour du support Qt.

    Ça marche plutôt bien, c'est portable, ça supporte les fonctionnalités classiques (système évènementiel dynamique, conteneurs, toute la flopée de contrôles habituels, persistance pour la config). Il y à bien de petites choses qui pourraient être améliorées, mais bon, rien de bien méchant.

    Pour en revenir à la question de "pourquoi on peut pas choisir à la compilation"... si on prend le cas de Qt, il commence par modifier la chaîne de compilation: c'est du C++ «amélioré». Dans le cas de GTK, on à du C brut. Et si on devait prendre le cas de wx, c'est du C++ brut.
    Du coup on à des bibliothèques qui sont basées sur des technologies de niveau différent. J'ai «entendu dire» que gtk faisait de l'objet. Dans un langage qui n'est pas fait pour. Ce genre de choses risquerai d'amener pas mal de problèmes en cas de passage à du C++ réel. Même si ces langages ont un fort taux de compatibilité, c'est très glissant.
    Je ne parlerai pas du fait que les toolkit graphiques sont anciens. Du coup ils ont souvent implémenté leurs propres versions des même conteneurs (bien qu'il me semble que dans le cas de Qt un travail ait été fait pour se baser sur le standard. Dans le cas de Wx, j'en suis sûr). Du coup, risque d'incompatibilité entre ces conteneurs.
    Pire, en C, il n'y à aucun conteneur en standard, donc GTK réinvente la roue concernant la gestion des chaînes de caractères.

    Et ce ne sont que quelques problèmes que je peux voir alors que ça fait bien longtemps que je n'ai pas touché un toolkit graphique.