Re: [gtk-list] Re: Automatic generation of gtk+ interface

[Tim Janik <timj gtk org>]

On 3 Jul 1998, Tero Pulkkinen wrote:

> > > What data members should be used by users? (think of GtkFileSelection and
> > > buttons inside it -- users need access to it, but there's no way to determine
> > > if they're public or private or if you should be able to read value or
> > > set it on the fly etc..) Same situation is with many other widgets too...
> > >
> 
> Steve Hosgood <iisteve@iiweeble.swan.ac.uk> writes:
> > I'd like to make a sugestion here which will probably raise a storm of
> > protest. :-)  Tero's comments above about GtkFileSelection above illustrate
> > a point nicely.
> > 
> > Basically, I consider GTK+'s interface to be horribly non object-orientated
> > despite all its claims to be. Tero speaks above of wanting to determine
> > 'public' and 'private' members of the widget. This is surely a side effect
> > of widget implementers not being bothered to write their interfaces
> > properly. You should *never* expect to access a member of a widget's data
> > structure directly!
> 
> No, the structure *is* part of widget's public interface. It just becomes
> a problem when people put things to that structure which should be private.

in C you need to put every valuable bit of information into the widget
structure that is needed through a widgets lifetime.
in general people shouldn't access those data memebers, except when explicitely
stated and even then they should only read from the widget structure.
so modification of a widget structure's memebr should either happen through
the prototypes exported in the widgets header file, or through the object
argument mechanism. so regarding the ok and cancel buttons of the FS widget,
those should probably be exported as readonly arguments.

> (some widgets have it right, not all..) Having publicly accessable data members
> in publicly available structs is ok and completely with the OO rules, but
> there should not be state information available in there (or it should be
> marked as private).
> 
> > Why should I (as a user of GtkFileSelection) have to know that it contains
> > a struct member called "ok_button" or another called "cancel_button"?
> > Dammit - that might be true in version X of the code, but what if the writer
> > of GtkFileSelection decides to change it in version X+1? Everyone's code
> > breaks!
> 
> Oh, it is good thing that ok_button and cancel_button are available there
> as widgets. (Makes the interface of GtkFileSelection much larger without
> complexity accociated with it and still preserving encapsulation.)
> 
> All the private data however should be behind opaque data member that is
> not accessable anywhere else than in widget code. (for example if there's
> state information in the widget about its state, it should not be available
> in that structure...)

where else would you want to put that? if we introduce opaque data memebers
for everything needed in a widgets structure, gtk's *.c files will become an
ugly accumulation of type casts and unneccessary pointer indirections that
do not suit an actual purpose.

> > It might be harder work initially, but the writer of GtkFileSelection
> > *ought* to have provided access-functions or #defines to "wrap up" all
> > the functionality that a File_Selection box ought to provide.
> > 
> > I reckon that rather than saying:
> > 
> > 	gtk_signal_connect(GTK_OBJECT(GTK_FILE_SELECTION(fs)->ok_button), "clicked"....
> > 
> > ..the user ought to say:
> > 
> > 	gtk_signal_connect(GTK_OBJECT(fs), "OK-button-clicked",......
> 
> This does not work correctly. People will want to change color of the button
> and your interface just forbid that. => no good.

well for one, you can always control a widgets appearance through the rc system,
so something like

static const gchar *rc_string =
"style 'my-FS-button'"
"{"
"bg[SELECTED]='#ffffff'"
"}"
"widget_class '*GtkFileSelection*GtkButton' style 'my-FS-button'";

gtk_rc_parse_string (rc_string);

will change the buttons appearance. though this doesn't distinguish between
cancel and ok, that could be taken care off by assigning widget names to
the two buttons.

> GtkWidget*'s are perfectly ok inside publicly available
> structs... but, currently there's no information in it what interface
> you can expect from it. (people do "dynamic_cast" using
> GTK_BUTTON(fs->ok_button) and there's no information that you can use
> methods available for buttons in the structure. (Thats also one thing
> I'm thinking should be made more explicit => even though the resulting
> code could have it represented as GtkWidget* and not GtkButton*.)

this should be taken care off by supplying a read only object argument
"GtkFileSelection::ok_button" of type GTK_TYPE_BUTTON.

object arguments are meant to export those structure members that are
provided for public access.

> > After all, if you want to get the selected filename out of a
> > gtk_file_selection, you make a call to
> > "gtk_file_selection_get_filename", you don't go poking around inside
> > the widget. Why are the OK and Cancel buttons not similarly wrapped?
> 
> They are. Through those data members. => thats ok. No need to cut/paste
> the button's interface 3-10 times inside GtkFileSelection, just those
> 3-10 publicly accessable data members are fine.
> 
> > GtkCombo is another fine example. You have to go poking around at it's 'list'
> > and 'entry' widgets.
> 
> Thats ok too. Its part of widgets public interface.
> 
> > Admittedly, all these wrappers would make the .h files bigger, but
> > they don't make the eventual *code* any bigger, and they do make the
> > .h file become a better document on what exactly a widget can do
> > (thus solving Tero's problem).
> 
> This doesnt solve much. Better would be more explicit of what the types
> of the widgets are.
> 
> -- 
> -- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
> 

---
ciaoTJ