On Sun, 3 Oct 1999, M. Uli Kusterer wrote:
> >It wouldn't be *very* hard, but there certainly are performance and
> >file-size issues associated with doing something like this. Part of
> >this problem has already been solved, as we've digested a list of
> >properties that could potentially be inherited which is returned by
> >the "properties" property in 2.3. But even that includes stuff that's
> >probably not useful (e.g., would you really want to be able to inherit
> >the rect of an object?)
>
> Scott,
>
> rects could be even more complicated. Imagine I'm porting a stack, and on
> the Mac a button's height is usually 20 pixels. On Unix, it's usually more
> like 30. Now I create a base button and inherit only its height. That would
> be cool :-)
I agree: inheriting the width or height independent from the rect
*would* be useful. But a nightmare to implement (or even understand).
This is a very good reason why the inheritance shouldn't be based on
built-in objects, but rather on either a true class system (which
requires some sort of #include capability) or on the creation of a new
class of object (e.g., the propertyBundle) that would make making the
distinction between changing the width and changing the rect
explicit. These property bundles would be attached to a stack, and
would never be visible. They'd be like scripts and would be built up
of some new object description language (maybe an XML derivative).
> >Right. But I'm still not really comfortable with this idea of
> >inheriting child objects in the same way that you can inherit scripts
> >or other properties.
>
> Maybe we could add a property to every object to turn that on/off? This
> mechanism could completely replace the current scheme of groups and
> backgrounds. Instead of having some strange concept about using groups as
> backgrounds, you simply place a group on a card, assign it your desired
> background as its master group and set a property in it that makes new
> cards automatically copy this group. It would become one common powerful
> concept, and so far it would even maintain backward compatibility.
But copying is not what's required: there needs to be a way to
maintain some sort of live linking between the template object and the
objects inheriting from it. And also being able to use the template
more than one place on a single card.
> >I'm starting to think that a script-only solution to this problem is
> >the way to go. For example, you'd create a group and tell it to
> >inherit from some other "template" object. The script of that
> >template object would look at the children of the new group, and make
> >whatever adjustments were required (adding controls, moving them
> >around, etc). Then it would set a timestamp (version number) on the
> >"derived" group. Then the user could make whatever changes would be
> >required to customize the new group. If they later change the
> >"template" group, it would use its timestamp to update the groups
> >derived from it as needed to reflect it's new configuration (hopefully
> >without screwing up the users changes to those customized derived
> >versions). This makes for a larger burden on the "template"
> >developer, but seems the only way to build in enough flexibility to
> >handle the wide range of things this might be used for.
>
> But it will certainly screw up users' modifications.
Why? The behavior is up to the scripts...
> If you add it to the
> engine, you can choose what to inherit and what not to. I think this is
> much more sensible. Users prefer if the engine only changes things they
> told it to. If they adjust something, they expect it to stay that way. If
> it needs to be adjusted later, then they can still do it manually, but at
> least their work isn't gone.
Right. But scripts could do this as easily as the engine could. And
with a lot more flexibility.
> >This doesn't really solve the problem of using the same group multiple
> >places on the same card, though, does it?
>
> What's the problem with that? Since you now have a concrete object
> standing in for your background on *every* card, you can keep the info
> about changes with this object. You don't have to tack it onto the card
> anymore internally.
I'm missing something here: something needs to be placed (maybe
multiple times) on each card, right? What is that thing?
Regards,
Scott
> Cheers,
> -- M. Uli Kusterer
>
> ------------------------------------------------------------
> http://www.weblayout.com/witness
> 'The Witnesses of TeachText are everywhere...'
>
> --- HELP SAVE HYPERCARD: ---
> Details at: http://www.hyperactivesw.com/SaveHC.html
> Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
>
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
