Morph-M

Description:
----------------------------------------
Les débordements des fenêtres actives ne sont pas gérés de la même façon en
fonction du bord concerné. En 2D, avec les conventions usuelles, si la fenêtre
déborde à gauche ou en haut, elle est déplacée de façon à ce qu'elle rentre dans
l'image. Si elle déborde à droite ou en bas, elle est coupée.
Ce comportement, hérité de Xlim3D, garantit que la fenêtre active obtenue n'est
jamais vide.
Personnellement, je préférerais un mécanisme qui gère de la même façon les
différents bords. Je propose de toujous prendre l'intersection entre la fenêtre
active demandée et l'image (c'est à dire, toujours couper la fenêtre active).
Dans ce cas, un problème se pose lorsque l'intersection est vide. On pourrait
alors:
1) Ne rien faire (garder la fenêtre active précédente?) et rendre un RES en
conséquence;
2) avoir une fenêtre active vide ? Plus rigueureux, mais source potentielle de
problèmes pour les utilisateurs... (et je ne sais pas si cette éventualité
bizarre a été prévue par les autres fonctions, et en particulier par les
itérateurs).

#1 23/11/2007 11:25 (etienne)
---------------------------------------------------------------------------
Change: status: "pending" -> "accepted"
Change: assignees: "[]" -> "['morphmdev', 'raffi', 'Thomas', 'Tibs']"
Change: topic: "" -> "UI"
Change: importance: "medium" -> "low"
Change: title: "" -> "setActiveWindow() et gestion des débordements"
Change: classification: "Bug" -> "Feature"
Change: description: "" -> "Les débordements des fenêtres actives ne sont pas gérés de la même façon en fonction du bord concerné. En 2D, avec les conventions usuelles, si la fenêtre déborde à gauche ou en haut, elle est déplacée de façon à ce qu'elle rentre dans l'image. Si elle déborde à droite ou en bas, elle est coupée.

Ce comportement, hérité de Xlim3D, garantit que la fenêtre active obtenue n'est jamais vide.

Personnellement, je préférerais un mécanisme qui gère de la même façon les différents bords. Je propose de toujous prendre l'intersection entre la fenêtre active demandée et l'image (c'est à dire, toujours couper la fenêtre active).

Dans ce cas, un problème se pose lorsque l'intersection est vide. On pourrait alors:

1) Ne rien faire (garder la fenêtre active précédente?) et rendre un RES en conséquence;

2) avoir une fenêtre active vide ? Plus rigueureux, mais source potentielle de problèmes pour les utilisateurs... (et je ne sais pas si cette éventualité bizarre a été prévue par les autres fonctions, et en particulier par les itérateurs).

"