1. RE: GTK & BSD
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
problems.
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.
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. 
-Ron T.
2. RE: GTK & BSD
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
3. RE: GTK & BSD
irv mullins wrote:
>
>
> > gtkfunction = sprintf("gtk_%s_get_type",{name})
> Actually, it should be "gdk_pixbuf_get_type" - my mistake.
Oops, that's what I meant. Slip of the finger. Still, I did a grep for
gdk_pixbuf_get_type on all the GTK/GDK API docs and found no mention of
it.
BTW, I tried changing PIXBUF to PIXLIB and it didn't seem to break
anything else. At least, I'm still getting the same gMessage as before.
-Ron T.
4. RE: GTK & BSD
Ron Tarrant wrote:
>
>
> irv mullins wrote:
> >
> >
> > > gtkfunction = sprintf("gtk_%s_get_type",{name})
>
> > Actually, it should be "gdk_pixbuf_get_type" - my mistake.
>
> Oops, that's what I meant. Slip of the finger. Still, I did a grep for
> gdk_pixbuf_get_type on all the GTK/GDK API docs and found no mention of
> it.
There are several things that aren't documented. You can find code
which uses that call, but no mention in the docs.
> BTW, I tried changing PIXBUF to PIXLIB and it didn't seem to break
> anything else. At least, I'm still getting the same gMessage as before.
>
You might just comment out the include of pixmap.e, until you get things
working. None of the demos need it, it's pretty rarely used, I think.
Regards,
Irv
5. RE: GTK & BSD
irv mullins wrote:
>
> You might just comment out the include of pixmap.e, until you get things
>
> working. None of the demos need it, it's pretty rarely used, I think.
Actually, I've had a modicum of success without doing that. I cloned
newGDK() in class.e as newPIXBUF() and changed the first sprintf
statement. It looks like this:
----------------------------------------
global function newPIXBUF (sequence name)
----------------------------------------
atom handle, id
sequence gdkfunction
gdkfunction = sprintf("gdk_%s_new",{name}) ------ changed
id = define_c_func(PIXLIB,gdkfunction,{},P)
if id = -1 then
error_halt("Invalid GDK object: " & name)
else
handle = c_func(id,{})
classes = append(classes,{id,handle,upper(name)})
end if
return handle
end function
Then in pixbuf.e (line #2) I changed the PIXBUF initialization to:
global constant PIXBUF = newPIXBUF("pixbuf")
After finally catching all the calls to func() and proc() so they all
have four args, I got window.exu to work.
I also tried unicode.exu and turtle.exu but ran into new problems (my
brain is a bit overloaded at the moment or I'd outline them). I'll keep
you posted.
-Ron T.
6. RE: GTK & BSD
Ron Tarrant wrote:
>
>
> irv mullins wrote:
> >
> > You might just comment out the include of pixmap.e, until you get things
> >
> > working. None of the demos need it, it's pretty rarely used, I think.
>
> Actually, I've had a modicum of success without doing that. I cloned
> newGDK() in class.e as newPIXBUF() and changed the first sprintf
> statement. It looks like this:
>
>
> ----------------------------------------
> global function newPIXBUF (sequence name)
> ----------------------------------------
> atom handle, id
> sequence gdkfunction
> gdkfunction = sprintf("gdk_%s_new",{name}) ------ changed
>
> id = define_c_func(PIXLIB,gdkfunction,{},P)
>
> if id = -1 then
> error_halt("Invalid GDK object: " & name)
> else
> handle = c_func(id,{})
> classes = append(classes,{id,handle,upper(name)})
> end if
> return handle
> end function
>
>
> Then in pixbuf.e (line #2) I changed the PIXBUF initialization to:
>
>
> global constant PIXBUF = newPIXBUF("pixbuf")
>
>
> After finally catching all the calls to func() and proc() so they all
> have four args, I got window.exu to work.
>
> I also tried unicode.exu and turtle.exu but ran into new problems (my
> brain is a bit overloaded at the moment or I'd outline them). I'll keep
> you posted.
Good. It seems that Linux is far more lax about some things (or, if
you prefer, handles them more intelligently :) than BSD, when it comes
to calls to shared libraries. GTK on Windows falls somewhere between the
two. I'll keep that in mind when (and if) I do another version.
Irv
7. RE: GTK & BSD
irv mullins wrote:
> Good. It seems that Linux is far more lax about some things (or, if
> you prefer, handles them more intelligently :)
Ah, a subtle dig at my favourite OS. Arr, matie! Avast!
But on the other hand, I think it's the 0.22.0 version of gdk-pixbuf
(the latest available for FreeBSD) that's at fault here. I ran a number
of the samples from the command line, and they all threw this message:
(<unknown>:2539): GdkPixbuf-CRITICAL **: file gdk-pixbuf.c: line 260
(gdk_pixbuf_new): assertion `bits_per_sample == 8' failed
The first part (<unknown>:2539) doesn't always have the same number and
I'm not sure yet what to make of that yet. The other interesting thing
about this error is that it claims to be a problem with line 260 of
gdk-pixbuf.c when in fact the error is thrown from line 170. Line 260 is
dead-smack in the middle of a multi-line comment. I'm still looking into
why 8 bits per sample is such a big deal for GDK.
And as for Linux, it _does_ get all the press which just means we BSDers
get to have more fun making things work. 
> than BSD, when it comes
> to calls to shared libraries. GTK on Windows falls somewhere between the
>
> two. I'll keep that in mind when (and if) I do another version.
Aw, don't give up on it just yet, Irv. There's always GTK 3, 4, 5 ...
Anyway, thanks for sharing the journey so far.
-Ron T.
8. RE: GTK & BSD
Ron Tarrant wrote:
>
>
> irv mullins wrote:
>
> > Good. It seems that Linux is far more lax about some things (or, if
> > you prefer, handles them more intelligently :)
>
> Ah, a subtle dig at my favourite OS. Arr, matie! Avast!
It depends, I guess, on whether being lax is unsafe or not.
Unfortunately, I don't know enough to be able to even guess about that.
> But on the other hand, I think it's the 0.22.0 version of gdk-pixbuf
> (the latest available for FreeBSD) that's at fault here. I ran a number
> of the samples from the command line, and they all threw this message:
>
> (<unknown>:2539): GdkPixbuf-CRITICAL **: file gdk-pixbuf.c: line 260
> (gdk_pixbuf_new): assertion `bits_per_sample == 8' failed
>
> The first part (<unknown>:2539) doesn't always have the same number and
> I'm not sure yet what to make of that yet. The other interesting thing
> about this error is that it claims to be a problem with line 260 of
> gdk-pixbuf.c when in fact the error is thrown from line 170. Line 260 is
> dead-smack in the middle of a multi-line comment. I'm still looking into
> why 8 bits per sample is such a big deal for GDK.
Perhaps the shared library doesn't match the source code.
As in: was compiled from a different version, or something was
changed after the compile?
...
> Aw, don't give up on it just yet, Irv. There's always GTK 3, 4, 5 ...
Actually, that's what worries me.
Irv
9. RE: GTK & BSD
irv mullins wrote:
> > > Good. It seems that Linux is far more lax about some things (or, if
> > > you prefer, handles them more intelligently :)
> It depends, I guess, on whether being lax is unsafe or not.
> Unfortunately, I don't know enough to be able to even guess about that.
Good point. The reasons I went with FreeBSD after trying various
flavours of Linux and, of course, MS Windows was for the stability, ease
of configuration and security. It only took me about two hours in 1998
to set up security on my FreeBSD firewall and I was pretty green in the
FreeBSD world at the time. Since then, I've upgraded the OS once, moved
the system drive around to four different machines and the only real
change I had to make was to tweak the security setup. That took about a
half-hour (including reading several man pages) and was only necessary
because of the OS upgrade.
> Perhaps the shared library doesn't match the source code.
> As in: was compiled from a different version, or something was
> changed after the compile?
Hmmm. I didn't think of that. I'll look into it. Thanks, Irv.
> > Aw, don't give up on it just yet, Irv. There's always GTK 3, 4, 5 ...
>
> Actually, that's what worries me.
Uh-huh. Another good point.
BTW, I've finished testing all of the samples you included with euGTK2
and here is a list of the ones that don't work on my system:
barchart.exu
buttonstyles.exu
calendar.exu
drawing_area.exu
entry.exu
eventtest.exu
combo.exu
pixmaptest.exu
psychedelic.exu
spectrum.exu
table.exu
tooltips.exu
treeview_fancy.exu
turtle.exu
unicode.exu
The problems all stem from four areas:
1) manipulating fonts,
2) drawing on a pixmap (at least I think that's what it is),
3) something to do with glist's,
4) and something subtle with gobject's
All the rest work fine except for spitting out that strange error I
mentioned in my previous message. I'll keep at it and see where it ends
up.
-Ron T.
10. RE: GTK & BSD
Ron Tarrant wrote:
...
> The problems all stem from four areas:
>
> 1) manipulating fonts,
> 2) drawing on a pixmap (at least I think that's what it is),
> 3) something to do with glist's,
> 4) and something subtle with gobject's
>
> All the rest work fine except for spitting out that strange error I
> mentioned in my previous message. I'll keep at it and see where it ends
> up.
Well, this helps to narrow down the problem.
It would be interesting to test these one at a time, with very simple
programs. For example, with fonts, I would try to determine if *all*
font calls fail, or just calls to use some particular font (which
might not exist or exists but can't be located).
Something like the following:
include gtk2/wrapper.e
constant fnt = font("Courier 16") -- experiment with this
atom win, lbl
win = window("Font Test")
lbl = label("This is a test")
set(lbl,"Font",fnt)
addto(win,lbl)
show(win)
main()
Regards,
Irv
11. RE: GTK & BSD
irv mullins wrote:
>
>
> posted by: irv mullins <irvm at ellijay.com>
>
> Ron Tarrant wrote:
> ...
>
> > The problems all stem from four areas:
> >
> > 1) manipulating fonts,
> > 2) drawing on a pixmap (at least I think that's what it is),
> > 3) something to do with glist's,
> > 4) and something subtle with gobject's
> >
> > All the rest work fine except for spitting out that strange error I
> > mentioned in my previous message. I'll keep at it and see where it ends
> > up.
>
> Well, this helps to narrow down the problem.
> It would be interesting to test these one at a time, with very simple
> programs.
I finally got it all working. As it turns out, some of the c_proc() and
c_func() calls were going to the GTK library rather than (for instance)
the GDK or GOBJ library. I'm still getting this error:
(<unknown>:9325): GdkPixbuf-CRITICAL **: file gdk-pixbuf.c: line 260
(gdk_pixbuf_new): assertion `bits_per_sample == 8' failed
but it doesn't seem to stop any of the euGTK stuff from working, so I'm
not going to worry about it for now.
Do you want me to send you a copy of this in case anyone else wants to
use it with FreeBSD? I'd also be interested to see if it still works
with Linux with these modifications.
-Ron T.
12. RE: GTK & BSD
Ron Tarrant wrote:
>
> I finally got it all working.
> As it turns out, some of the c_proc() and
> c_func() calls were going to the GTK library rather than (for instance)
> the GDK or GOBJ library.
Oops! The previous sentence should read:
As it turns out, some of the define_c_proc() and define_c_func() calls
were going to the GTK library rather than (for instance) the GDK or GOBJ
library.
> Do you want me to send you a copy of this in case anyone else wants to
> use it with FreeBSD? I'd also be interested to see if it still works
> with Linux with these modifications.
Additional:
All demos provided with euGTK now work properly under FreeBSD/GTK2.
-Ron T.
