Re: [Fresco-devel] A Graphic Dictionary

Stefan Seefeld <[email protected]>
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
Tobias Hunger wrote:

> Downside: As this Dictionary is not exported via CORBA this dictionary is not 
> accessible for remote Graphics and cannot get queried by applications. It is 
> purely server internal.

I don't think that this is a drawback at all. We are talking about a debugging
tool, right ?

> So far I register a name for a graphic and a 'creator stack'.

I'm a bit worried as the most important thing doesn't seem to be clear:
what is this to be used for ? What's the scope of this 'debugging tool' ?

 From the discussions I remember, I thought of something even more simple
(and less intrusive): just store the servant type (typeid(...).name()) with
the pointer as its key and possibly proxy pointers that point to it.

The goal was (iirc) to be able to trace the real type of the object if you
have nothing but a Graphic_ptr.

> I orginally 
> thought such a stack would be useful for debugging... Here is how it works: 
> Let's assume we have a WidgetKit whos button-method returns an object 
> generated by the FigureKit. Entering the WidgetKit it pushes "WidgetKit" onto 
> the creator-stack and then requests a new Graphic from the FigureKit. That 
> pushes "FigureKit" onto the creator stack, generates a Graphic, and registers 
> it with the Dictionary, giving it a name and asking the Dictionary to set a 
> creator of "WidgetKit::FigureKit". "FigureKit" now gets poped from the stack 
> again and any additional Graphics created by the WidgetKit will just have 
> "WidgetKit" for their creator. So much for the theory...

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

This may sound like nit picking, but if you really want a generic debugging
tool to inspect server side graphics, you ought to be prepared for everything...


> it seems to work 
> fine, although with CORBA and multithreading going on I'm not so sure it will 
> work in all cases. As additional debugging info what I get now should be 
> fine:-)
> 
> What do you think about such a Dictionary? Is that a good thing to have?

As I said, I'd suggest you start outlining what exactly you want this to help
you with, i.e. some use cases would help to see where such graphic names
would help.

> I was wondering wether such a dictionary can be used to help with the 
> switching of Kits at runtime.

Ouch.

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 ?

You need to preserve more semantics than that...

Regards,
		Stefan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.