Re: [zzdev] Re: [zzdev] To do for article

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> On Wed, May 09, 2001 at 04:06:31AM +0200, B. Fallenstein wrote:
> > Tuomas Lukka wrote:
> > >
> > > Demos:
> > >         - file browser (Benja, Rauli)
> > >                 - should use JInternalFrame
> > >                   to make cooler-looking display
> >
> > I don't have a clue at what you want to do here (except if you want to
> > replace the panes by JInternalFrames, which would require re-writing
> > VobPanel COMPLETELY, as well as writing a new VobScene implementation,
> > because overlapping panes are nowhere near being possible at the moment).
> 
> We don't have to show anything overlapping.

Well, then it doesn't require anything new, but I feel it's cheating,
because if you see two windows you assume you can move them over each
other. When you see a split pane, you don't. Imagine someone sees the
video, they download the demo to try themselves, move the windows over
each other and get the clipping errors (i.e. stuff that shouldn't be
shown because the other window is above it is shown anyway). I don't
think this is worth the coolness effect.

> Does it need a complete reimplementation really? There's just one vobset
> there, isn't there?
> 
> Then you could probably just put the JInternalFrames inside one pane
> and just have the vob-placing views walk up the hierarchy to know their
> relative coordinates.

The problem is not the relative coordinates (they are computed from the
screen coordinates, so we don't even need to walk up in the hierarchy),
the problem is the overlapping. If we would put the JInternalFrames into
different panes of a JSplitPane, we wouldn't have too much of a problem,
but that wouldn't look very cool then.

> > >         - code to time an event stream and play back, writing
> > >           .ppm files
> > >           - must show mouse cursor, and also output sound track
> > >             clicks at the right times.
> >
> > The guidelines UIST refers to require that the video is real-time; is
> > the plan you describe ok in that case?
> 
> Hmmm... it's a borderline case.

I think at least we should make the snapshots in a separate thread,
using a timer.

> > >         - file browser (Benja, Rauli)
> > >                 - should be faster
> > 
> > What exactly needs to be faster until Friday? (Why does it need to be
> > faster? The browser runs fast enough on my system, if no BIG directories
> > are shown.)
> 
> Ok, I guess we just don't show the largest directories on my system.

That's ok, because what slows us down here are AFAIK the system calls (I
will benchmark, but I'm pretty sure).

> > Something else: The search function isn't implemented yet but should
> > today. (I'll take care of that.)
> 
> Ok. The important thing is to make something that is easily understood to
> be useful.

Yes.

- Benja