>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 :-)
But I have to admit that this would probably be an implementation mess, so
I leave it to you to find a solution or drop it as unimplementable. Still,
there's always a reason to inherit even the rect. Of course, it could be
done in different ways: Inherit the actual rect with or without the loc, or
inherit its proportions.
With loc would be cool for things like help buttons, which are usually in a
standardized location throughout an application so users always know where
to get help.
w/o loc would be cool for e.g. dials implemented using icons so certain
positions can be hard-coded for better performance.
Proportions would mean I could create a button of size A4 (That's a
European paper size standard, sort of like US-letter) and by creating a
button that's 25% smaller based on the A4, I'd have A5. Now, if I want to
generate A6, I simply make the base part size A5. This might be a very
restricted use, but surely someone will work up the fantasy to find some
other use.
Maybe a game of cards, where you can enlarge the size of cards by resizing
the base object, thus making best use of screen estate.
>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.
>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. 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.
>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.
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
