On 10/26/06, reasamp@xxxxxxxxx <reasamp@xxxxxxxxx> wrote:
Hi
I just joined the other day, and right now I am taking the time to get used
to various parts of the library. Since the documentation is limited so far I
decided to post here to clear up some small confusions about some library
conventions:
- The 'ID': Can this be used as a string pad to each and every operation?
You know, so that it can be cloned/otherwise referred later somewhere else?
The clones.xml shows it being used on the 'load' operation, but I failed to
use it on other operations. If it's possible, how? If not, how do I refer to
results of other operations?
No parts of the GEGL API are considered stable or final. The ids are
only used for clones in the XML parsing stage, the rest of referencing
between nodes in the tree is done implicitly through the tree
structure. XML is not capable of expressing arbitrary graphs you'd
have to use the C api to do that at the moment.
- Is the XML format used in the examples considered to be within the scope
of the library? That is, ... is it an 'official' part of the library, or
just here for debugging, perhaps to be moved into a separate distinct
library later on?
The answer to these questions is not known but some future incarnation
of the XML parsing might be native to use within the library, for
external use, for parsing OpenRaster, open document based structured
raster graphics interchange documents, for serialization for
distributed RPC in the network, or some other purpose, the only thing
that is certain is that you should not rely on it behaving like it
does now in the future.
When is the outer tag <gegl> and when is it <image>?
They are synonyms at the moment, currently it is used as a distinction
between GEGL documents and OpenRaster experiments.
- The docs show many operations accepting 'input' 'output' 'aux' pads of
object type. Now do they all have a maximum of three 'object' inputs? I am
asking this because of the particular way in which they have to be specified
in the XML examples in doc.
The XML only enables an interface to a subset of what is possible with
GEGL, but it is probably the most useful subset.
- Lastly, is there any reference/c header/source file which lists all the
API that is exposed to operations?
API stabilization for operation plug-ins will happen after the public
api for applications/language bindings embedding GEGL is settled
and even decisions about this has barely started.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
