Hi Allen,
Allen Bierbaum wrote:
> I have been looking at the code for OSG::Image today and there seems to
> be some crufty code related to name and filename.
Yeah, quite possible. IIRC Image originally wasn't a FieldContainer and
so there was no (easy) way to use attachments on it.
> At first it looked like Image has a field called "name" that seems to be
> used to hold the filename of the image instead of a name describing the
> image. But then after looking at the image loader I found that it adds
> attachment fields for the filename and the full file path even though it
> still puts the full file path in the name field. The VRML writer seems
> to look for the attachment first and thens falls back on the name
> field. On the other hand the OSB field only looks at the name field.
Hm, this inconsistency is probably a side effect of Image's evolution.
How much clean-up can be done mainly depends on the amount of breakage
it would cause and we are willing to accept.
> So, I have a few questions:
>
> - Why isn't there a filename field for storing the name of the file?
> (this would allow the name field to be used to describe the image)
> - Why does the loader store the filename and full file path in attachments?
>
> In a perfect world I would think the code would have separate name and
> filename fields and that the filename would be a relative path from the
> file that the image is used within. That way when a loader loads a file
> it can find the image and load it. Or perhaps there could be a file
> search path that is used to find the file. This seems to be what
> PathHandler is for, but I don't know for sure.
I don't know the "official" word this, but my own opinion is:
For consistency, naming of objects should be done via the NameAttachment
whenever possible -- yes, for ContainerPool I recently suggested a name
field myself ;)
Likewise paths should be stored in an attachment as well, as there are
Images that do not correspond to files on disk (ImageGrabForeground
comes to mind). Likewise if an Image is used as part of a model (e.g. a
texture) it can hold the model's file path in its attachment.
ImageGenericAttachment is a DynFieldAttachment so you can add fields for
this type of information to it - there is even a convenience interface
in Image for this: setAttachmentField/findAttachmentField.
Cheers,
Carsten
PS: In 2 DynFieldAttachment is broken, hence ImageGenericAttachment can
not be really used ATM.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
