tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] Maemo port

[Alessandro P. <apa...@gm...>]

Hi,

I've committed some changes for debian maemo packaging, I hope I did'nt
break anything for other architectures.

This release updates to the last CVS source and fixes some problems:

* missing icon in the task manager when home button is pressed
* cursor is now hidden
* print and text tools are disabled


I will upload new armel debian packages to garage later this morning.

Disabling text tool from code is a bad idea (someone have an hardware BT
keyboard), is not possibile to add a configuration switch (such as
noprint=yes)?

libsdlttf2 remains an unresolved issue (but unrelated with tuxpaint
development): the only way I've found to install it from N770 is to maunally
add the maemo repository , enter in red-pill mode and install it before
tuxpaint from the app manager, not an easy way.


Enjoy.
-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] Test build with SVG support

[Bill K. <nb...@so...>]

On Thu, Mar 22, 2007 at 07:58:16PM +0000, John Popplewell wrote:
> Here is a link to a complete set of binaries zipped-up into a 'tuxpaint'
> directory:
> 
> http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-win32-svg-test-02.zip
> (2.1Mb)

It worked, thanks! :)

-bill!

Re: [Tuxpaint-devel] Test build with SVG support

[TOYAMA Shin-i. <sh...@wm...>]

Hi !

Finally I got working tuxpaint.exe with svg-support basicly 
according to your instruction.

Thank you!

John Popplewell wrote in <200...@ro...>
>I've updated my instructions and patches:
>
>http://johnnypops.demon.co.uk/mingw/index.html

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Having a hard time compiling tuxpaint for 770

[Alessandro P. <apa...@gm...>]

Ok, I've found my way, changed makefile for nokia target and now it works
fine with locales and fullscreen.

A fresh build will follow.

Cheers.


2007/3/23, Alessandro Pasotti <apa...@gm...>:
>
> Ok, I've found some more time for 770/800 build,
>
> I restarted from the CVS code (still don't have login access to it :( ),
> I'm trying to do it the "debian" way...
>
> I've found a lot of problems since there is probably a bug in tuxpaint.c:
>
> The NOKIA_770 flag, set WINDOW_WIDTH variable but the following lines:
>
> #ifndef WINDOW_WIDTH
>   WINDOW_WIDTH = 800;
>   WINDOW_HEIGHT = 600;
> #endif
>
> reset them to 800x600, solved moving those lines before the nokia and olpc
> ifdef.
>
>
> Another issue I cannot solve is that localization don't work, all locales
> are in the right place but the language is fixed to english.
>
> Even the command line switches for language don't help.
>
> Any idea?
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it




-- 
Alessandro Pasotti
w3:   www.itopen.it

[Tuxpaint-devel] Having a hard time compiling tuxpaint for 770

[Alessandro P. <apa...@gm...>]

Ok, I've found some more time for 770/800 build,

I restarted from the CVS code (still don't have login access to it :( ), I'm
trying to do it the "debian" way...

I've found a lot of problems since there is probably a bug in tuxpaint.c:

The NOKIA_770 flag, set WINDOW_WIDTH variable but the following lines:

#ifndef WINDOW_WIDTH
  WINDOW_WIDTH = 800;
  WINDOW_HEIGHT = 600;
#endif

reset them to 800x600, solved moving those lines before the nokia and olpc
ifdef.


Another issue I cannot solve is that localization don't work, all locales
are in the right place but the language is fixed to english.

Even the command line switches for language don't help.

Any idea?

-- 
Alessandro Pasotti
w3:   www.itopen.it

Re: [Tuxpaint-devel] Test build with SVG support

[John P. <jo...@jo...>]

On Thu, Mar 22, 2007 at 11:19:29AM -0700, Bill Kendrick wrote:
> On Thu, Mar 15, 2007 at 05:06:43AM +0000, John Popplewell wrote:
> > and the 'duplicates' in the stamps collection.
> 
> FYI, I finally updated tuxpaint.c so that when it stumbles across a PNG file,
> it double-checks that there's no similarly-named SVG file.  If it finds one,
> it skips the PNG, with the assumption that the SVG one is the preferred one
> to use.
Great!

> I think at some point, for platforms that just won't do SVG any time soon,
> we'll end up wanting a build process within tuxpaint-stamps that
> converts SVGs into PNGs before packaging the stamps for release.  Then only
> package the PNGs.
> 
> So in the end, the only PNGs that would be stored in the Tux Paint Stamps
> 'source' repository would be photographic ones, for which there are no
> corresponding PNGs.
Sounds like a plan!

I found the problem with the previous build (I hope!) it was some weird
exports in 'jpeg.dll' and a buggy gcc-3.4.2 compiler.

Here is a link to a complete set of binaries zipped-up into a 'tuxpaint'
directory:

http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-win32-svg-test-02.zip
(2.1Mb)

which will overwrite existing files if you unpack into an existing
'tuxpaint' directory.

It needs the 'data', 'docs' and 'locale' directories from an existing
tuxpaint installation to work.

Please test!

I've updated my instructions and patches:

http://johnnypops.demon.co.uk/mingw/index.html

I've checked some minor updates into cvs, but there is still a problem
with this embedded path:

SVG_CFLAGS=-I/usr/include/cairo

thanks,
John.

Re: [Tuxpaint-devel] Test build with SVG support

[Bill K. <nb...@so...>]

On Thu, Mar 15, 2007 at 05:06:43AM +0000, John Popplewell wrote:
> and the 'duplicates' in the stamps collection.

FYI, I finally updated tuxpaint.c so that when it stumbles across a PNG file,
it double-checks that there's no similarly-named SVG file.  If it finds one,
it skips the PNG, with the assumption that the SVG one is the preferred one
to use.

I think at some point, for platforms that just won't do SVG any time soon,
we'll end up wanting a build process within tuxpaint-stamps that
converts SVGs into PNGs before packaging the stamps for release.  Then only
package the PNGs.

So in the end, the only PNGs that would be stored in the Tux Paint Stamps
'source' repository would be photographic ones, for which there are no
corresponding PNGs.

In other words:

  source tarball / CVS repository:

    foo-photo.png
    bar-drawing.svg

  package for an SVG-capable platform: (say, Win32)

    foo-photo.png
    bar-drawing.svg

  package for some non-SVG-supporting platform:

    foo-photo.png
    bar-drawing.png    [converted from bar-drawing.svg at 'build' time]

-bill!

[Tuxpaint-devel] stamps won't scale up

[Albert C. <aca...@gm...>]

The X server is 16 bit/pixel, 5:6:5. This is x86.

Scaling down always works fine.

When VIDEO_BPP is 32, scaling up works. 15, 16, and 24
all fail. NO_BILINEAR makes no difference.

I get a rectangle of thin lines or some similar bland pattern,
with no hint of the stamp I was using. Both the stiple outline
and the final result have this problem.

I'd use 32, but then the OOM killer gets me. Got any other
ideas for saving memory? I can't much exceed 50 MB.

Re: [Tuxpaint-devel] Test build with SVG support

[TOYAMA Shin-i. <sh...@wm...>]

Hi Jhon,

At the end of last year, I tried to build tuxpaint-win32 with 
svg support using MinGW/MSYS (latest version at that time)
The version of GCC I used was 3.4.2.

I will try different version of gcc.
Thank you for your information!

John Popplewell wrote in <200...@ro...>
>On Thu, Mar 15, 2007 at 10:40:25PM +0900, TOYAMA Shin-ichi wrote:
>> Thank you Jhon!
>> 
>> Your tuxpaint-svg.exe works well on my WinXP.
>> I'm looking forward to seeing your summary  how 
>> to build svg-enabled version of tuxpaint!
>Hi Shin-ichi,
>
>I've updated my instructions for building the DLLs and started from
>scratch using the latest MinGW/MSYS version:
>
>http://johnnypops.demon.co.uk/mingw/index.html
>
>Unfortunately, it doesn't work for me either :-(
>
>I also had trouble building the "fluid" FLTK application and it crashed
>with the same nasty message.
>
>It all builds and works fine when using an older version of MinGW/MSYS
>which uses a different version of the compiler, gcc-3.2.3, instead of
>the later gcc-3.4.2 so maybe it's something related to gcc?
>
>I'll try again later with gcc-3.4.5 which is also available on the MinGW
>site.
>
>Did you use the "Current" version of MinGW/MSYS ?
>
>I'm fairly sure the working ones were built with the "Previous" version,
>
>regards,
>John.
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Test build with SVG support

[Karl O. H. <ka...@hu...>]

Torsdag 15 mars 2007 06:06 skreiv John Popplewell:

>and the 'duplicates' in the stamps collection. One of them,
>'pink_cake.svg' doesn't render anything - I've not looked into it yet.

Could it be because of the gradients? It is with images with gradients we will 
really save most space by using SVG images instead of PNG.

-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] Test build with SVG support

[John P. <jo...@jo...>]

On Tue, Mar 20, 2007 at 01:00:45PM -0700, Bill Kendrick wrote:
> On Thu, Mar 15, 2007 at 05:06:43AM +0000, John Popplewell wrote:
> > Hi,
> > 
> > I've finally got SVG support working on Windows using MingW/MSYS. Here
> > is a link to a zip archive containing a 'tuxpaint-svg.exe' and the extra
> > DLLs:
> > 
> > http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-win32-svg-test-01.zip
> > 
> 
> Copied my C:\Program Files\TuxPaint onto my desktop (so I wouldn't
> mess up my installed copy), and drug the contents of the ZIP into there.
I should have mentioned that it doesn't over-write anything, and that it
needs to be unpacked into the 'tuxpaint' parent directory, or somewhere
else and the files moved in manually.

> I tried double-clicking tuxpaint-svg.exe but get a Window pop-up error:
> 
>   The application failed to initialize properly (0x00000005).
>   Click on OK to terminate the application.
> 
Thanks for testing it bill!

That's the message we get with the latest builds, which is interesting,
but just muddies the water further :-(

Is that with the final release version of Tux Paint 0.9.16 installed ?

There could be something nasty going on in one of the four new DLLs
(0.9.16 seems to work fine with the new MinGW/MSYS) but that wouldn't
explain the problem with 'fluid'.

> Running regular tuxpaint.exe in there seems to work.  Tried running both
> from an MSDOS command-line prompt, with the same results, and no additional
> output to the terminal.
> 
> I see no stderr.txt or stdout.txt. :(
I've checked, and it's crashing before it gets into main(), hence that
unusual error-box.

> This is Win XP Pro v2002 SP2 on a Dell Latitude D620.
It works fine on all my machines: 2xWin98 boxes, Win2K and WinXP Pro
SP2,

cheers,
John.

> 
> Thx!
> 
> -bill!
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Re: [Tuxpaint-devel] Test build with SVG support

[Bill K. <nb...@so...>]

On Thu, Mar 15, 2007 at 05:06:43AM +0000, John Popplewell wrote:
> Hi,
> 
> I've finally got SVG support working on Windows using MingW/MSYS. Here
> is a link to a zip archive containing a 'tuxpaint-svg.exe' and the extra
> DLLs:
> 
> http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-win32-svg-test-01.zip
> 

Copied my C:\Program Files\TuxPaint onto my desktop (so I wouldn't
mess up my installed copy), and drug the contents of the ZIP into there.

I tried double-clicking tuxpaint-svg.exe but get a Window pop-up error:

  The application failed to initialize properly (0x00000005).
  Click on OK to terminate the application.

Running regular tuxpaint.exe in there seems to work.  Tried running both
from an MSDOS command-line prompt, with the same results, and no additional
output to the terminal.

I see no stderr.txt or stdout.txt. :(

This is Win XP Pro v2002 SP2 on a Dell Latitude D620.

Thx!

-bill!

Re: [Tuxpaint-devel] Test build with SVG support

[John P. <jo...@jo...>]

On Thu, Mar 15, 2007 at 10:40:25PM +0900, TOYAMA Shin-ichi wrote:
> Thank you Jhon!
> 
> Your tuxpaint-svg.exe works well on my WinXP.
> I'm looking forward to seeing your summary  how 
> to build svg-enabled version of tuxpaint!
Hi Shin-ichi,

I've updated my instructions for building the DLLs and started from
scratch using the latest MinGW/MSYS version:

http://johnnypops.demon.co.uk/mingw/index.html

Unfortunately, it doesn't work for me either :-(

I also had trouble building the "fluid" FLTK application and it crashed
with the same nasty message.

It all builds and works fine when using an older version of MinGW/MSYS
which uses a different version of the compiler, gcc-3.2.3, instead of
the later gcc-3.4.2 so maybe it's something related to gcc?

I'll try again later with gcc-3.4.5 which is also available on the MinGW
site.

Did you use the "Current" version of MinGW/MSYS ?

I'm fairly sure the working ones were built with the "Previous" version,

regards,
John.

Re: [Tuxpaint-devel] Makefile break & fix for MAEMOFLAG

[Bill K. <nb...@so...>]

On Fri, Mar 16, 2007 at 10:39:13PM -0700, Mark K. Kim wrote:
> Adding a default value for MAEMOFLAG that does not conflict with any
> other defined constants or macros should take care of this little
> issue.  Anyone mind if I add a default value for MAEMOFLAG?:

That's fine.

Why not just leave MAEMOFLAG blank for non-Maemo builds, and set it to
"-DMAEMO" for Maemo builds?  I guess I could do similar for some of the
other flags, too, if that makes more sense than what I have now...

Thx for catching and fixing this, Mark! :)

-bill!
(busy with a baby!)

Re: [Tuxpaint-devel] Makefile break & fix for MAEMOFLAG

[Mark K. K. <mkk...@gm...>]

On Sat, Mar 17, 2007 at 07:17:48PM +0200, Terje Bergstr?m wrote:
> On Saturday 17 March 2007 07:39:13 Mark K. Kim wrote:
> (...)
> > which causes `make` to refuse to compile for non-Nokia_770 platforms
> > because there is no identifier defined after "-D":
> 
> Hi,
> 
> Sorry about that. I committed the change and didn't realize that it breaks 
> non-770 builds. Please commit a fix if possible.

No worries.  Just wanted to make sure my change is okay with everyone.

The change has been commited to CVS.

-Mark

Re: [Tuxpaint-devel] Makefile break & fix for MAEMOFLAG

[Terje <te...@ik...>]

On Saturday 17 March 2007 07:39:13 Mark K. Kim wrote:
(...)
> which causes `make` to refuse to compile for non-Nokia_770 platforms
> because there is no identifier defined after "-D":

Hi,

Sorry about that. I committed the change and didn't realize that it breaks 
non-770 builds. Please commit a fix if possible.

Thank you.

Terje

[Tuxpaint-devel] Makefile break & fix for MAEMOFLAG

[Mark K. K. <mkk...@gm...>]

It looks like the Nokia 770 patch added a variable called "MAEMOFLAG" in
the Makefile:

  DEFS=-DDATA_PREFIX=\"$(DATA_PREFIX)/\" \
   -D$(NOSOUNDFLAG) -D$(NOSVGFLAG) -DDOC_PREFIX=\"$(DOC_PREFIX)/\" \
   -DLOCALEDIR=\"$(LOCALE_PREFIX)/\" -DCONFDIR=\"$(CONFDIR)/\" \
   -DVER_VERSION=\"$(VER_VERSION)\" \
   -DVER_DATE=\"$(VER_DATE)\" \
   -D$(MAEMOFLAG)

where MAEMOFLAG is set to NOKIA_770 when compling for the Nokia 770:

  # "make nokia770" builds the program for the Nokia 770.
  
  nokia770:
    make \
      DATA_PREFIX=/usr/share/tuxpaint \
      SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG \
      MAEMOFLAG=NOKIA_770

which is fine, except the default value of MAEMOFLAG for non-Nokia_770
platform is blank:

  # Maemo flag
  
  MAEMOFLAG=

which causes the DEFS expansion to end in:

  DEFS=-DDATA_PREFIX= ... -D

which causes `make` to refuse to compile for non-Nokia_770 platforms
because there is no identifier defined after "-D":

  ~/proj/tuxpaint/tuxpaint/>make nosvg
  
  Building with SVG DISABLED
  
  make SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG
  make[1]: Entering directory `/home/vindaci/proj/tuxpaint/tuxpaint'
  
  ...Compiling Tux Paint from source...
  cc -O2 -W -Wall -fno-common -ffloat-store -Wcast-align -Wredundant-decls
  -Wbad-function-cast -Wwrite-strings -Waggregate-return
  -Wstrict-prototypes -Wmissing-prototypes `src/test-option.sh
  -Wdeclaration-after-statement`  -I/usr/include/SDL -D_REENTRANT
  -Isrc/mouse -DLARGE_CURSOR_SHAPES
  -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -D__SOUND -DNOSVG
  -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint/\"
  -DLOCALEDIR=\"/usr/local/share/locale/\"
  -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DVER_VERSION=\"0.9.17\"
  -DVER_DATE=\"`date +"%Y-%m-%d"`\" -D \
          -c src/tuxpaint.c -o obj/tuxpaint.o
  <command line>:14:1: macro names must be identifiers

Adding a default value for MAEMOFLAG that does not conflict with any
other defined constants or macros should take care of this little
issue.  Anyone mind if I add a default value for MAEMOFLAG?:

  Index: Makefile
  ===================================================================
  RCS file: /cvsroot/tuxpaint/tuxpaint/Makefile,v
  retrieving revision 1.125
  diff -u -r1.125 Makefile
  --- Makefile   12 Mar 2007 06:27:03 -0000   1.125
  +++ Makefile   17 Mar 2007 05:22:42 -0000
  @@ -84,7 +84,7 @@
  
   # Maemo flag
  
  -MAEMOFLAG=
  +MAEMOFLAG=NO_MAEMOFLAG
  
   # Where to find cursor shape XBMs

which produces:

  ~/proj/tuxpaint/tuxpaint/>make nosvg
  
  Building with SVG DISABLED
  
  make SVG_LIB= SVG_CFLAGS= NOSVGFLAG=NOSVG
  make[1]: Entering directory `/home/vindaci/proj/tuxpaint/tuxpaint'
  
  ...Compiling Tux Paint from source...
  cc -O2 -W -Wall -fno-common -ffloat-store -Wcast-align -Wredundant-decls
  -Wbad-function-cast -Wwrite-strings -Waggregate-return
  -Wstrict-prototypes -Wmissing-prototypes `src/test-option.sh
  -Wdeclaration-after-statement`  -I/usr/include/SDL -D_REENTRANT
  -Isrc/mouse -DLARGE_CURSOR_SHAPES
  -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -D__SOUND -DNOSVG
  -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint/\"
  -DLOCALEDIR=\"/usr/local/share/locale/\"
  -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DVER_VERSION=\"0.9.17\"
  -DVER_DATE=\"`date +"%Y-%m-%d"`\" -DNO_MAEMOFLAG \
          -c src/tuxpaint.c -o obj/tuxpaint.o
  
  ...Compiling i18n support...
  
  ...Compiling cursor support...

  etc.

-Mark

Re: [Tuxpaint-devel] Test build with SVG support

[TOYAMA Shin-i. <sh...@wm...>]

Thank you Jhon!

Your tuxpaint-svg.exe works well on my WinXP.
I'm looking forward to seeing your summary  how 
to build svg-enabled version of tuxpaint!


John Popplewell wrote in <200...@ro...>
>Hi,
>
>I've finally got SVG support working on Windows using MingW/MSYS. Here
>is a link to a zip archive containing a 'tuxpaint-svg.exe' and the extra
>DLLs:
>
>http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-win32-svg-test-01.zip
>
>if anyone wants to play with it.
>
>I'll write it up later: I had quite a struggle getting 'svg.dll' built
>because of a libtool problem...
>
>I've tested it with the .svg files from this project:
>
>http://www.linuxmotors.com/SDL_svg/
>
>and the 'duplicates' in the stamps collection. One of them,
>'pink_cake.svg' doesn't render anything - I've not looked into it yet.
>
>Thanks to Toyama Shin-ichi whose post got me started on this :-)
>
>regards,
>John.
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] [Tuxpaint-users] no stamps after installing stamps

[<tor...@at...>]

Bill Kendrick skrev:
> On Sat, Mar 03, 2007 at 01:49:45PM -0800, Richard Hubbell wrote:
>   
>> I installed the stamps under the current users account
>> and they are there under ~/Library/Application
>> Support/TuxPaint/stamps/
>>
>> But they don't show up when selecting the stamp tool.
>> Only see the default stamps with tux on them.
>>
>> Thanks for any help. 
>>     
>
> Hi Richard, sorry for your trouble.  I'm Cc'ing this to the 'tuxpaint-devel'
> list to see if anyone there may know what's up.
>
> I've not come across this issue before, unfortunately.
>
> Thanks and good luck!
>
> PS - sorry for the late reply from me -- newborn in the house! :^)
>
>   
It sounds like the problem I had, where I had used the config program to 
set up a different save directory, and TuxPaint looked in the save 
directory when trying to find the stamps.

See:
http://sourceforge.net/mailarchive/forum.php?thread_id=30593748&forum_id=44504

That was on Windows however, so I don't know if it's the same problem. 
One solution was to move the stamps to the data\stamps folder under the 
TuxPaint program folder. The other solution was to move them to the save 
folder (in a data\stamps folder I think).

Kind regards,
Tore

[Tuxpaint-devel] Test build with SVG support

[John P. <jo...@jo...>]

Hi,

I've finally got SVG support working on Windows using MingW/MSYS. Here
is a link to a zip archive containing a 'tuxpaint-svg.exe' and the extra
DLLs:

http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-win32-svg-test-01.zip

if anyone wants to play with it.

I'll write it up later: I had quite a struggle getting 'svg.dll' built
because of a libtool problem...

I've tested it with the .svg files from this project:

http://www.linuxmotors.com/SDL_svg/

and the 'duplicates' in the stamps collection. One of them,
'pink_cake.svg' doesn't render anything - I've not looked into it yet.

Thanks to Toyama Shin-ichi whose post got me started on this :-)

regards,
John.

Re: [Tuxpaint-devel] A list of the Tux Paint canvas (and starters) size.

[Bill K. <nb...@so...>]

On Wed, Mar 14, 2007 at 01:21:42PM -0400, Albert Cahalan wrote:
> On 3/14/07, Bill Kendrick <nb...@so...> wrote:
> 
> > It should, at the moment, always be 192 px narrower than the window,
> > and 128 px shorter in height than the window.
> 
> Sure about the height?

Ack, actually, no.  I recall it being 128 for a few sizes, but obviously
did not check the code.  I'll be sure to do so.

-bill!

Re: [Tuxpaint-devel] A list of the Tux Paint canvas (and starters) size.

[Albert C. <aca...@gm...>]

On 3/14/07, Bill Kendrick <nb...@so...> wrote:

> It should, at the moment, always be 192 px narrower than the window,
> and 128 px shorter in height than the window.

Sure about the height?

I think it's 40 plus the largest multiple of 48 that wouldn't
make the tux text area shorter than 56. Thus the tux text
area varies between 56 and 103. That makes the drawing
area shorter than the screen by 144 to 191.

Well, it was something like that when I wrote the code
to allow arbitrary sizes.

Re: [Tuxpaint-devel] [SDL] Full screen mode disabling screensaver?

[Ryan C. G. <ic...@ic...>]

> Sounds like SDL is disabling screensaver while in fullscreen mode.
> Is that by design?  Any way around that?  Any reason to avoid turning on
> the screensaver?

I suspect it was added for games that never want the screensaver to 
enable, so if you're playing with a joystick, you won't have to wiggle 
the mouse every few minutes to keep the screen from turning off.

TuxPaint is fairly unique among SDL apps in that you could have someone 
walk away and not quit...it's more a regular application and less a game.

> (Maybe I should add a simple screensaver to Tux Paint itself after
> an extended amount of inactivity...?)

We could probably add an environment variable to SDL for this, but it 
might be cleaner to either just ship a hacked SDL that returns 
immediately from X11_DisableScreenSaver() or build it into TuxPaint itself.

I could see a value in having the environment variable, since other apps 
could use this, too, but on the other hand...another environment 
variable?!  :)

Let me know what you think is best.

--ryan.

Re: [Tuxpaint-devel] [Tuxpaint-users] no stamps after installing stamps

[Bill K. <nb...@so...>]

On Sat, Mar 03, 2007 at 01:49:45PM -0800, Richard Hubbell wrote:
> I installed the stamps under the current users account
> and they are there under ~/Library/Application
> Support/TuxPaint/stamps/
> 
> But they don't show up when selecting the stamp tool.
> Only see the default stamps with tux on them.
> 
> Thanks for any help. 

Hi Richard, sorry for your trouble.  I'm Cc'ing this to the 'tuxpaint-devel'
list to see if anyone there may know what's up.

I've not come across this issue before, unfortunately.

Thanks and good luck!

PS - sorry for the late reply from me -- newborn in the house! :^)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] A list of the Tux Paint canvas (and starters) size.

[Bill K. <nb...@so...>]

On Thu, Feb 22, 2007 at 06:05:15PM -0800, Robert Elliott wrote:
> Tux Paint Developer List
> 
>    I am developing starters for kids to practice matte painting for motion
> pictures using Tux Paint (on the Macintosh).  I find that some of the
> information on the page "Extending Tux Paint" is incomplete or wrong.
> 
>    By measuring, I find that:
<snip>

It should, at the moment, always be 192 px narrower than the window,
and 128 px shorter in height than the window.

I'll make sure to update the EXTENDING docs to cover this!

-bill!