File nodes hide their children because in-memory editing of the
children is ill-defined; if you change the children of a File node, are
you changing only the in-memory representation or are you really
changing the contents of the file on disk? If you're just changing
them in memory, what happens when the user presses "Save", do they lose
their changes (very bad!)? If you're really changing the file on disk,
the user can construct scenes in memory that are impossible to write
out correctly (if a node is a child of two different File nodes, in
which file should it be DEF'ed when the scene is written out?).
As for workarounds, you could implement your own nodes with whatever
functionality you like; some interesting ones might be:
GlobalReference {
name "Joe"
}
GlobalReference would be a Group subclass that just looked for the last
node given the name 'Joe' and made that it's child. It would be
different from USE in that it would look in a global naming dictionary
which would not be restricted to nodes DEF'ed in the current file
(Inventor has SoNode::getByName() to support this).
Or:
FilePart {
filename "Foo.vrml"
objectname Joe
}
... which would add object named "Joe" in "Foo.vrml" as a child node.
The implementation could optimize things so that "Foo.vrml" was read
only once and stored somewhere in case you used several objects from
it.
By the way, Inventor has done pretty well without these, and I think
VRML will do just fine without them, too. If you want a library of
materials, the easy workaround is to create a directory with each
material in its own VRML file and then just use:
DEF Gold WWWInline {
name "http://www.gavin.com/myMaterials/Gold.vrml"
}
(Side note: I like the names WWWInline and WWWAnchor for the nodes I
was calling WWWFile and WWWButton before).