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

[Tero Pulkkinen <terop students cc tut fi>]

> > 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.
(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...)

> 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.

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*.)

> 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 --