GEGL conventions
This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| GEGL conventions | reasamp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org | 26 Oct 15:46 |
| GEGL conventions | Øyvind Kolås | 28 Oct 01:50 |
GEGL conventions
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?
- 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? When is the outer tag and when is it ?
- 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.
- Lastly, is there any reference/c header/source file which lists all the
API that is exposed to operations?
reasamp
GEGL conventions
On 10/26/06, reasamp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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 and when is it ?
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.
