[sugar] taskframe and activity resizing

[Erik Blankinship]

On 9/7/06, Dan Williams <dcbw at redhat.com> wrote:
> On Thu, 2006-09-07 at 20:26 -0400, Erik Blankinship wrote:
> > On 9/7/06, Marco Pesenti Gritti <mpg at redhat.com> wrote:
> > > Erik Blankinship wrote:
> > > > Right now, when toggling the taskframe on/off (F5), activities' edges
> > > > are covered up.
> > > >
> > > > Is this the default behavior, or should we write our apps to
> > > > dynamically resize to the new available screen real estate?
> > >
> > > No, that is the intended behavior. Activities should just take the whole
> > > screen.
> > >
> > > > Will the
> > > > taskframe's dis/appearance be animated at some point?
> > >
> > > Yes, it will. I hope to have more informations about the visual design soon.
> > >
> > > > Regardless, what event do we listen for to know when the taskframe's
> > > > appearance is toggled?
> > >
> > > What is the use case for this?
> >
> > I  would like to know which activity pixels are displayed and which are not.
>
> Because...?

Maybe I would like to move some visual information, or the child's
attention, to other parts of the activity if the taskframe is
displayed?  For example, I might want to highlight draggable icons
that can be moved to the taskframe when the taskframe is visible (or
maybe I want to make the task frame appear if one of those icons is
selected).

Or maybe I am designing a whack-a-mole game and need to know if moles
should only pop up from the visible holes.

Or maybe I am designing a tamagotchi who reacts to what a child is
doing on the taskframe and where that activity is taking place.

> > Appearance of the taskframe might also impact intercepting
> > mouse-events, or, dragging to/from the taskframe.
>
> That's kind of the point...  the frame has to intercept mouse events to
> be able to do what it does.

What is the drag-and-drop model for activities to work with the taskframe?