[Bf-funboard] Re: Toolbox Flash 2

[Thorsten Wilms]

On Sun, Nov 09, 2003 at 05:11:06PM +0100, GSR - FR wrote:
> 
> Have you tried doing a demo in which the menus open following the same
> dir than the parent? To check distance vs changing dir.

No, because opening submenus in same direction would enlarge the space 
the Toolbox needs, thereby increasing the propability that it and 
the mousecursor has to be relocated.

Do you, considering the above, think that to not change directions might
be better? Perhaps with autoscrolling submenus?

It's no problem to change the layout, but things like detecting 
collision with edges and autoscrolling could prove to be to difficult 
for my skills in combination with limited time.


> I have checked that it does not follow the rule about the triangle
> (opened menu, moved towards Add, got pointer around the h in Mesh,
> tried to select Icosphere, submenu vanished), but dunno if you avoided
> it to avoid coding it or what (I see you talked about handling menus
> near edges, but your flash does not).

With my layout, the mousepointer will always be closer to the submenu 
than it would be the case with normal pulldown menus. That is what I 
talked about, but might not have brought across clearly. Because 
of this, it seemed to be ok to have no delay or geometrical system.
Personaly, I have no problems, because I'm used to move the pointer 
in a hard bow (must be because of some bad menu implementations). 
Nobody complained until now.

But I'm very happy that you look into details. And I'm sure my design 
would be better with a geometrical system or maybe a delay.
I will look into this.

By the way, this lead me to the click-on-submenu-parent thing that's 
mentioned on my site and that I've implemented for the "Select" menu.
What do you think of it?


> For those that do not know:
> 
> +--------+
> |    1   |
> | _______|+-------+
> |*ItemA >||       |
> | \temB  ||       |
> | I\emC >||       |
> |   \    ||       |
> |    \ 2 ||       |
> |   1 \  ||       |
> |      \ ||       |
> |       \||       |
> |        |+-------+
> |        |
> 
> Start in mouse in *, thus with the ItemA submenu open. If the cursor
> moves over the area marked 2, submenu stays, cos it is considered the
> user is going to the submenu. If goes over area 1, others like ItemC
> will open, cos it is considered that user is trying to go to other
> menu items. The \ and _ are the imaginary border. The * could be over
> the "e" in ItemA, for example, and the border could be from there to
> the submenu corners, but that is just a small variation of the idea.
> 
> There are other variations in which, instead of a pure geometrical
> system, speed counts (move over area 2, but not too slow, ie), or
> angle. In feew words the trick is to provide a safe area to allow a
> direct path (the rest is tunning and implementation details).

Some might remember that I tried to visualize such a geometrical system 
by highlighting the save area. But it looked odd and distracting (and 
was ignored, it seems).


Thank you for your input. This is very welcome and a nice break from 
all the posts about not that important details like the Grabber
business :-)


---
Thorsten