Re: [Fenfire-dev] darcs patch

[Benja Fallenstein]

Tuukka Hastrup wrote:
> If we want to have the size of the fixed knob be something else than the 
> minimum size of the fraction knob, could we revert back to passing null 
> as the size model? Or would it be better to have some special value such 
> as NaN?

It would be better to have a method to set the min knob size model:

    private Lob middle() {
        Model min = Parameter.model(MIN_KNOB_SIZE, new FloatModel(15));
    }

    public void setMinKnobSize(Model value) {
        delegate.setTemplateParameter(MIN_KNOB_SIZE, value);
    }

> > Tuukka Hastrup wrote:
> >
> > > so now please tell what I did wrong :-)
> >
> > Actually, it's good except for ugliness of having the 
> > visibleFractionModel in ViewportLob, which is probably what you're 
> > referring to. 
>
> Actually, I don't know if it's that bad in the end. I don't understand
> Replaceables, Parameters, Templates, cloning etc. or why setSize is a
> sufficient place to update the model, but at least this was simple and
> introduced only one new object per viewport.

Mhm, it's simple but hackish to put special functionality for this into 
Viewport...

(The object count can not be an argument here, that would undermine the 
whole idea of the lob system -- to built complex things from simple 
parts -- and would be very premature optimization.)

> >     AssignedSizeGetterLob
> >              |
> >         ViewportLob
> >              |
> >    PreferredSizeGetterLob
> >              |
> >          (content)
> >
> > (I have a hard time coming up with good names for these, any 
> > improvements appreciated!)
>
> In theory, MinSize and MaxSize are needed as well.

Mhm, probably each of these should have models for min, nat *and* max.

> Would the naming 
> of these as Getters imply that the models be read-only?

Yes. The requested size of a lob isn't something you can *set*, in the 
sense of lob.setMinSize(axis, value) etc.

> RequestChangeLob 
> exists as the writable counterpart, and it never changes the model values.

It's kind of a counterpart, yes, but what it does isn't *setting* its 
content's requested size, exactly, it's creating a new lob which behaves 
like the content lob except that it has a different requested size...

Point being, it would not make sense to unify PreferredSizeGetterLob and 
RequestChangeLob into a single class.

> The name "RequestChangeLob" could easily be interpreted as a lob that
> requests changes instead of the lob that changes requests. Request isn't 
> even used in the names getNatSize etc. SizeRequestChangeLob? 
> NatSizeWatchLob or a general SizeRequestWatchLob?

Hmmm -- okay.

Thanks,
- Benja