OpenEuphoria

RE: GTK & BSD

• Posted by irv mullins <irvm at ellijay.com> May 12, 2004
• 588 views

Ron Tarrant wrote:
> 
> irv mullins wrote:
> > 
> > Has anyone gotten EuGTK to work with FreeBSD?
> 
> Thanks for posting this, Irv. When I didn't see any replies after the 
> first day, I started hacking the eugtk2 code.
> 
> I've managed to eliminate the first gMessage error I mentioned to you 
> (Invalid function: g_object_ref) and all its bretheren who followed. 
> This error was spit out by gMessage whenever a call was made to either 
> func() or proc() in method.e.
> 
> To solve this, I added an arguement ('which_lib' in an attempt to follow 
> your naming conventions) to each of these functions to ID the library 
> from which the function (ie. g_object_ref) was being called. I then went 
> through each eugtk2 include file and used the library identifier 
> constants (as declared in wrapper.e) in each call to func() and proc(). 
> For internal eugtk2 calls I simply used an empty string to maintain the 
> argument count. Not an elegant solution, I know, but this process got 
> eugtk2 through a vast amount of the initialization code without 
> problem.

Good thinking, it will probably make finding errors easier.

> Now I'm on to the next gMessage error: "Invalid GDK object: pixbuf"
> 
> This seems to be happening during a call to the function newClass() in 
> class.e. The statement:
> 
>       gtkfunction = sprintf("gtk_%s_get_type",{name})
> 
> builds a function call to gtk_pixbuf_get_type which I can't find in the 
> GDK or GDK Pixbuf APIs. I'm thinking it should actually be 
> gdk_pixbuf_new if the pixbuf is being created in memory or 
> gdk_pixbuf_new_from_file if a file is being loaded. Either way, my next 
> move is to try massaging the newClass() function in an attempt to bend 
> things to my evil way.

Actually, it should be "gdk_pixbuf_get_type" - my mistake.

> But, there is one thing I don't understand. In wrapper.e one of the 
> global constants for library access is named PIXBUF. In pixbuf.e there 
> is another global constant named PIXBUF that (I believe) is a handle for 
> the pixbuf created during initialization. Aren't these in conflict?
> 
> wrapper.e includes controls.e which in turn includes pixbuf.e so they 
> both exist at the same time in the same namespace, don't they? Or am I 
> missing something?
> 
> Colour me confused, please, and you can do it in a pixbuf. 

Ok, that one I don't understand either. It's an error on my part, but
I would have thought that two globals of the same name would produce 
some kind of warning, but I've never gotten one. 
I'll change the global in wrapper.e to PIXLIB, and see what happens.

Regards,
Irv