Re: Further gstreamermm wrapping

["Milosz Derezynski" <internalerror gmail com>]

There is one difference between the rest of the plugins as found in the -good, -bad and -ugly packages (and 3rd party plugins): Those are the base types which everything derives of.

The reason why it would make sense to explicitly wrap the core and base plugins (e.g. GstBaseSrc) is that then it would be possible to write wholly new elements (plugins) using our C++ binding; otherwise this would be not possible, not even with the code generator i'm working on, as this only wraps properties and signals, which is enough for normal elements as they usually don't expose specific API in the sense of methods, they only have own properties and signals to be attached to.

"Normal" here refers to anything that isn't a base for anything else. Derivation from specific elements isn't possible or needed either (and hence it's not neccessary to wrap all of them which would be a daunting task to keep up with, if possible at all), because they usually don't extend the object structure beyond what they've inherited from their base (e.g. GstGIOSrc only fulfills the GstBaseSrc API, but doesn't extend it).

-- Milosz

2008/3/21, Murray Cumming <murrayc murrayc com>:

On Thu, 2008-03-20 at 23:12 -0400, José Alburquerque wrote:
> José Alburquerque wrote:
> > Hi Murray.  I'm noticing that there are some things in gstreamer which

> > we haven't contemplated wrapping in gstreamermm yet and I was
> > wondering how we might go about this:
> >
> > 1) In the gstreamer source directory, besides the gst directory (which
> > we've mostly wrapped), there is a libs/gst directory with other
> > directories such as base, check, controller, etc. which are not
> > wrapped (the docs for these are at:
> > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/).


If these are useful for something then, yes, they should be wrapped. I
wouldn't bother creating extra directories for them, but you might want
to use doxygen groups in the documentation to group them together. For
instance, see the TreeView group in gtkmm.

But I wouldn't bother wrapping any of this until you have discovered
what an application might want to use it for, and can think of an
appropriate small example in C++.


> > 2) In the gstreamer source directory there's also a plugin directory
> > with other directories (namely elements and indexers) which are also
> > not wrapped (the docs for these are at:
> > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/).


I guess these are just standard plugins. Milosz is working on a way to
get access to specific API of elements (provided by plugins, I believe)
that are discovered at runtime (or expected to be discovered at
runtime). It's a code-generation tool for use by applications, I think,
roughly equivalent to how users of CORBA or COM generate code to use
APIs.


> > 3) The gstreamer gst-plugins-base module has a directory named
> > gst-libs/gst with items (including a few interfaces which I mentioned
> > in post:
> > http://mail.gnome.org/archives/gtkmm-list/2008-February/msg00201.html)
> > that may also be beneficial to wrap (the docs for these are found at:
> > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/).


Again, this seems to be plugins.


> > Finally,
> >
> > 4) The gst-plugins-base module also has directories named gst and ext
> > which contain gstreamer base plugins (the docs for these are at:
> > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/).
> > (I'm not sure that these should be wrapped, but I thought I should
> > include them in this list for completeness.)


Again.


> > What I'm trying to figure out is: would it be necessary to make
> > subdirectories in gstreamermm/gstreamer or in gstreamermm (the main
> > directory)?  I know that if the directories are created under the main
> > gstreamermm directory these would probably represent namespaces and
> > I'm not sure if I have to be precise in choosing good names and what
> > these names should be.  I thought that names could be as follows: for
> > 1) corelibs, for 2) coreplugins, for 3) baselibs and for 4)
> > baseplugins.  Are these names ok?  I'm thinking of adding these
> > directories so that what's necessary can also be wrapped.  Thanks.
> >

> I'm sorry.  With your permission, I'm reposting on gtkmm list in case
> others want to opine.
>

--
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com


_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list