Re: Steps to get to GTK+ 3.0
- From: Tim Janik <timj imendio com>
- To: Alberto Mardegan <mardy users sourceforge net>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Steps to get to GTK+ 3.0
- Date: Tue, 3 Jun 2008 14:23:57 +0200 (CEST)
On Tue, 3 Jun 2008, Alberto Mardegan wrote:
ext Kristian Rietveld wrote:
10. Remove all structure fields from the public API. There are two ways
this can be done:
a) Move object structures to private headers.
b) Move object structures to the local C file, the rest of GTK+ will then
also have to use accessors.
If you go for (a), will the private headers be installed in the target
system?
No, definitely not. "private headers" here means "internal", in that they'll
be accessible only from within the Gtk+ source tree during the gdk and gtk
library builds.
I've often felt that subclassing a GTK+ widget to modify its
functionality is usually harder than creating a new widget from scratch
(copying from the GTK+ code), as accessing the parent private members is
impossible, and many members that could be useful for a derived class
are in the private struct.
I like the Python way of doing it (by mangling the members name you want
to protect, so the client must really know what he's doing when
accessing it); I would find it useful if private GTK+ were private but
somehow accessible (at least from derived classes).
This would essentially make the fields part of our (semi-)public API,
and that in turn means we need to preserve their behaviour compatibly.
This is something we cannot provide and which gets us into much trouble
currently when we try to fix bugs or optimize/improve the current code
base.
However, if instead the public API is defined only in terms of function
entry points (object properties and signals are essentially provided via
functions as well):
- We can add compatibility code to those functions to emulate old
behaviour on top of a changed code base.
- We can establish a clear migration procedure for any particular feature
by adding new functions and deprecating old ones.
- We can provide compile time and runtime warnings for deprecated
functions to aid developers in migration.
Ciao,
Alberto
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]