On Mon, Apr 6, 2009 at 6:05 PM, Bill Kendrick <firstname.lastname@example.org>
> What should II think 'memo' the magic tool should, for now at least, be a separate
> do about pushing patches downstream? I have an SVN repository that you
> can pull from if that is acceptable, or I can send things directly to the
> CVS repo you are hosting. My experience with CVS is that it causes
> surprises to appear when source trees get out of sync. Whichever is
> preferable to you is fine with me.
download. Therefore, live in a separate repository. To keep things
'in the family,' I'd like to suggest hosting it at SourceForge.net.
Right now, all we use there is CVS, since that's all they supported
for a _very_ long time.
Since being it's own, separate thing, with its own Makefile & such,
it wouldn't be touching the active Tux Paint code, there's little space
So in otherwords, the repository would hold:
tuxpaint -- app & core magic tools
tuxpaint-config -- configuration gui
tuxpaint-stamps -- stamps collection
tuxpaint-website -- website source code
drawtext -- the handwriting-recognition magic tool from GSOC 2008
memo -- your audio recording/playback magic tool
Now, there are probably places where the Magic API in TP could be
improved to support your app. (I see you cut-n-pasted some of the
'where are my saved files stored?' code. Along with being dup'd code,
I think that would also end up ignoring the --savedir option, which'd be
bad. So a 'where are my files?' query via the API might eb good.
And even 'what's the picture I'm working on now?' query.)
I seriously think this discussion should take place over at tuxpaint-devel.
Do you mind if we move it there, moving ahead?
First off, I agree about where to put memo in the context of Tuxpaint, and to using CVS to whatever extent necessary ;-0 No complaints from me!
My product designers, Rachel and Maya, don't know much about the Magic API, but they did seem to be wanting to evolve the recording tool into a game rather than a utility. You may notice the use of the term 'game_' sprinkled among the symbols in memo.c, that's because a closely related version of this tool also supports a simple microphone game (say something and pass the microphone to the next person in a circle, is a basic description), that in the end I decided was probably out of scope for Tuxpaint (as well it employed it's very own SDL_Thread and there were some pesky instabilities that I never did work out entirely).
In working with the Magic API firsthand, I noticed a number of small things that were design challenges. For instance, deciding what would be the output filename of the user's picture (so that audio filenames could be chosen to correspond to the current image). Since the current image may be new and unsaved and/or abandoned, the filename was undecidable at recording time, so it goes to a temporary location instead. One thing I wanted to do with it was somehow support some way to bundle multiple wav(s) and the current image into a single file (SVG can do this according to specs, no?) that would increase the shareabilitiy of user experiences.