Re: canvas example and fixes

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> Hi Andreas,
>
> On Sun, 2004-05-30 at 19:22 +0200, Andreas Rottmann wrote:
>>
>> I agree that the toplevel modules (e.g. (gnome gtk)) should not have
>> any prefixes, but I followed the upstream module names for the
>> generated modules in (gnome gw ...) and the actual category name. I'm
>> not clear wether you meant to change this or only talk about toplevel
>> modules.
>
> Well, when I wrote I was referring to both. I hadn't really thought
> about it too much, it seems we're defining our rules by doing ;) That's
> OK though.
>
> There are two possibilities. One is to make it the same as the toplevel
> module name (i.e. (gnome canvas) -> (gnome gw canvas)). The other is to
> make it the same as the upstream package. However, with the upstream
> package name, you run into a problem: is it gtk, gtk+, or libgtk+?
>
I went after upstream tarball/CVS module names. However, I deviated
for gtk (for historical raisins :-)); to be consistent, it would have
to be gtk+.

> I have a very slight preference towards the first option, but I don't
> care very much, as long as we're consistent. If you can provide a
> consistent mapping strategy, and add it to HACKING at the pkg--dev--0
> top dir, then I'm cool with whatever strategy you come up with.
>
I have a slight preference to the current scheme (if only because it's
already there ;-). That is:

* Follow upstream tarball/CVS module names for the G-Wrap wrapset
  names, spec file names and Arch category names. This way, when you
  know the upstream CVS module name is FOO, you know the G-Wrap
  wrapset name is gnome-FOO and the binding is hosted in the FOO
  category. The latter is only true, however, if the binding isn't
  split up in different pparts, as with GTK+ (gdk, gtk) or GLib
  (gobject, glib).

* Give the toplevel modules "natural" names, e.g. drop "lib" prefixes.

How does that sound?

> Perhaps there is a third way, though. No one should use the g-wrap
> modules by themselves. Perhaps we should require that the scheme code be
> done manually. That way (gnome gtk) dlopens the g-wrap library itself,
> and there is no (gnome gw foo). Dunno, thoughts?
>
This looks like an alternative, but it would violate the assumption of
G-Wrap that it can emit Scheme code to the module it creates (or that
it can create a Scheme module at all).

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/