Journal Uniformisation des librairies graphiques

Posté par  (site web personnel) .
Étiquettes : aucune
0
12
sept.
2004
Bonjour journal, bonjour lecteurs/trices.

En lisant cette news traitant du portage de gecko sur QT, une question me vient à l'esprit:
Pourquoi ne pas uniformiser les librairies graphiques.

J'imagine que beaucoup de librairies ont des points en commun, genre qt_ouvre_cette_fenetre() et gtk_ouvrir_ la_fenetre() et d autre encore.
Et le portage semble si fastidieux qu'on en fait une news...

Pourquoi ne pas normaliser les fonctions communes (ou appelées à l'etre) du genre LIB_ACTION() où ACTION serait commun a toutes ces librairies, et le code de la fonction aussi, et pour porter, on n aurait qu'a renommer les fonctions, et a faires des petites modifs selon les spécificités des librairies (du genre, cette fonction prend R,G,B séparément, et chez le "concurrent", elle prend un structure RGB).

Le portage en serait sans doute grandement simplifié, et la communauté y gagnerait sans doute.

Mais peut-etre revé-je, peut-etre que cela est stupide ou s'avere etre une tache impossible, peut-etre est-il trop tard...
Toutefois, ca me semble plutot bon comme idée...

Qu'en pensez vous?

  • # Euh ...

    Posté par  . Évalué à 8.

    Une couche d'abstraction de la couche d'abstraction en somme ?

    On tient un concept là

    M

  • # Oui, oui, oui, j'adhère !

    Posté par  . Évalué à 4.

    Eh ben, oui, c'est une bonne idée, y'a plus qu'à !
    ;-)

    Une structure indépendante décrivant l'interface visuelle ... et plusieurs générations :
    - wrapper QT en C++
    - wrapper GTK en C / C++
    - interface HTML, javascript
    - wrapper VB (ben oui, pourquoi pas)
    - wrapper C# (juste pour troller)
    - wrapper TCL/TK
    - wrapper bash-dialog
    - etc ...

  • # Un sujet est important en soi ou pas

    Posté par  . Évalué à 1.

    "Et le portage semble si fastidieux qu'on en fait une news..."

    C'est pas la "news" qui donne l'importance du travail réalisé

  • # sauf que la "philosophie" diffère

    Posté par  . Évalué à 2.

    Peut etre que je vais dire une connerie...

    Mais QT etant du C++ (donc objet) et GTK etant du C (don impératif), perso ca ne me parait pas simple du tout... Etant donné que la facon de programmer n'est pas la meme.

    Non ?

    Corrigez moi si je me trompe.

    • [^] # Re: sauf que la "philosophie" diffère

      Posté par  . Évalué à 4.

      Tu ne te trompes pas (enfin pas trop, le C++ est objet ET impératif..., en fait je crois que tu voulais dire structuré concernant le C), mais GTK, bien quand langage C, est tout de même orienté objet.

      Reste que la facon de programmer n'est effectivement pas la même, est que la manière la plus "sage" d'uniformiser les interfaces d'un point de vu de l'utilisateur est certainement via les thèmes. Du point de vue d'un développeur, un logiciel bien concu devrait avoir sa logique découplée du code de son interface, ce qui facilite énormement le portage sur une autre architecture de bibliothèque.

  • # GTK-QT

    Posté par  (site web personnel) . Évalué à 5.

    Pour ceux qui ne connaitraient pas, il y a dors et déjà gtk-qt, thème GTK2 faisant appel aux widgets de QT.
    http://xserver.freedesktop.org/Software/gtk-qt(...)
    Ça suffit à rendre l'interface dejà grandement plus cohèrente.
    Sans parler des inombrables thèmes GTK1 simulant des thèmes QT.

  • # Uniformisation des librairies graphiques

    Posté par  (site web personnel) . Évalué à 5.

    Déjà, si on uniformisait les appels à certaines fonctions telle que ouvrir un fichier, rechercher/remplacer, enregistrer sous... afin de pouvoir avoir un jeu de boite de dialogue cohérent, ça serait pas mal.
    Comme imprimer avec Openoffice ou Mozilla que tu peux par exemple configurer avec kprinter et hop, tu as la boite de dialogue de kde.

    Quand à faire, y inclure le navigateur d'aide serait pas mal aussi.
    Il suffirait (?) de créer une variable $TOOL_BOX_SET. Un truc dans le genre. Avec un fichier de config pour chaque appli pour pouvoir personnaliser (filtre par défaut, aperçu des images...).

    Tu pourrait ainsi choisir tes boites de dialogue comme tu choisis ton WM.

    Enfin c'est juste une idée.

    Pour l'uniformisation des toolkits, je crois que c'est bien utopique dans la mesure où ils ne couvrent pas tous les mêmes domaines. Si tk est uniquement un ensemble de widggets, QT comporte tout un tas de fonctions non graphiques.

  • # Réinventons l'eau chaude!

    Posté par  . Évalué à 4.

    Euh, wxwidgets, c'est pas ce que tu voulais par hasard?

    http://wxwidgets.org/(...)

  • # XUL

    Posté par  (site web personnel) . Évalué à 3.

    C'est le but de XUL.

    D'ailleurs, il n'est pas dépendant d'un langage de programmation particulier car l'IHM est décrite en XML (donc déclaratif).

  • # Pourquoi ne pas faire un "compilateur" ?...

    Posté par  (site web personnel) . Évalué à 2.

    Schéma de principe :

    On crée une "librairie" qui synthétise l'ensemble des appels communs.
    Cette librairie sera la plus simple possible. J'ai un excellent exemple d'un truc buggé archi simple pour se donner une idée : Windev.
    L'idée consiste donc à créer une librairie ultra simple, sans pointeur,sans handle, des fonctions simples genre creerfenetre(),
    si cliquebouton(bouton_OK) alors ...
    mon_choix = ma_liste[ma_liste.select]

    etc...


    On interface ensuite un "compilateur" qui traite ces fonctions spéciales et les traduisent en gtk, qt, etc...
    Ce compilateur prend du c et crache du c, idem avec c++, etc...

    Mieux, ils ne s'occupent que de traiter les fonctions de la "librairie"


    C'est un peu une approche à la glade, sauf que l'on reste dans le domaine d'un langage et que cela évite des indirections trop lourdes au niveau du code.

    En plus il n'y a pas de raisons que cela créee des exécutables lent et buggés

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Pourquoi ne pas faire un "compilateur" ?...

      Posté par  (site web personnel) . Évalué à 2.

      Il me semble que ça reviendrait au même si on créait une nouvelle bibliothèque intermédiare dont toutes les fonctions seraient "inline" (et/ou des macros). De cette manière, le code vraiment généré utilise aussi directement les appels de GTK/QT/WxBrol/...

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # c'est possible, c'est fait, mais c'est pas toujours bien

    Posté par  (site web personnel) . Évalué à 4.

    D'abord celà existe déjà :
    par exemple wxWidgets utilise les toolkit graphiques natifs pour se dessiner. SWT en Java fait de même.

    Mais celà a des avantages et inconvénients :
    tu dois factoriser les points communs entre les toolkits, résultats tu vas perdre ce qui fait la spécificité d'un toolkit : des fonctionnalités mais aussi des règles d'ergonomie, de conventions, de nommage, de disposition, d'encapsulation, d'interactivité, etc.
    Tu peux y remédier partiellement pour ce qui est des fonctionnalités en "simulant" de nouveaux widgets sur les toolkits plus "pauvres" : il y aura pleins de problèmes d'intéraction avec l'environnement, ces nouveaux widgets s'intégrant souvent mal, surtot qu'il faut la plupart du temps le réécrire entièrement pour pouvoir l'étendre.

    Bref, ce n'est pas simple, parcque justement s'il existe plusieurs toolkit, c'est parcqu'ils sont différents. Tu peux te contenter des points communs, mais celà va vite te faire un toolkit basique, voir très réduit au fur-et-à-mesure que tu vas étendre sa "portabilité".

    Je comprend ton problème et tu aimerais bien faciliter la vie du programmeur, mais il faut savoir que rien ne vaudra jamais une application qui s'intègre parfaitement dans chaque environnement et que la solution que tu proposes ne le permettra jamais, ou alors c'est que les toolkits sont trop "proches". Fait mieux : code correctement ton application en séparant bien l'interface, histoire de pouvoir la réécrire facilement. (PS : penses aussi au fait qu'une application peut être utilisé sur des périphériques portables, mais aussi à travers une interface web qui est un toolkit comme un autre (HTML+JScript), mais cependant très différents)

    C'est comme dans la vie : il ne faut pas vouloir mondialiser tout pour simplifier, certaines choses doivent rester différentes, que chacun est sa culture et puisse la faire évoluer avec ses spécificités, quitte à venir piocher de temps en temps chez le voisin les bonnes idées.

  • # mmpf

    Posté par  . Évalué à 2.

    s/librairie/bibliothèque

    que je sache on code pas des "bookshops" !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.