[Fresco-devel] Kit switching (was: Re: A Graphic Dictionary)

OK, part II of my reply:-)

To get this straight: Thje dictionary as it is now is not up to the task I'm 
describing here. This is just an idea I had when programming the dictionary 
and which I lumped in with my original 'announcement' that it seems to be 
working fine. I should have spilt the original message up in two parts. Damn 
overenthusiasm;-)

Lets take a step back: What do we need to allow for runtime switching of Kits? 
We need views onto the SceneGraph at different 'levels' of abstraction (~= 
Kits?). We need a place to store those views and finally we need to integrate 
that in the Kits without too many changes if possible.Finally the system 
needs to be adaptable to an arbitrary number of Kits that the user might have 
installed and might want to switch the implementations of.

Once a dictionary is integrated into the kits for debugging purposes, it might 
be a good place to start and extend:-)

On Monday 06 January 2003 02:03, Stefan Seefeld wrote:
> That's an entirely different beast, and I *really* suggest we discuss that
> in a separate thread. I believe that worrying about individual graphics
> when switching kits (are you thinking about widget style changes etc. ?)
> is the wrong approach entirely. The scene graph for a widget in Motif
> style may be entirely unrelated to the scene graph for an equivalent
> OpenLook widget, so what exactly would you gain from the knowledge where
> a given scene graph chunk originates ?

The idea is that Graphic play several 'roles' at any given time.: At one level 
it is a button.  When you look closer the same Graphic that is a button on 
the WidgetKit 'level' is just a box arranging other Graphics to form the 
actual button on the LayoutKit level below. It still is the same Graphic, 
it's just the level at which you look at that Graphic that changed.

The dictionary keeps a list of such levels for each Graphic: The 'creator 
stack'. With a bit of work it could also hold a list of 'roles' (names), one 
for each level. This way you can find out that one Graphic is a "selector" on 
the abstract level of a "TasketKit" (not implemented, ask stefan about it if 
you want to know more;-), a "menu" on the level of the "WidgetKit" and a 
"box" on the level of the LayoutKit.

This solves at least the problem of finding out what a graphic is considered 
to be by the Kits involved in it's creation. We'd still need to store the 
followup-graphic(s) for each level so that we can walk the scenegraph at more 
then the Graphic-level we have encoded now..

<inserted part from earlier in the mail I'm replying to:>
> well, I can see your idea. But in practice this isn't really robust. First
> you'd need to use thread safe data, or at least use a dictionary per
> ServerContext to get meaningful results. Second don't forget that graphics
> are flyweights. They may be used in unexpected places, not necessarily
> related to your 'creator stack'.

I fail to see the point about having one dictionary per ServerContext: We do 
want a consistent user experience, so if a application uses the same Kit as 
another one and the user decides to switch the implementation of said kit, 
then all the widgets created with the old one should change. The dictionary 
should be reasonably threadsafe, using one creatorstack per thread. That's 
somewhat similar to the Tracer in Prague. Definitly enough for debugging 
purposes... 

As to the robustness: I'm very much worried about that, too. As I said 
earlier: The dictionary will suffice for the debugging tool it was written 
for as it is now. Some mayor efford needs to go into it to extend it to help 
with runtime switching of arbitrary Kits.

-- 
Gruss,
Tobias

------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
[email protected]                      So I installed Linux.
------------------------------------------------------------