[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] View change
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] View change
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Sun, 12 Nov 2000 13:57:48 +0200 (EET)
- Cc: Tuomas Lukka <lukka@xxxxxxxxxx>, zzdev@xxxxxxxxxx
- In-reply-to: <3A0E83C7.EFD85BEC@xxxxxx>
On Sun, 12 Nov 2000, Benjamin Fallenstein wrote:
> Tuomas Lukka schrieb:
> >
> > On Fri, 10 Nov 2000, Benjamin Fallenstein wrote:
> >
> > >
> > > I wrote:
> > > > (Would mean cell views would need to be able to construct flobs given
> > > > visual center & dimensions, instead of UL corner & dimensions. But that
> > > > *does* make sense for many views.)
> > >
> > > More to the point, both makeFlob and placeFlob should take two
> > > "alignment" integers specifying where the x/y coordinate is in the flob.
> > > 0 means visual center, -1 means left/top, +1 means right/bottom.
> >
> > Doesn't placeflob do just this?
>
> No. It doesn't layout from the "visual center," and it doesn't take
> sizes. Have a look at the methods I added to the CellFlobFactories and
> how I use them in the now-half-working-though-crashing-and-awfully-slow
> EnumVanishingView and you'll see what I mean (probably ;o}).
We should probably rethink FlobFactories entirely
(as an aside, an answer to your earlier question that I hadn't time to
reply then: they currently only produce cells but they could easily also
produce more complicated objects, whose handle is the cell), because they
need to be
- flexible and easy to use by views
- efficient
- simple to write (i.e. implementing as few methods as possible)
Tuomas