[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fenfire-dev] darcs patch

From: Benja Fallenstein
Subject: Re: [Fenfire-dev] darcs patch
Date: Wed, 15 Dec 2004 09:22:13 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041124)

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.)


(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.

- Benja

reply via email to

[Prev in Thread] Current Thread [Next in Thread]