Citation:
Envoyé par
fcharton
Une petite liste d'idées pas forcément très organisées... (koala, va falloir t'habituer à me trier...)
Ne t'en fais pas, je sais ce que c'est :D
Et toi, il faudra que tu t'habitue en retour au fait que je réfléchis souvent "tout haut" (ou, sur le forum, "par écrit")... et que tu n'hésite surtout pas à reprendre les points qui ne te paraissent incorrect ou peu clairs... C'est un deal :question:
Citation:
En fait, dans ces modèles les deux axes sont parfaitement interchangeables : un alignement vertical, c'est comme un alignement horizontal, etc... On commence même à voir des plateformes sur lesquelles on peut les echanger très naturellement (iphone).
Le sens de ces axes est également conventionnel : ca va vers la droite et vers le bas chez nous, parce que c'est comme ca qu'on écrit, mais on a des plate formes ou l'horizontal est orienté dans l'autre sens: l'arabe et l'hébreu par exemple, mais aussi le chinois et le japonais classiques, qui s'écrivent en colonne de la droite vers la gauche...
Je ne sais pas très bien comment on modélise ca, mais il me semble qu'il faudrait y réfléchir... En gros, c'est un peu bête de parler de x et de y si on veut pouvoir les échanger comme on veut...
Peut être en définissant:
- une politique "orientation " (l'axe des X va de gauche à droite ou de haut en bas et l'axe des y va... perpendiculairement)
- une politique "sens horizontal"
- une politique "sens vertical"
A mon sens, le bipoint est le mieux placé pour prendre cela en charge... Mais ai-je raison de le penser :question: Faut-il en faire des politiques "globale" (dans le sens où tous les objets suivent par défaut les mêmes) ou une politique "particulière", en donnant la possibilités à deux éléments visuels d'une même "fenêtre" la possibilité d'avoir des politiques différentes (et parfois totalement opposées) :question:
Quelque part, s'il est possible d'avoir des politiques différentes pour chaque objet, cela ouvre des horizons innombrables... et implique des casses tête pour ce qui est de la définition des référenciels :D :P
2- Alignement
Citation:
Au delà du positionnement par coordonnées, la forme la plus courante de définition d'une IHM c'est le positionnement d'éléments les uns par rapport aux autres. Le bouton 123 n'est pas en position (42, 57), mais à 2 pixels à gauche du bouton 122... Le panel 32 ne fait pas 500 par 220, mais 220 de haut, en occupant tout l'espace horizontal allant du panel 31 au panel 33... Et ainsi de suite.
Ce qui, de manière assez marrante, implique qu'il faut prendre la distance entre... le coté droit (quel que soit le sens que l'on donne à "droit" dans notre cas :D) d'un des élément et... le coté gauche de l'autre :D
Citation:
Cette notion d'alignement est importante quand on redimensionne une fenêtre, car c'est lui qui décide du déplacement des éléments d'interface. Si on le programme correctement, l'utilisateur n'a pas besoin de gérer les redimensionnements...
Effectivement...
Mais, tant qu'à faire, je souhaiterait quelque chose de plus souple que ce qui est proposé par Qt, par exemple, où lorsque l'on travaille avec une grille, il n'est pas possible de mettre un élément tenant sur deux lignes à coté de deux éléments tenant sur une ligne sans passer par un "canevas" supplémentaire...
Citation:
Elle joue également un rôle quand on ajoute des éléments dans un conteneur : c'est l'alignement du parent qui décide(entre autres) de l'apparition de barres de défilement...
Elle intervient, effectivement, partout :D
Citation:
Dans la pratique, la présence d'un trait d'alignement provoquera le recalcul des coordonnées d'un (ou plusieurs) éléments d'interface...
ou, en tout cas, de tous les éléments "enfant" de l'élément auquel le trait est appliqué, effectivement (et il pourrait être "hérité" par les enfants, mais pas forcément :aie:) :D
Citation:
En général, l'alignement va se définir selon trois principes (je suis sur ce sujet Borland et Adobe/Flex):
- les alignements de base : ce sont des lignes qui permettent de positionner l'élément : 4 pixels à gauche du bouton, centré au milieu de la fenêtre, etc... A priori, il y en a 2 : un horizontal, un vertical
- les ancrages, déterminent la façon dont l'élément se déplace ou se redimensionne quand la taille de la fenêtre ou d'un de ses composants change : sur l'axe horizontal, un composant ancré sur sa gauche "suivra" le composant à gauche, un ancré à droite suivra le composant à sa droite, un ancré des deux côtés se redimensionnera horizontalement quand ses ancrages bougent
- les contraintes, qui déterminent les tailles minimales et maximales d'un composant, elles empêchent le redimensionnement
Hé oui...
Citation:
On pourrait éventuellement imaginer d'autres politiques de redimensionnement...
Et de positionnement...
Tu avais émis l'idée (dans la discussion qui a précédé le lancement du projet) me semble-t-il de pouvoir faire en sorte qu'un élément soit dépende d'un autre sans pour autant qu'il ne soit limité en terme de positionnement par l'espace occupé par celui-ci... (en gros, avoir une boite à outil à gauche et un des boutons de celle-ci à droite)
Faudra relire la discussion, mais c'était une idée qui m'avait charmé :D
Citation:
Ces aspects se retrouvent en horizontal et en vertical... Ils ne sont pas parfaitement orthogonaux au positionnement : en fait, quand on a alignement, le positionnement initial est recalculé en fonction de l'alignement
Effectivement, ils travaillent de concert dans une certaine mesure et sont sans doute parfois exlusifs ;)
Citation:
3- Fontes et texte
Un certain nombre d'éléments d'interface se verront affecter du texte (une légende, des données...). Le texte doit pouvoir se définir selon trois axes :
- le texte à afficher
- une police d'affichage (avec sa taille)
- un point de départ
Je rajouterais la forme...
Un peu (si tu as déjà utilisé le genre d'outils auxquels je pense) à la manière des logiciels de création de bannières, de cartes postales, ou de couvertures de boite de CD, qui permettent d'avoir une écriture en forme de vague, de serpent, ou qui suit un arc de cercle.
Evidemment, cela ne peut réellement fonctionner, dans le meilleur des cas, qu'avec des polices vectorielles :P
Citation:
Un certain nombre de fonctions de base doivent être rendues disponibles, notamment le calcul de l'espace occuppé par un texte, le clipping (ou les ellipses), éventuellement les primitives permettant l'écriture sur plusieurs lignes).
L'affichage du texte est presque un sujet à part...
Oui, outre le tracé des forme et la transmission des messages, l'affichage de texte fera partie des gros morceaux :aie:
N'hésite pas à ouvrir une discussion sur le sujet :D
4- Formes de base
Comme Koala en parlait, je suggérerais bien que l'on considère dans un premier temps, comme éléments de base
Citation:
- les points
- les lignes (définies par un bipoint, une épaisseur, des paramètres de dessin)
- les arcs (on a plusieurs choix, là : arcs de cercle, splines, courbes de bézier, NURBS, chacun plus riche que le précédent, mais plus complexe pour l'utilisateur aussi)
donc, ton bipoint n'avait pas pour objectif de définir en lui-même un "rectangle de base", mais bien, simplement, de définir... un "segment de droite" (y a-t-il un meilleur terme :question:) que l'on assigne en définitive à ce qu'on veut (comme j'en ai montré l'exemple), c'est bien ca (je commence à fatiguer, et j'hésite sur le sens à donner à ta phrase :aie:)
Citation:
- les rectangles (parallèles aux axes), un carré c'est un rectangle, et les coins ronds, ca fait partie du rectangle
Effectivement, un carré n'est (ici du moins) jamais qu'un rectangle particulier... Par contre, il serait alors sympa d'avoir un moyen de vérifier H == L lorsque l'utilisateur veut garantir que c'est un carré :P (mais bon, cela peut n'être qu'un booléen placé à true ou à false :D)
Citation:
- les ellipses (parallèles aux axes aussi), un cercle c'est une ellipse
Cela implique, malheureusement, d'avoir... deux rayons (un rayon sur chacun des axes)... encore une fois, quitte à ce que le cercle soit considéré comme une éclipse dont les deux rayons sont de taille identique (encore une fois, un booléen peut y suffire :D)
Et cela nous mène, finalement, à un choix "crucial"...
Qu'est ce qui est préférable, selon vous:question::
- De se dire que le cercle ou le carré ne sont que des "aberrations" (dans le sens de "particularités, voulues ou non, susceptibles de changer "à tout moment") des ellipses / rectangles
- De se dire que l'on donne le choix à l'utilisateur de placer un cercle ou une éclipse (un carré ou un rectangle), mais qu'il ne peut revenir sur sa décision par la suite
- de se dire que l'utilisateur peut placer une ellipse ou un rectangle et décider à n'importe quel moment de placer... ou retirer une restriction supplémentaire les faisant devenir cercle ou carré.
Le (3) me semble le plus approprié, mais il faut alors décider de la manière dont on organise la transition:
- Choisi-t-on de réduire le rayon / coté, pour le rectangle le plus grand à la taille du rayon / coté le plus petit :question:
- choisi-t-on d'agrandir le rayon /coté le plus petit à la taille du rayon / coté le plus grand :question:
- choisi-t-on d'adapter les deux tailles en fonction de l'espace utile disponible le plus grand possible entre les deux rayons /cotés :question:
- Pourrait-on envisager la mise au point de traits de politiques qui permettent au développeur avancé de choisir lui-même la réaction qui lui convient le mieux :question:
Citation:
- les polygones, qui sont une liste de points, engendrant un polygone, ou une suite d'arcs fermés
Là, par contre, cela peut poser problème...
Si l'on déplace un des angles, est-ce que les autres se déplacent en proportion dans les directions adéquates afin de "simplement" redimensionner l'objet, ou admet-on que l'utilisateur puisse "tout aussi simplement" décider d'écarter un seul angle où bon lui semble :question: (autrement dit, doit on se limiter aux polygones convexes, ou peut on envisager les polygones concave, voir croisés :question:)
D'une certaine manière, avec mon étoile à cinq branches, il semblerait que je milite pour permettre les polygones concave et / ou croisés :D
Citation:
Toutes ces surfaces ont une bordure (éventuellement transparente), et un intérieur (pareil)
(je ne fais pas de différence entre cercles et disques : un cercle, c'est un disque dont l'intérieur est transparent...)
Je partais du même principe pour les disques...
Pour ce qui est de la bordure, si je te comprend bien, on en revient au bipoint et à son épaisseur afin de pouvoir "jouer" avec :question:
Citation:
5- Pointage, souris, clavier
On a, en gros, deux types de dispositifs :
- des dispositifs "non pointants" (clavier, joystick, ...) qui envoient des messages à l'application toute entière (généralement à un composant actif, via une notion de "focus" géré au niveau de l'appli)
- des dispositifs pointants (souris, et autres), qui envoient des messages (généralement plus simples), et une information de position (éventuellement de mouvement, les "gestures"), l'IHM doit alors déterminer le récepteur de ce message...
En fait, toute la gestion "globale" de ces dispositifs se limite à deux notions :
- une notion de "focus" : composant d'interface qui recoit en ce moment, les messages du clavier
- une fonction permettant d'attribuer à chaque point de l'écran (ou de la zone "pointable" de celui ci, un élement d'interface qui recevra le message.
Au niveau des éléments, je pense qu'on devra définir un certain nombre de traits de base, correspondant aux interactions les plus fréquentes (clic souris, survol, bouton relaché/enfoncé, frappe d'une touche), et permettre la redéfinition d'évènements supplémentaires.
Rien à dire sur ce point (enfin, pour l'instant :aie:)