[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: canvas example and fixes
From: |
Andreas Rottmann |
Subject: |
Re: canvas example and fixes |
Date: |
Mon, 07 Jun 2004 20:08:08 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
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/