A working TuxPaint-2.xo for 8.1 and 8.2, how to update the wiki?

[Ton van Overbeek]

Albert Cahalan wrote:
> Ton van Overbeek writes:
>
>   
>> This version (TuxPaint-2) of TuxPaint for the OLPC-XO fixes several issues
>> with the original version (TuxPaint-1) by Albert Calahan.
>>     
>
> Uh, are you intending to take over? I haven't seen any discussion on
> the tuxpaint-devel mailing list, on #tux4kids, or elsewhere.
>
> I have been working on a TuxPaint-2.xo for a while now. Am I supposed
> to abandon that effort, release it anyway, skip a version number...?
>   

> BTW, the name is spelled "Cahalan".
>   
Albert, first my apologies for misspelling your name.
I have no intent in taking over, but am willing to help. I had a 
personal need to get TuxPaint working
in Dutch on the XO for my grandson, since he will get my G1G1 XO next 
month when we are in Europe.
Since the Dutch translation was far from complete in TuxPaint-1.xo and 
the non English versions were
not working out of the box (see e.g. 
http://olpcnews.com/forum/index.php?topic=1049.0 item #4) and
other issues like changing the bundle name (no more hyphens allowed, see 
the discussion
on http://wiki.laptop.org/go/Talk:Tux_Paint) I decided to rebuild 
starting from the current CVS
version and your additions (sugarize + libsugar) in the original.
Because I thought the end result might interest more people I announced 
it on the devel list.
Since my version is now 'out in the wild', I am afraid you will have to 
go to TuxPaint-3.xo
for your next version.
>  
>   
>> The following issues are fixed in this release:
>> - Internationalization works out of the box. In TuxPaint-1 there was a typo
>>   which caused TuxPaint to look in a parallel tree under TuxPaint.activity.
>>   (note the trailing dot) for the localized files (.mo and fonts).
>>     
>
> I believe this was fixed when I checked in some Makefile changes.
> I have not rebuilt the *.xo since I fixed the Makefile.
>   
I could not get your Makefile fix to work. The code still looked for 
localization information
in ../TuxPaint.activity. (with trailing dot) due to the DEFS definition 
in the Makefile.
See my changes to the olpc: target in tuxpaint/Makefile (explicit 
defintion of LOCALE_PREFIX).
> BTW, perhaps I'm being too picky, but I'm trying to get Tux Paint
> sources in CVS to support building a *.xo with one command and a
> minimum of hacks. This is a good part of the reason for the delay.
> TuxPaint-1.xo is not very reproducable; plenty of manual work was
> required to create it.
>
>   
I have followed your example and to build my version start in 
TuxPaint.activity/ and then
do 'make olpc'. See TuxPaint.activity/Makefile and tuxpaint/Makefile. 
This assumes
you are building on an XO (see also below).
>> - Added the needed libpaper.so in the bundle and modified sugarize.c to add
>>   LD_LIBRARY_PATH so tuxpaint can find the library.
>>     
>
> I didn't do that for several reasons:
>
> 1. license issues
> 2. version control issues
> 3. can't set up /etc with the right printer info
>
> If libpaper isn't in the base system, then I don't want to use it.
> I have two other choices. I can rip out printing. I can revert to
> some older code which directly generates postscript.
>
> Assuming that printing support is even desirable, reverting to the
> old code (plus bug fix) looks best. That way, there is little need
> to worry about paper sizes.
>
>   
Agree with your reasoning. For the XO it is probably best to disable the 
priuter support
completely. The current code requires libpaper and I did not want to
remove the printer support code, since I am not that familiar with the 
TuxPaint code (yet).
Hence, the easy way out was to include libpaper.so in the bundle.
Since it is available as fedora-9 rpm I did not expect any license 
issues for libpaper.
>> Other changes:
>> - Added support for svg (scalable vector graphics) stamps.
>>     
>
> Which library? Which *-devel packages must be installed?
>
>   
All the non-devel rpms/packages needed for svg support are already on 
the XO (at least
for Update.1 and the current joyride/8.2 builds). I needed the required 
SDL-* devel rpms
anyway to compile so 'it just worked'.
My build machine is a QEMU emulated XO on Windows XP/SP2 with an extra 
1GB disk
where I moved and mounted /home/olpc to make room for all the needed 
devel packages
and gcc, make etc.
In the most recent builds also SDL-pango is included, as you know, so 
now we should be able
to build a full TuxPaint, but only for 8.2 systems. SDL-pango is not 
available on 8.1 and older
builds.
>> - To save space, keep only the smallest version of a stamp if both svg
>> and png
>>   versions are available.
>> - Removed development related files in the bundle. The full source is in
>>   TuxPaint-2.xo.tar.bz2.
>>     
>
> This really should happen in the main Makefile, via not copying
> them in the first place.
>
>   
Agreed, but I did not want to mess with the install-all target in 
tuxpaint-stamps, since that is
used by everybody, hence the use of some cleanup scripts. See 
TuxPaint.activity/Makefile.
>> - Updated activity.info with license information.
>>     
>
> Be careful. Tux Paint is not 100% GPL, though it's 100% Free Software.
>
>   
At the bottom of the home page of www.tuxpaint.org it says:
"Tux Paint is free, Open Source software, distributed under the terms of 
the GNU General Public License"
with a link to the GPLV2 text.
Are you talking about the included fonts?

>> - Added permissions.info with constant-uid option for 8.2 release.
>>     
>
> Why is this needed?
>   
In the Rainbow version on recent builds each invocation of TuxPaint 
starts with a new uid, but with the same gid.
The HOME directory is directed to SUGAR_ACTIVITY_ROOT/data by your 
wrapper which always maps
to the same directory independent of the uid. But the files created are 
owned by the creating uid with mode 644
and hence  cannot be overwritten by the next invocation of TuxPaint 
which used a different uid.
To avoid this for apps like TuxPaint they introduced this constant-uid 
option.
See http://wiki.laptop.org/go/Activity_bundles item 
activity/permissions.info.

I hope this clarifies the situation. Again I only wanted a working 
version for my grandson and thought others
might be interested in it. I have no intention at all to take over from 
you and I especially value the early
work you did (sugarize/libsugarize) to make it possible to integrate 
'normal' linux apps on the XO.

PS I did submit my updated dutch po files to Bill Kendrick yesterday.

Ton van Overbeek