ANN: pure-gtk 0.1

[Albert Graef]

Grab it here:
http://pure-lang.googlecode.com/files/pure-gtk-0.1.tar.gz

pure-gtk is a collection of bindings to use the GTK+ GUI toolkit version
2.x with Pure, see http://www.gtk.org. The bindings include the gtk
(+gdk), glib, atk, cairo and pango libraries, each in their own Pure module.

At present these are just straight 1-1 wrappers of the C libraries,
created with pure-gen. So they still lack some convenience, but they are
perfectly usable already, and a higher-level API for accessing all the
functionality will hopefully become available in time. In fact *you* can
help make that happen. :) So please let me know if you'd like to give a
helping hand in improving pure-gtk.

See examples/hello.pure in the source for a basic example. The files
uiexample.pure and uiexample.glade show how to run a GUI created with
the Glade interface builder.

Note that if your version of GTK+ and/or the support libraries differs
widely from what I have then you may have to regenerate the headers with
pure-gen ('make generate' does this). I've created this version with
GTK+ 2.14.4 on SUSE 11.1.

Enjoy :)
Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag

[Ryan Schmidt]

On Feb 20, 2009, at 06:57, Albert Graef wrote:

> Grab it here:
> http://pure-lang.googlecode.com/files/pure-gtk-0.1.tar.gz

I added this to MacPorts.

It was a little more involved than the other pure modules, because in
every .c file in pure-gtk, there is a #include referencing an
absolute path beginning with /usr/include, but that is not where
MacPorts installs the files, so I had to replace that path in each file.

[Albert Graef]

Ryan Schmidt wrote:
> I added this to MacPorts.

Thanks. :)

> It was a little more involved than the other pure modules, because in
> every .c file in pure-gtk, there is a #include referencing an
> absolute path beginning with /usr/include, but that is not where
> MacPorts installs the files, so I had to replace that path in each file.

Yes, that #include is generated by pure-gen, so it's hard-coded and can
only be changed by regenerating the bindings. (Which needs pure-gen. But
you'll probably have to do that anyway if your GTK version differs too
much from the version with which the distributed bindings were
generated.) I'm open to suggestions there.

[Albert Graef]

Albert Graef wrote:

> Ryan Schmidt wrote:
>> It was a little more involved than the other pure modules, because in
>> every .c file in pure-gtk, there is a #include referencing an
>> absolute path beginning with /usr/include, but that is not where
>> MacPorts installs the files, so I had to replace that path in each file.
>
> Yes, that #include is generated by pure-gen, so it's hard-coded and can
> only be changed by regenerating the bindings. (Which needs pure-gen. But
> you'll probably have to do that anyway if your GTK version differs too
> much from the version with which the distributed bindings were
> generated.) I'm open to suggestions there.

Ryan, I think I fixed this now. Can you please have a look at r945 and
see whether it compiles for you?

[Ryan Schmidt]

On Feb 22, 2009, at 19:28, Albert Graef wrote:
> Albert Graef wrote:
>> Ryan Schmidt wrote:
>>> It was a little more involved than the other pure modules,
>>> because in
>>> every .c file in pure-gtk, there is a #include referencing an
>>> absolute path beginning with /usr/include, but that is not where
>>> MacPorts installs the files, so I had to replace that path in
>>> each file.
>>
>> Yes, that #include is generated by pure-gen, so it's hard-coded
>> and can
>> only be changed by regenerating the bindings. (Which needs pure-
>> gen. But
>> you'll probably have to do that anyway if your GTK version differs
>> too
>> much from the version with which the distributed bindings were
>> generated.) I'm open to suggestions there.
>
> Ryan, I think I fixed this now. Can you please have a look at r945 and
> see whether it compiles for you?

Yes, revision 945 does it! Thanks. I changed the MacPorts port to use
that fix.

I note that the .pure files still contain the old absolute paths, but
only in a comment, so that doesn't affect anything.

Now, I noticed when trying to run the hello.pure example, it tries to
use pure-ffi:

$ pure -x /mp/share/examples/pure-gtk/hello.pure
/mp/share/examples/pure-gtk/hello.pure, line 6: ffi.pure: No such
file or directory
/mp/share/examples/pure-gtk/hello.pure, line 15: unknown namespace 'gtk'
/mp/share/examples/pure-gtk/hello.pure, line 19: unknown namespace
'glib'
[snip]

Is pure-ffi required for pure-gtk in general or only for the
examples? I'm trying to decide if I should declare the pure-ffi port
as a dependency of the pure-gtk port.

[Albert Graef]

Ryan Schmidt wrote:
> Yes, revision 945 does it! Thanks. I changed the MacPorts port to use
> that fix.

Thanks. I'll do a new pure-gtk release as soon as I get around fixing
another issue on SUSE 10.3 reported by Toni.

> I note that the .pure files still contain the old absolute paths, but
> only in a comment, so that doesn't affect anything.

Yeah, I only bothered to fix up the real code, not the comments. ;-)

> Is pure-ffi required for pure-gtk in general or only for the
> examples? I'm trying to decide if I should declare the pure-ffi port
> as a dependency of the pure-gtk port.

Only for the examples. But you'll need pure-ffi for practically every
pure-gtk application (it's needed to define the callbacks).