Re: canvas example and fixes

[Andy Wingo]

Hi,

I just wanted to summarize the conclusions for naming schemes. I still
think having the tarball name all ofer the place is a bit ugly, but I
don't feel like switching it around any more. (Also, I can't create new
categories on the mainline archive. Any way that can change, rotty?)

arch categories:    same as upstream tarball name
wrapset name:       same as upstream tarball name
spec file name:     same as upstream tarball name
public module name: schemey name, without prefix.
defs file name:     undecided? should be same as the spec file name, tho

Hm. Actually, looking at that list, I really think using the upstream
tarball name anywhere is just unnecessary. Is anyone with me on this?
Maybe I'm crazy.

> > 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).

Why is this an important assumption? The only reason that g-wrap used to
do this is because it was exporting each symbol, which is unnecessary in
the light of the use-module trick.

OK, I don't want to delay a g-wrap release any more ;) But the presence
of a g-wrap scheme module can only cause confusion: people will think
they can just use the things in (gnome gw ...), when that's private API
(beside the -spec files). The other situation you get is when wrapsets
don't have a toplevel module, people will get lazy and release code that
depends on (gnome gw foo). A number of categories are like that now.

Sorry for replying so late. Let's not make any of these issues
release-blockers :P
-- 
Andy Wingo <address@hidden>
http://ambient.2y.net/wingo/