BTW, another file which contains lots of implementations that could be auto-generated is gtkfilechooser.inc. As far as I can see, only get_filenames(), get_uris(), list_filters(), list_shortcut_folders() and list_shortcut_folder_uris() need explicit implementations.

On Sun, 18 Dec 2005, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

BTW, another file which contains lots of implementations that could be auto-generated is gtkfilechooser.inc. As far as I can see, only get_filenames(), get_uris(), list_filters(), list_shortcut_folders() and list_shortcut_folder_uris() need explicit implementations.

Okay, the reason why that is done like that is because gtkfilechooser.inc is a gtk2 interface. I implemented all the gtk2 interfaces as .inc files.

The classes that use the interfaces have to be cast to the interface type for the function to work, otherwise the function doesn't think the class has the appropriate function (compare with c++ vtables).

I actually had it originally like that, but nothing worked properly until I manually put in the function bodies and had the appropriate casts.

All the .inc files should be like this. If not, the functions that aren't probably won't work.

lance

Featurerequest:

In support.c we currently PIKE_IMPORT to get image_program from the Image module. This is done so that the image storage can be indexed directly on xsize and ysize, instead of calling these methods from the object.

I did however notice that gdkbitmap.pre does apply(o,"xsize",0); get_all_args("internal",1,"%i",&x); pop_stack(); apply(o,"ysize",0); get_all_args("internal",1,"%i",&y); pop_stack(); so I would like to generalize the import of image_program by moving the PIKE_IMPORT call to INIT. But I don't think there is any mechanism for adding code to INIT, so that would be the feature request...

I assume from other messages that PIKE_MODULE_IMPORT() can't be done in PIKE_MODULE_INIT, but can be done in the init callback, correct?

No, PIKE_MODULE_IMPORT sits just fine in PIKE_MODULE_INIT.

It was just me showing my ignorance for how the whole system works. Previously the type GtkHscrollbar* was generated, which doesn't exist in my gtk, so the compilation failed.

On Sun, 18 Dec 2005, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

I see. So if the auto-generator is used, it would insert e.g. GTK_FILE_CHOOSER_DIALOG(x) instead of GTK_FILE_CHOOSER(x), because all it knows is that it has seen "class GTK2.FileChooserDialog;". I suppose to fix this we can introduce a new keyword "interface" to the auto-generator, so you can say "interface GTK2.FileChooser;" in the .inc file.

Yes, exactly.

Of course, the best way would be to make the interfaces into real Pike classes, so you could use multiple inheritance instead of includes. This would also allow you to use "GTK2.FileChooser" as an abstract type in your Pike applications. Hmm. Let me see what I can whip up.

I originally tried to use multiple inheritance, but the auto-generator (build_pgtk.pike) isn't written with multiple inheritance in mind. It checks for circular dependencies and stuff, and trying to hack it to allow multiple inheritance was turning into a major undertaking. Just creating the .inc file structure was a compromise.

Multiple inheritance would be great, and an interface keyword would be a good second choice..

I converted the gtkfilechooser interface to demonstrate the use.

That reduced the filesize by 1.1% Not bad.

There might be a problem with the new mixins. I took for example GTK2.FileChooser->get_preview_widget(). The source generated now is:

void pgtk_file_chooser_get_preview_widget(INT32 args) { pgtk_verify_inited(); { GtkWidget *a1; a1 = (GtkWidget *) gtk_file_chooser_get_preview_widget(GTK_FILE_CHOOSER(THIS->obj)); my_pop_n_elems(args); push_gobjectclass(a1,pgtk_widget_program); } }

The original had:

push_gobject(a1);

Now, the old function call actually got changed to:

push_gobjectclass(a1,pgtk_type_to_program(a1));

which would push the correct object type, be it GTK2.Label, GTK2.Image, or whatever.

Now, push_gobjectclass(a1,pgtk_widget_program) only pushes it as a pgtk_widget_program, which isn't the correct type.

Basically, functions that return a GTK2.Widget need to return the actual object type, not just a pgtk_widget_program. Maybe build_pgtk.pike (or the output/ files) should be changed to generated push_gobjectclass(a1,pgtk_type_to_program(a1)) for any function the returns a GTK2.Widget (or actually, any GTK2 object type).

Now, I know this because I did it that way originally (by letting build_pgtk.pike generate the code for those functions itself), but then I realized that the object that got returned wasn't what I wanted. My pike code after that couldn't call any of the functions for the proper object, because it was just a GTK2.Widget).

Not really, since it does not return an object of type this_program...

On Tue, 2006-01-03 at 10:10 +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

That's not related to the mixins, but simply to the fact that if you declare something as returning "GTK.Widget", you'll get a GTK.Widget. One solution would be to extend the syntax to allow i.e. "GTK.Widget+" as a return type, meaning that subclasses may be returned as well. Or we could simply use push_gobject() always, I don't know if there are any compelling performance reasons to ever use push_gobjectclass(), and risk this type of problem...

I think extending to GTK2.Widget+ would be better. Some classes don't work with push_gobject, such as GTK2.TextIter. Those have to use push_gobjectclass(), because either push_gobject() gets it wrong, or I believe because GtkTextIter is not a gtk object, but a structure that I implemented as an object, so it doesn't get identified in pgtk_type_to_program().