Re: appearances are behaving strangely

[slevy]

> Try this:
> Load a colored object (eg cube.off)
> Load a non-colored object (eg dodec.off)
> Change the color of the faces in the world.  Both objects will now
> appear as the selected color
> Save the world as a geom
> 
> Restart geomview
> Load in the file you saved
> The non-colored object will have retained the color it was given, but
> the colored object will have reverted back to whatever the original
> data file specified.
> 
> If this is actually a feature, I think it is totally counterintuitive.
> If something appears one way and you save it, it's reasonable to
> expect it to appear the same way when you load it back in.
> 
> -Celeste

Argh!  This happens because (a) geomview appearance settings use the
"override" feature, but (b) overrides are carefully removed from saved
appearances to make it possible to save an object, then reload it, and
still be able to change its appearance.

Maybe we can fix this -- and improve the way geomview deals with appearances
generally -- as follows.

Rather than using overrides to impose appearances, let's just scan the
OOGL tree below the point the appearance is being added.  Wherever there's
an appearance with a conflicting setting, just remove it -- invalidate
the conflicting setting (but retain the rest of the appearance).  Do this
regardless of whether the conflicting appearance was created with a geomview
control or was loaded as part of the original object.

This will more closely approximate the "ideal" case where appearances
are applied on only one level, i.e. toggling anything is always effective.
It obviates the need to carefully edit appearances when saving objects.

It also behaves sensibly if we go to hierarchies of more than one level.

On the other hand, it can destroy information -- if you load an object
with an appearance embedded in it, then use the controls to change something,
the original setting is lost.  I think this is still better than the current
setup, though.

Comments?  If nobody comes up with a better scheme or objects too violently,
I'll do this.

   Stuart