Frame Decision (was [sugar] OLPC priorities for Sugar in the August release)

[Neil Graham]

On Saturday 17 May 2008 5:26:06 pm John R.Hogerhuis wrote:
> One possible idea: rather than popping up the frame when near the edge, pop
> up a translucent overlay in key places that looks just like the keyboard
> frame key. If the user clicks on it, then bring up the whole frame.

I had been pondering if that could be done as a solution also but to do 
something like that would require somethink like a compositing WM. I have a 
vague feeling it could be done with some low level geode hacking, but a 
simple overlay is tricky because it's the size of the screen with a hole in 
the middle.  I wouldn't actually be opposed to the frame being some sort of 
special class citizen with specific driver support myself since it's a single 
unique and integral component (much like the mouse pointer being a hardware 
sprite).  Of course The person who would have to implement this would 
probably be spitting tacks at the thought of it :-)

A concern for me is the redraw required as the frame retracts.  On 
particularly heavy load windows the redraw can take some time. If the repaint 
on frame retract  could be avoided(by overlay or even a clever save-under 
scheme) then that would be a benefit.

It would also allow a solution by where the time it takes for the frame to 
retract is decided as proportional to how long the pointer has been in a 
trigger-zone. so if you just bang the mouse into the corner and away again 
(something my daughter does all the time) The frame starts to appear but 
disappears just as quickly.