guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

guile-gnome-glib 2.3.993


From: Andy Wingo
Subject: guile-gnome-glib 2.3.993
Date: Thu, 09 Sep 2004 00:10:50 +0200

New in this prerelease:

All AUTHORS files have been updated. I think they're correct, although
if you've put in a patch to GLib or the build system and you're not
there, let me know. Also, it would be nice to have someone GNU-
knowledgeable to look at them and see if they are OK.

glib/NEWS got a big update. I tried to make it look like Guile's NEWS;
it's a helpful format. Dunno if I missed something important there. I've
included the new section inline below for comment.

docs/ is now in the tarball. Whoops!

Still TODO: suitable READMEs in the toplevel pkg directory, explaining
how the source is laid out (i.e., independent packages in subdirs).

http://ambient.2y.net/wingo/tmp/guile-gnome-glib-2.3.993.tar.gz

Give it a whirl -- I think that the GLib side of things is looking good.
We just have to get GNOME in order.

=======
guile-gnome-glib NEWS --- history of user-visible changes.
Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
See the end for copying conditions.

guile-gnome-glib contains the bindings generator for guile-gnome, the
GObject wrapper, and the GLib bindings. This file documents the
user-visible changes in guile-gnome-glib only.


guile-gnome-glib 2.6.0 - Andy Wingo, 2004-09-XX

* Changes to the distribution

** guile-gnome-glib is a part of GNU Guile-Gnome.

GNU Guile-Gnome is the umbrella project for the Gnome 2.X Guile
bindings. guile-gnome-glib is that part of the package that wraps
GObject, provides a bindings generator, and the bindings for GLib.

** guile-gnome-glib can be distributed separately.

guile-gnome can be configured to have any number of modules together in
one source package. guile-gnome-glib can be installed on its own; its
only dependency is on the .defs module, guile-gnome-defs.

Most common files were placed in guile-gnome-pkg. ChangeLogs from
subdirectories were merged together, and entries that didn't have to do
with GLib, GObject, or the bindings generator were elided from
guile-gnome-glib's copy.

** We depend on unstable G-Wrap 1.9.1.

G-Wrap is an FFI generator for Guile and other languages. guile-gnome
relies on many features of the new G-Wrap, including latent bindings for
types and generic functions, which reduce wrapset load time
considerably.

** There's a test suite now.

Andreas Rottmann rocks.

* Changes to the GObject wrapper

** (gnome gobject) has been split into pieces.

Closures, GObject, parameters, GValues, signals and GTypes are now
implemented in separate modules, with no circular dependencies.

** The C interface has been cleaned up and split into pieces.

The specious "gobject/primitives" distinction was removed in favor of a
function decomposition of the wrapset mirroring the module hierarchy.
The set of exported macros and functions was audited for relevance.

** GInterfaces are supported via multiple inheritance.

You can use standard type predicates such as `is-a?' on instances of
types that implement interfaces. Methods on interfaces dispatch
properly. For example,

  (class-precedence-list <gtk-entry>
  ==>  (#<<gobject-class> <gtk-entry> 40f329d0>
        #<<gobject-class> <gtk-editable> 40f32a10>
        #<<gobject-class> <gtk-cell-editable> 40f32a40>
        #<<gobject-class> <gtk-widget> 8091f80>
        #<<gobject-class> <atk-implementor-iface> 8091f90>
        #<<gobject-class> <ginterface> 808b4b0>
        #<<gobject-class> <gtk-object> 80920e0>
        #<<gobject-class> <gobject> 808b610>
        #<<gtype-instance-class> <gtype-instance> 808a250>
        #<<class> <object> 80865a0>
        #<<class> <top> 80865d0>)

** The metaclass hierarchy was cleaned up.

Metaclasses were cleaned up so that type predicates applied
consistently. See gtype.scm for details.

  (class-precedence-list (class-of <gtk-entry>)
  ==> (#<<set-once-class> <gobject-class> 808b6c0>
       #<<set-once-class> <gtype-instance-class> 808a2b0>
       #<<set-once-class> <gtype-class> 808a330>
       #<<class> <set-once-class> 808a3d0>
       #<<class> <class> 8086600>
       #<<class> <object> 80865a0>
       #<<class> <top> 80865d0>)

** Class slot names changed.

`gobject-signals' => `gsignals'.

** GValueArray support added.

You can make GValueArrays just like you make GValues:

  (make <gvalue-array> #:value '(1 2 3))

If the values are not <gvalue> instances already, they will be passed to
`scm->gvalue'.

** GSignals can be emitted on any GTypeInstance.

As such, many of the signal functions changed name. For instance,
`gobject-signal-emit' changed to `gtype-instance-signal-emit'. The
generics were adjusted accordingly.

** GObject classes can be subclassed directly.

As a result, `define-gobject-class' and `let-params' are gone.

  (define-class <my-entry> (<gtk-entry>)
   (prop #:gparam `(,<gparam-int> #:default-value 1))
   #:gsignal '(my-signal #f))

<genum> and <gflags> can also be subclassed. See the documentation for
more details.

*** `initialize' is called by libgobject for custom classes.

This ensures that the ancestor classes have initialized the object
before user code handles it. However, this means that any arguments
passed to `make' are not seen by the `initialize' method, including
:init-keyword options. This is a problem that needs resolution.

** GObject instances can be marked as "destroyed".

Gtk+ requires that one be able to explicitly destroy objects, which
should cause all code to release references to an object. This is
implemented by setting the SMOB's value to NULL.
scm_c_scm_to_gtype_instance will check for a NULL value, throwing an
exception as appropriate.

* Changes to the bindings generator

** Enums without GTypes are supported

See the GLib bindings for an example.

** Scheme name hyphenation better matches GNOME conventions.

GtkIMContext => <gtk-im-context>, GtkHBox => <gtk-hbox>, etc. However,
although GSource => <g-source>, GObject => <gobject>.

** GErrors produce Scheme exceptions.

As such, there is no longer a need to pass GError arguments to
procedures.

* Bug fixes.
-- 
Andy Wingo <address@hidden>
http://ambient.2y.net/wingo/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]