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