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 thecat . En réponse au journal Conception d'une API interface utilisateur. É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.