[Bf-funboard] Re: (Guillermo) Toolbox speed

[Thorsten Wilms]

On Sun, Nov 09, 2003 at 07:41:01PM +0100, GSR - FR wrote:
> t_w_@freenet.de (2003-11-09 at 1809.35 +0100):
> > Autoscroll. Like, when a submenu is partly outside the screen, 
> > it's contents are scrolled when the user aproaches the edge?
> 
> Yes, in some cases, or moves all the menu widgets (parents and all) in
> the oposite direction, like NeXT. For example, GTK drop down creates a
> rectangle as big as all the menu items (visual hint), but puts the
> active under cursor, and slides the inner part back into the
> "container". Example, with a window that is near bottom of screen:
> http://www.infernal-iceberg.com/blender/gtk-menu-out-of-screen-clip.png

I don't think scrolling single submenus will work nicely.
But I very much like the idea of moving the whole menu in the oposite 
direction.

Do you have any links that go into detail about NeXT GUI innovations?
 
> > Would have visibility problems (hidden menu items).
> > Do you know of any comparison between the 2 solutions? 
> 
> Yes, it hides things. OTOH, if items do not change position and the
> list is small, your muscle memory should work fine. So the issue is
> for learning if it is always that way, afterwards I doubt it slows
> down much (sorry, no stats). Personally (sample size: 1) I go fine
> with the selector above, you can not see them all, like you can not
> see them when you have not clicked yet, but I do not have to scroll
> all and read them all, I know where is the one I want, approximately.

Things shouldn't change position. You can see how small or large the  
lists are. Nobody will use the Toolbox close to the edges all the time, 
therefore it shouldn't be a problem.


Thanks again for you input.

---
Thorsten