Journal Conception d'une API interface utilisateur

Posté par  (site web personnel) .
Étiquettes : aucune
0
6
juil.
2005
Chers tous , dans un précédent journal j'avais posé la question de ce que des développeurs désireraient dans une API graphique orienté jeu.

J'ai maintenant la tentation de vous poser la même question pour une API interface utilsateur du type swing, Gnome, QT, etc... en ne considérant que les fonctions de bases au début.

Cette API est destinée à être écrite en Lisaac ( http://fr.wikipedia.org/wiki/Lisaac(...) ) pour le projet Isaac qui consiste à écrire un OS intégralement objet avec ce langage dédié (ce qui est déjà le cas puisque l'OS fonctionne déjà sur 5 architectures différents) . Sur le site http://isaacos.loria.fr/(...) vous trouverez une démo sous linux.

L'API est donc destinée à être utilisée pour cet OS, elle n'est pas vouée à être un binding de tel ou tel autre librairie, car l'OS est par essence autonome et embarque tout, du putpixel en utilisant les registres de la cartes à la gestion des fenêtres.

La question est donc : Qu'est ce qui vous dérange, que préférez vous dans l'utilisation de votre toolkit graphique préféré ?
Quels points voudriez vous voir améliorer ?

Quel serait l'API l'interface utiilisateur de vos rêves ?

  • # Est-ce à nous de le dire ?

    Posté par  . Évalué à 7.

    Je pense qu'il est inutile de nous demander notre avis.
    Je trouve en effet qu'un toolkit doit tirer profit des capacités du langage de programmation dans lequel il est conçu, et donc proposer une API qui y soit adaptée.
    Prenons par exemple Qt : je le trouve parfaitement adapté au C++, mais par contre ses bindings python (pyqt) ne sont pas adaptés au langage python : le système de connexion signal/slot n'est pas, et de loin, le plus adapté au langage python dans l'état actuel des choses. Pourquoi faire un QObject.connect (source, signal, cible, slot) alors qu'on pourrait en python faire un cible.slot.append(source.signal) ou un truc comme ça ?

    Bref, je ne pense pas que linuxfr soit le meilleur endroit pour trouver l'API de ton toolkit : il y a trop peu de personnes connaissant le Lisaac pour aider à faire une API adaptée...

  • # les sources ??

    Posté par  . Évalué à 2.

    On a pas droit aux sources lissac du "Système" ?
    Pas le gros fichier .c généré par le compilo car ca c'est l'équivalent d'un "binaire" hein ! Je parle des sources en issac.

    • [^] # Re: les sources ??

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

      Ca va venir.

      Le problème c'est de convaincre l'Inria que ça sert à rien de rester closed source

      Comme quoi les promoteurs de la cecill, sont pas toujours LL ...

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

  • # fonctionnalités

    Posté par  . Évalué à 4.

    Il y a trois fonctionnalités indispensables à gérer pour moi:

    - le multilangue.
    - le redimmensionnement.
    - la séparation entre l'interface et les données/fonctionnalités.

    • [^] # Re: fonctionnalités

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

      Très interessant merci :-)

      Le multilangue, tu l'entend à la Windev ou chaque fonction/méthode est traduite en plusieurs langue et/ou tu l'entend en terme de gestion des textes affichés sur les boutons, les champs etc... ?

      Le redimensionnement, il n'y aura pas de problème car la librairie s'appuiera sur un objet graphique vectoriel. L'interface primitive implémentée actuellement est postscript v1 en natif...

      Justement, question séparation de l'interface, je pense de plus en plus à concevoir un système basé sur XUL : les interfaces seront uniquement décrites en XUL et un parser se chargera de l'affichage.

      Au delà de ça, je pense qu'il faudrai designer la lib de sorte que celle-ci se contente d'envoyer des messages aux objets chargés des fonctionnalités.

      A creuser

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

      • [^] # Re: fonctionnalités

        Posté par  . Évalué à 3.


        Le redimensionnement, il n'y aura pas de problème car la librairie s'appuiera sur un objet graphique vectoriel. L'interface primitive implémentée actuellement est postscript v1 en natif...


        Ne pas confondre "redimensionnement" et "zoom vectoriel". Le redimensionnement c'est quand tu agrandi ta fenètre mais que ton interface reste "cohérente", i.e., qque les boutons ne s'agrandissent pas mais que les champs éditablent/de présentation s'agrandissent pour présenter une surface de visualisation plus grande.
        (Au passage: sous linux on a trés rarement ce problème mais esseye un Windows et tu va voir que tu hurle a la mort a plein d'endroits. -ne serait-til pas prés pour le Desktop?-)


        Justement, question séparation de l'interface, je pense de plus en plus à concevoir un système basé sur XUL : les interfaces seront uniquement décrites en XUL et un parser se chargera de l'affichage.


        Esseye de penser a un langage trés "déclaratif" pour les interfaces: "qu'est ce que je veut afficher" et non "comment doit ce comporter mon interface". Par exemple doner la possibilité d'associer automatiquement un champs texte a un attribut d'un objet. L'attribut sera automaitquement modifié lors de la saisie dans le champs texte et vice-versa.
        Regarde du coté de GNUstep et de GORM, il y a des idées vraiment interressante dans la gestion de IHM/GUI. Le futur MS Visual 2005 proposera aussi un système du mème genre.
        (Le pattern MVC est biens mais quand mème trés lourd a mettre en oeuvre a chaques fois.)


        Au delà de ça, je pense qu'il faudrai designer la lib de sorte que celle-ci se contente d'envoyer des messages aux objets chargés des fonctionnalités.

        Je crois que c'est dans ce sens qu'il pourrait y avoir des innovations: les système d'action, de listener ou d'evenement (signaux) n'ont jamais conquis a 100% n'importe quel développeur. Trouver un nouveaux mecanisme pourrait etres vraiment innovant.

        • [^] # Re: fonctionnalités

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


          Ne pas confondre "redimensionnement" et "zoom vectoriel". Le redimensionnement c'est quand tu agrandi ta fenètre mais que ton interface reste "cohérente", i.e., qque les boutons ne s'agrandissent pas mais que les champs éditablent/de présentation s'agrandissent pour présenter une surface de visualisation plus grande.
          (Au passage: sous linux on a trés rarement ce problème mais esseye un Windows et tu va voir que tu hurle a la mort a plein d'endroits. -ne serait-til pas prés pour le Desktop?-)


          C'est une bonne problématique, on va y réfléchir :-)
          Mais c'est transparant au niveau code pour l'utilisateur ça (?).


          Esseye de penser a un langage trés "déclaratif" pour les interfaces: "qu'est ce que je veut afficher" et non "comment doit ce comporter mon interface". Par exemple doner la possibilité d'associer automatiquement un champs texte a un attribut d'un objet. L'attribut sera automaitquement modifié lors de la saisie dans le champs texte et vice-versa.


          C'est effectivement un peu comme ça que je le visualisai.
          J'ai fait un peu de windev.. et outre que ce langage et ce système est pourri (affreusement buggé, tient pas la charge, etc...) il est très bien pensé sur de nombreux point et en particulier celui de la facilité de compréhension et d'accès au code (et la doc est la meilleur doc pour logiciel de dev que j'ai jamais vu. Un modèle du genre).
          Mon but est aussi de faire en sorte que coder une interface avec cette lib soit le plus simple possible.
          Donc effectivement un champ texte sera un objet, avec pour prop son emplacement, quelques autres données cosmétiques et un get/set sur le string qu'il contient.



          Je crois que c'est dans ce sens qu'il pourrait y avoir des innovations: les système d'action, de listener ou d'evenement (signaux) n'ont jamais conquis a 100% n'importe quel développeur. Trouver un nouveaux mecanisme pourrait etres vraiment innovant.


          En ce qui me concerne, je voudrai faire évoluer le langage en lui ajoutant des fonctionnalité acteurs : un acteur envoi un message à l'assemblée en déterminant qui a droit de le recevoir et chacun sélectionne ensuite ce qu'il veut recevoir. Un système de mail entre objet en qq sorte.
          Je pense qu'il serai assez génial de faire tourner la lib et la gestion des event comme ça, ça rejoindrai mon idéal de simplicité totale du code.
          En attendant, je ne sais quel système choisir. Surement un système d'évènement comme il en existe déjà un sur l'OS.

          Mais franchement j'aurai besoin d'en savoir un peu plus sur ces systèmes et les problèmes qu'ils génèrent. Merci pour les liens :-)

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

          • [^] # Re: fonctionnalités

            Posté par  . Évalué à 2.

            Mais c'est transparant au niveau code pour l'utilisateur ça (?).

            Pas vraiment, parce que l'utilisateur (developpeur) doit preciser ce qui s'etend et ce qui ne s'etend pas, les proportions de chaque widget...

            Amuses-toi un peu avec Glade ou QtDesigner pour voir comment ca marche.

            Sous Windows il y a de l'abus de placement absolu, ce qui fait que les boites de dialogue ne sont pas souvent redimensionables (genre les fenetres de configuration).

        • [^] # Re: fonctionnalités

          Posté par  . Évalué à 2.

          Par exemple doner la possibilité d'associer automatiquement un champs texte a un attribut d'un objet.[...] Le futur MS Visual 2005 proposera aussi un système du mème genre.


          Ca existe depuis longtemps, même avec les antiques MFC...

Suivre le flux des commentaires

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