Re: canvas example and fixes

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> 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?)
>
Only if we move to a site like Gna! that allows centralized Archives
(or get Savannah to support it).

> 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
>
Yes, should be the same as the spec file.

> 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.
>
*g* I just thought it would make sense, since the names are presumably
 globally unique. Also the names aren't user-visible, they are just
 internal, so I don't mind that they are a bit verbose/ugly. Maybe you
 mind? ;)

>> > 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?
>> >
Any reasons you'd like to do this for (aside from doing away with the
re-export stuff?).

>> 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).
>
Indeed. And for wrapsets that are used directly, you'd have to write
the .scm module yourself, which seems like extra, unecessary work for
me. G-Wrap does this just nice and automatically, so why drop that
useful feature? I could imagine adding an option to turn it off
optionally, however.

> 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.
>
See above.

> 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).
>
I think documenting this big and fat would be enough.

> The other situation you get is when wrapsets don't have a toplevel
> module,
>
I think it should be mandatory for guile-gnome modules to 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.
>
Yeah, this should be fixed.

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

Python is executable pseudocode, Perl is executable line-noise.