Re: How private are private GTK+ data structures

[Havoc Pennington <hp redhat com>]

Jag <agrajag linuxpower org> writes:
> I've working on a program and have found myself needing to access a few
> pieces of data that the gtk-docs say that programmers shouldn't directly
> access.  Unfortunately, I don't see any other way in the API to easily
> get the information I need. (noteably, I'm looking at rows in GtkCList
> to see if a CList is empty or not, and max_position in GtkPaned to see
> what possible positions are for me to use in gtk_paned_set_position)
>
> As a developer, this sort of leaves me between a rock and a hard place..
> to just forget about this new feature I want due to not being able to
> access the data, or go ahead and read the data, but risk having my
> programs break with future versions of GTK+.
>
> Is there anything else I can do in this situation?  I'd be willing to
> send in patches against GTK+ to provide the functions I need, but I have
> no idea how frozen the API is.  Am I reading to much into the part of
> the docs that say not to use them, in that they mean its safe to read
> the data, but not to modify it?

Your programs will already break a little bit with future GTK
versions, so there's no need to be super-paranoid about avoiding
it. Any upgrade to a future GTK will require some work, but you aren't
ever forced to upgrade, you can always keep using 1.2 as long as you
want.

I would make sure you encapsulate any use of private data in a nice
function so the code is only in one place and can easily be fixed
later; send a patch against CVS GTK or GTK 1.3.2 adding the
functionality for future versions (the API is frozen for 1.2.x, but
not for future versions); and if your code breaks or doesn't work due
to use of private data, don't expect too much sympathy. ;-)

Basically use of private data is totally unsupported and a bit
fragile, since private data can change or get deallocated or mean
something other than what you expected, and we won't feel guilty.
It is even possible that the behavior of private data could change
slightly in the stable bugfix series (1.2.x), though fairly unlikely,
and the change will always be binary compatible.

Havoc