[gst-devel] Header file restructuring needed

[Erik Walthinsen]

The work I'm doing on incremental schedule (BRANCH-INCSCHED1) is showing
me that we will need to do some restructuring of the header files at some
point in the relatively near future.  I can shim it for now with signals
(the signals I'm creating need to exist anyway, so no loss), but it'll get
messier and messier as things go.

The fundamental problem is that with the current header layout, a
GstElement can know about (i.e. use the definition of) a GstPad, but not
vice versa.  This is a problem with incsched because I need to get
callbacks into the scheduler from all sorts of events.  The simple ones
are the addition and removal of an element from a Bin, but I also have to
know when two pads are connected or disconnected.  This makes things
pretty messy when I have to attach to signals to catch the events.  Ick.

The quick-hack solution it to create a header file with all the typedefs
for all the objects, and make sure that's included up front in every file.
That gives us access to the right types, but not much else.

The real solution is to split all the object headers into private and
public headers.  The public header file would contain the typing macros,
typedefs, public enums, external helper macros, and function prototypes.
The real structure definitions and internal helper macros would be defined
in the private header.

One neat trick would be to put:

#ifndef __GST_H__
#warning Private GStreamer header included outside of libgst!
#endif

in each private header file.  If an application manages to include a
private header, they get a warning.  This will likely happen in a lot of
test programs within the distribution, but by definition can't happen in
outside apps because the private headers simply won't be installed <g>

The naming convention for these headers is still escaping me.  The header
names we have now must be used for the public headers, but the private
headers could be named in any of several ways:

gstpad.ph
gstpad.hp
gstpad_p.h
gstpad_private.h
etc...

I know they guys at RidgeRun will vote for the .hp extension..., but I'm
not sure which I prefer, except to say that _private is IMO too long.
gstelementfactory_private.h.... ick.

Anyway, that's gonna have to happen soon.  If someone wants to go and do
it, send out a unidiff for me to check, and either check it in or have me
check it in.

TTYL,
    Omega

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_