tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] [Fwd: Bug#308194: tuxpaint: cannot type in russian]

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

On Mon, May 09, 2005 at 08:21:23PM -0300, Ben Armstrong wrote:
> Anyone know if this is a bug or just a user configuration issue?
<snip: can't type in russian>

Tux Paint's text input capabilities are currently fairly simplistic,
so I don't believe this is possible yet.  (Patches welcome! ;^) )

-bill!

[Tuxpaint-devel] [Fwd: Bug#308194: tuxpaint: cannot type in russian]

[Ben A. <sy...@sa...>]

Anyone know if this is a bug or just a user configuration issue?
Ben

[Tuxpaint-devel] Storing print config in Mac OS X

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

Right now, Tux Paint for Windows allows a "printcfg" option to be given
which causes any printer setting changes (done via [Alt] + 'Print') to be
stored.  As long as that option's enabled, Tux Paint will continue using
the last settings made (rather than default print settings), without the
need to hold [Alt] and change things every time.

(At least, that's how I understand it.)

I just got a note from a school using Tux Paint on OS X that needs precisely
this behaviour (so that they don't need to hit [Option] + 'Print' _every_
time.)

I'll add a note to the RFE's at SourceForge.  However, in case this school
needs this feature ASAP, is anyone willing to hack the 0.9.14 codebase
to provide this option?


(I'll also add an RFE to make sure I remember to _expose_ this option in
Tux Paint Config.  D'oh!)


Thanks!

-- 
-bill!
bi...@ne...      Tonight's Forecast: Dark. Continued darkness
http://newbreedsoftware.com/   until widely scattered light in the morning.

[Tuxpaint-devel] [Fwd: [xp-u] xpilot .map generator program]

[Ben A. <sy...@sa...>]

Maybe someone here could answer?  I know other randomisers already
exist.  I haven't looked at Menno's, though.

Ben

Re: [Tuxpaint-devel] [fwd] Tux Paint on ebay...

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

On Sun, Apr 17, 2005 at 07:46:01PM -0700, Bill Kendrick wrote:
> I've also decided to fill out their "Notice of Claimed Infringement" form
> (which is a PDF I have to print and mail/fax :^P ), as well.
> 
> We'll see what happens from there...

They've gotten back to me over the phone, had me clarify my concerns, and
are going to look into it more closely.

I mentioned that the same seller(s) appear to be selling rebranded
OpenOffice.org, Linux distros, and no doubt some other Open Source stuff.
I didn't recall whether they had claimed copyright ownership on those,
but it looks like eBay will be looking over them in general, so they'll
find out soon.

-- 
-bill!
bi...@ne...      Tonight's Forecast: Dark. Continued darkness
http://newbreedsoftware.com/   until widely scattered light in the morning.

Re: [Tuxpaint-devel] [fwd] Tux Paint on ebay...

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

On Sun, Apr 17, 2005 at 07:24:15PM -0700, Bill Kendrick wrote:
<snip>
> Anyone have any other comments/ideas regarding this?
<snip>

I've also decided to fill out their "Notice of Claimed Infringement" form
(which is a PDF I have to print and mail/fax :^P ), as well.

We'll see what happens from there...

-bill!

[Tuxpaint-devel] [fwd] Tux Paint on ebay...

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

Someone wrote in with the following:

> Hello, I just found this on ebay... 
> 
> I know Tux Paint is free software / open source but someone (Limited
> Educational Paint) seems to be making a buck or 2 out of it. No idea
> if its legit or not but I wanted to point it out, just in case.
> 
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=51347&item=7149627504&rd=1
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=51347&item=7150089436&rd=1
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=51347&item=7150120237&rd=1
> 

Normally, this wouldn't be an issue, even with the silly name change they've
done to the software.  HOWEVER, the person reporting this to me followed up
with:

> Check the copyright notice at the botton of those pages:
>     Copyright (C) 2004 Limitedsoft Team
>     Copyright (C) 2004 Limitedsoft Educational 4 Kids
>     All Rights Reserved!

So I've just wrote the following in to eBay's Customer Support
(via their "Verified RIghts Owner (VeRO)" page):


  Hello, I'm creator of a software product called "Tux Paint" which is
  released under the GNU General Public License.  I, and a collection of
  other developers, share copyright on the product.

  It has come to my attention that a company using a number of eBay
  seller accounts ("ameri_vendor2005" and "coollam2004"; perhaps others)
  is selling a copy of this software on eBay.  While this would normally
  not be a problem (the GPL license allows redistribution, even for
  profit), I am concerned with the following text shown on the items in
  the eBay auction:

    Copyright (C) 2004 Limitedsoft Team
    Copyright (C) 2004 Limitedsoft Educational 4 Kids
    All Rights Reserved!

  In other words, they're implying that THEY own the copyright to the
  software, which they do not.  The full permissions granted to them as
  a user or distributor is clearly included in the software, and can be
  read online here, if you're interested (again, it's simply the GNU GPL
  license):
  http://www.newbreedsoftware.com/tuxpaint/docs/COPYING.txt

  Can you please ask them to stop asserting copyright on our software?
  Thank you!



Anyone have any other comments/ideas regarding this?  (The same company/sellers
appear to also be selling altered versions of OpenOffice.org and Linux
distributions, and probably a lot more software.)


Also, do people think it's worth mentioning this situation on the Tux Paint
website, to prevent any confusion for people who might somehow stumble
on the eBay items and then hit our website (or vice-versa)???

Thanks!

-- 
-bill!
bi...@ne...      Tonight's Forecast: Dark. Continued darkness
http://newbreedsoftware.com/   until widely scattered light in the morning.

[Tuxpaint-devel] [fwd] Re: [SDL] File paths and portability

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

Dave's "fnkdat" library supports Windows, Linux and FreeBSD,
but not /specifically/ Mac OS X, Solaris or BeOS.

Perhaps we can help improve his library, and at the same time utilize it
in Tux Paint?

-bill!

----- Forwarded message from David MacCormack -----

On Mon, 11 Apr 2005, Marian Schedenig wrote:
>
> What I'm wondering now is: What is the usual way to access these files from
> the program? Use a global define for the data directory and set it
> differently for each platform, like "./" for Windows and
> "/usr/share/games/mygame/" for Linux?
>

Marian,

When faced with the same problem, I wrote this:
   http://www.maccormack.net/~djm/fnkdat/

It may work for you as well.

Dave

----- End forwarded message -----

[Tuxpaint-devel] Comments on Win32 Installer (for use at a school)

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

John and others, can you comment on any of this?

Thanks! :)


> In a Unix environment things are so much simpler, but currently the 
> school uses Windows XP pro. I am able to get everything to work with 
> some extra work and if I could talk them into producing a new image I 
> would only have to tweak the image machine, but unfortunately that's low 
> on their priority list right now, so I have to install and tweak it on 
> every individual machine. Here are the things I wish the installer did:
> 
> 1. It looks as if the installer was written for non pro versions of 
> windows since it installs the program menu for the current user and not 
> for all users. Many installers check for this and either install in the 
> all user area on pro machines or have a check box to install for all users.
> 
> 2. Because we severely limit the student accounts it would be nice if 
> the userdata directory was open to all users. chmod 777 would take care 
> of it, but I don't know what is available from the installer.
> 
> 3. It would be nice to be able to control more of the default options 
> from the installer. It's not a big deal to run the configure program or 
> edit the config file after the install, but it would be more convenient 
> to set these during the installation. Specifically we would like to 
> disable printing.
> 
> If I can help with any of this let me know. I have done some programming 
> over the year, but most of it has been on Unix machines.


My comment on #2 was to try out the 'savedir' Python launcher I was
working on ( ftp://ftp.billsgames.com/unix/x/tuxpaint/savedir ) to see
if that could help.

For #3, I asked if it would be sufficient to, at the end of the
installation process, ask if the user wants to run Tux Paint Config next...
(Seem reasonable?)

I have no idea about #1, since I've only ever used WinXP Professional.
(Well, that and Win95, which was one of my key reasons for switching to
Linux ;^) )

-bill!

[Tuxpaint-devel] Tux Paint for Zaurus

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

Tux Paint 0.9.14 has been patched a little, and built for the Sharp Zaurus
line of Linux-based PDAs.  (SL-C700 and SL-C670, and other 640x480 models).

I've taken the content and downloads from ONO Tetsu's website
( http://www.geocities.jp/ono_tetsu/tuxpaint/ ) from a few days back,
and turned it into a new 'download' page at the Tux Paint website:

  http://www.newbreedsoftware.com/tuxpaint/download/zaurus/

I've also added a photo of Tux Paint on the Zaurus, over in the
screenshots section:

  http://www.newbreedsoftware.com/tuxpaint/screenshots/tuxpaint_zaurus.jpg


Tetsu, I believe I saw you subscribe to this list.  So, if you're here,
I'd be happy to give you access to CVS so that you can update that page
with any additional information.  (Or just tell me what to add, and I'll
do it for you.)

I didn't put your Japanese version up, as I did some minor editing,
reorganization, and PHP-izing of the English version, and didn't want to
blindly mess up the Japanese version.  It'd be nice to have a translated
version of the page, though!

I'd also be happy to make the "Zaurus" page on my website the 'official'
Tux Paint-on-Zaurus site, if you'd like (at least so far as downloads
and instructions go... I don't want to clutter up the download page with
too much more unrelated content!)


Thanks, and enjoy!

-- 
-bill!
bi...@ne...         "I'm anticipating an all-out tactical
http://newbreedsoftware.com/      dog-fight, followed by a light dinner."

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

[Ben A. <sy...@sa...>]

On Wed, 2005-03-23 at 13:32 -0800, Bill Kendrick wrote:
> As mentioned, we have stuff like this, now:
> 
>   #if !defined(_SDL_TTF_H) && !defined(_SDLttf_h)
> 
> which seems to cover the schizophrenia that the SDL header files have been
> going through as they mature. ;^)
> 
> Does THAT not work?

No.  It's a case of bit-rot.  The Tuxpaint in Debian doesn't have that.
Someone tried to build it against a recent SDL, and it broke.  I'm sure
the code above works just fine.  I just haven't done a CVS build in a
while.

> 
> <snip>
> > > The proper way to do this would be to have a configure script
> > > that could then give an error message.
> 
> Ack! No! ;^)
> 
> Or, if so, whoever creates it will need to become adopted by my wife and
> I and live in our spare bedroom, so that when stuff stops working, I'm
> not stuck. ;^)

Hah!  OK.  I concede.  I wouldn't want it to come to that.

> Anyway, if it comes to it, I suppose we can just remove the checks.
> I was TRYING to be friendly, but SDL*.h went and broke things out from
> underneath me. ;^)

So they did.  And that is my final word on it, if anyone asks.  "Sorry,
the build system is correct, it's upstream that broke." :)  (Too bad the
bug is closed now, or I'd add that!)

Ben

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

[Ben A. <sy...@sa...>]

On Wed, 2005-03-23 at 15:40 -0500, Albert Cahalan wrote:
> You'd have to provide a specific example.

Sorry, nothing recent comes to mind, other than this particular bug.

I believe what I'm reacting to is of all of my packages that use SDL,
this is the only one that is broken, and my autotools-based packages
have in general been trouble-free, whereas the hand-rolled build systems
have given me the most trouble.  But I suppose it could fairly be said
that is upstream's problem for defining crappy names (they weren't
prefixed "SDL" originally, so namespace clashes were possible, which
they subsequently fixed,) and nothing to do with the build system we
use.  Reasoning from your perspective, my SDL-using autotools-based
packages get away with it not because autotools is superior, but because
they perform the same check a different way.  If upstream had changed
something different about their package, though, I can easily see the
autotools checks failing and our hand-rolled check succeeding.  It comes
down to luck.

Tuxpaint, however, has been relatively trouble free, thus far, so this
isn't a criticism levelled specifically at Tuxpaint.  I guess it is
possible to make a tight and well-crafted hand-rolled build that works
most of the time on most systems, it's just that very few people
actually do that.  I can imagine, though I have not seen it yet, that it
is also possible to make a horrible mess of a build system using
autotools.

Since I'm not doing the work, I don't have any say in whether Tuxpaint
should use autotools or not anyway.  I thought I saw an opportunity to
make Tuxpaint's build system more robust across a broad spread of
different platforms.  I guess I was mistaken.

Ben

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

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

On Tue, Mar 22, 2005 at 07:46:56PM -0400, Ben Armstrong wrote:
> I believe we added header detection because it was a common problem for
> users to forget to install the dependencies.

#1 most FA'dQ I've seen.  "I installed SDL, but it won't compile!"
(It's due to the fact that libraries like SDL and friends are separated
into separate packages for the 'runtime' stuff (object files), and the
'compile-time' stuff (headers, documentation))


<snip>
> I'll hack my way around it now (probably just by disabling the checks)
> so I can remove this RC bug against tuxpaint as soon as possible, but
> I'd like to know what you guys think our permanent fix should be.
<snip>

As mentioned, we have stuff like this, now:

  #if !defined(_SDL_TTF_H) && !defined(_SDLttf_h)

which seems to cover the schizophrenia that the SDL header files have been
going through as they mature. ;^)

Does THAT not work?


<snip>
> > The proper way to do this would be to have a configure script
> > that could then give an error message.

Ack! No! ;^)

Or, if so, whoever creates it will need to become adopted by my wife and
I and live in our spare bedroom, so that when stuff stops working, I'm
not stuck. ;^)


Anyway, if it comes to it, I suppose we can just remove the checks.
I was TRYING to be friendly, but SDL*.h went and broke things out from
underneath me. ;^)

-- 
-bill!
bi...@ne...         "I'm anticipating an all-out tactical
http://newbreedsoftware.com/      dog-fight, followed by a light dinner."

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

[Albert C. <al...@us...>]

On Wed, 2005-03-23 at 07:58 -0400, Ben Armstrong wrote:
> On Tue, 2005-03-22 at 20:14 -0500, Albert Cahalan wrote:
> > Huh? "proper autotools-based build system"??? That's an oxymoron.
> > (been there, done that, saw the light)
> 
> How do you propose to reliably handle the varying dependency needs
> across a broad number of platforms with ever-changing versions of
> dependencies and relationships between them?  I don't care which build
> system you use.  I'm just pointing out that hand-rolled systems break
> easily.  I believe that in tuxpaint it's a real problem that needs to be
> addressed sooner or later.

You'd have to provide a specific example.

Generally though, one uses what the C programming language
provides. This includes the sizeof operator, <limits.h> and
all the rest. C has these features for a reason you know!

What C can't handle alone is pretty rare. If you should
happen to encounter such a problem, try the $(shell FOO)
function in a Makefile.

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

[Ben A. <sy...@sa...>]

On Tue, 2005-03-22 at 20:14 -0500, Albert Cahalan wrote:
> Huh? "proper autotools-based build system"??? That's an oxymoron.
> (been there, done that, saw the light)

How do you propose to reliably handle the varying dependency needs
across a broad number of platforms with ever-changing versions of
dependencies and relationships between them?  I don't care which build
system you use.  I'm just pointing out that hand-rolled systems break
easily.  I believe that in tuxpaint it's a real problem that needs to be
addressed sooner or later.

Ben

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

[Albert C. <al...@us...>]

On Tue, Mar 22, 2005 at 07:46:56PM -0400, Ben Armstrong wrote:
> I believe we added header detection because it was a common problem for
> users to forget to install the dependencies.  But this has caused
> tuxpaint in Debian to break, which is a release critical bug right on
> the verge of Sarge releasing.  I have to ask at this point if it is
> really worth it, or if we shouldn't put moving tuxpaint to a proper
> autotools-based build system as a higher priority.

Huh? "proper autotools-based build system"??? That's an oxymoron.
(been there, done that, saw the light)

Re: [Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

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

On Tue, Mar 22, 2005 at 07:46:56PM -0400, Ben Armstrong wrote:
> I believe we added header detection because it was a common problem for
> users to forget to install the dependencies.  But this has caused
> tuxpaint in Debian to break, which is a release critical bug right on
> the verge of Sarge releasing.  I have to ask at this point if it is
> really worth it, or if we shouldn't put moving tuxpaint to a proper
> autotools-based build system as a higher priority.
> 
> I'll hack my way around it now (probably just by disabling the checks)
> so I can remove this RC bug against tuxpaint as soon as possible, but
> I'd like to know what you guys think our permanent fix should be.
> 
> Ben
> 
Ben,

I had the same problem when I was getting the MinGW build working and I
just hacked my way through it and checked it into cvs:

#include "SDL_image.h"
#if !defined(_SDL_IMAGE_H) && !defined(_IMG_h)
...
#endif

#include "SDL_ttf.h"
#if !defined(_SDL_TTF_H) && !defined(_SDLttf_h)
...
#endif

#include "SDL_mixer.h"
#if !defined(_SDL_MIXER_H) && !defined(_MIXER_H_)
...
#endif

though this is, clearly, the work of the devil :-)

cheers,
John.

> -------- Forwarded Message --------
> > From: Kurt Roeckx <ku...@ro...>
> > Reply-To: Kurt Roeckx <ku...@ro...>, 30...@bu...
> > To: su...@bu...
> > Subject: Bug#300632: tuxpaint: FTBFS: Changed header files.
> > Date: Sun, 20 Mar 2005 22:33:55 +0100
> > Package: tuxpaint
> > Version: 1:0.9.14-1
> > Severity: serious
> > 
> > Hi,
> > 
> > Your package is no longer building problem.  I get the following error:
> > 
> > ...Compiling Tux Paint from source...
> > src/tuxpaint.c:176:2: #error "---------------------------------------------------"
> > src/tuxpaint.c:177:2: #error "If you installed SDL_image from a package, be sure"
> > src/tuxpaint.c:178:2: #error "to get the development package, as well!"
> > src/tuxpaint.c:179:2: #error "(e.g., 'libsdl-image1.2-devel.rpm')"
> > src/tuxpaint.c:180:2: #error "---------------------------------------------------"
> > src/tuxpaint.c:195:2: #error "---------------------------------------------------"
> > src/tuxpaint.c:196:2: #error "If you installed SDL_mixer from a package, be sure"
> > src/tuxpaint.c:197:2: #error "to get the development package, as well!"
> > src/tuxpaint.c:198:2: #error "(e.g., 'libsdl-mixer1.2-devel.rpm')"
> > src/tuxpaint.c:199:2: #error "---------------------------------------------------"
> > make[1]: *** [obj/tuxpaint.o] Error 1
> > 
> > You do seem to have both mentioned required build dependencies.
> > 
> > The code looks like this:
> > #include "SDL_image.h"
> > #ifndef _IMG_h
> > #error
> > 
> > #include "SDL_mixer.h"
> > #ifndef _MIXER_H_
> > #error
> > 
> > 
> > The first seems to be using _SDL_IMAGE_H (now?) and the
> > second _SDL_MIXER_H.
> > 
> > I find detection of presense of a header file like that a stupid
> > way.  It should not rely on those defines.
> > 
> > The proper way to do this would be to have a configure script
> > that could then give an error message.
> > 
> > 
> > Kurt
> > 
> > 
> -- 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
> Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
> for the chance to win $25,000 and application distribution. Enter today at
> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Tuxpaint-devel] [Fwd: Bug#300632: tuxpaint: FTBFS: Changed header files.]

[Ben A. <sy...@sa...>]

I believe we added header detection because it was a common problem for
users to forget to install the dependencies.  But this has caused
tuxpaint in Debian to break, which is a release critical bug right on
the verge of Sarge releasing.  I have to ask at this point if it is
really worth it, or if we shouldn't put moving tuxpaint to a proper
autotools-based build system as a higher priority.

I'll hack my way around it now (probably just by disabling the checks)
so I can remove this RC bug against tuxpaint as soon as possible, but
I'd like to know what you guys think our permanent fix should be.

Ben

-------- Forwarded Message --------
> From: Kurt Roeckx <ku...@ro...>
> Reply-To: Kurt Roeckx <ku...@ro...>, 30...@bu...
> To: su...@bu...
> Subject: Bug#300632: tuxpaint: FTBFS: Changed header files.
> Date: Sun, 20 Mar 2005 22:33:55 +0100
> Package: tuxpaint
> Version: 1:0.9.14-1
> Severity: serious
> 
> Hi,
> 
> Your package is no longer building problem.  I get the following error:
> 
> ...Compiling Tux Paint from source...
> src/tuxpaint.c:176:2: #error "---------------------------------------------------"
> src/tuxpaint.c:177:2: #error "If you installed SDL_image from a package, be sure"
> src/tuxpaint.c:178:2: #error "to get the development package, as well!"
> src/tuxpaint.c:179:2: #error "(e.g., 'libsdl-image1.2-devel.rpm')"
> src/tuxpaint.c:180:2: #error "---------------------------------------------------"
> src/tuxpaint.c:195:2: #error "---------------------------------------------------"
> src/tuxpaint.c:196:2: #error "If you installed SDL_mixer from a package, be sure"
> src/tuxpaint.c:197:2: #error "to get the development package, as well!"
> src/tuxpaint.c:198:2: #error "(e.g., 'libsdl-mixer1.2-devel.rpm')"
> src/tuxpaint.c:199:2: #error "---------------------------------------------------"
> make[1]: *** [obj/tuxpaint.o] Error 1
> 
> You do seem to have both mentioned required build dependencies.
> 
> The code looks like this:
> #include "SDL_image.h"
> #ifndef _IMG_h
> #error
> 
> #include "SDL_mixer.h"
> #ifndef _MIXER_H_
> #error
> 
> 
> The first seems to be using _SDL_IMAGE_H (now?) and the
> second _SDL_MIXER_H.
> 
> I find detection of presense of a header file like that a stupid
> way.  It should not rely on those defines.
> 
> The proper way to do this would be to have a configure script
> that could then give an error message.
> 
> 
> Kurt
> 
> 
-- 

Re: [Tuxpaint-devel] New Tux Paint mailing lists

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

On Tue, Mar 22, 2005 at 02:39:30PM -0500, Sam Hart wrote:
> I actually wasn't aware that the list was switched to lists.sf.net...
> Bill, was there a technical reason for the switch?

Heh, yeah! :^)  The Tux4Kids.net ones just stopped working.

The admin system still works, and I made sure I wasn't "nomail"'d again,
then I emailed you to ask what's up, but didn't get a response, so I figured
you were super-busy.

Shin-Ichi ended up sending me a personal email with some comments he had
tried to send to tuxpaint-dev as well, so I figured it wasn't me.

I didn't want to harass you about it (though I did consider whois'ing
and calling you on the phone again ;^) ), and figured moving them would just
take one more thing (4 more things?) off of your plate.  It's kind of what
SF.net is there for, anyway ;^)

Also, one thing I missed recently was integrated archives, so that was
another reason I decided to just go ahead and switch. :^)


> Personally, I have never been a fan of the sf.net mailing lists as they
> do all manner of stuff that I don't like (I am a big fan of reply-to
> munging, for example, even if certain vocal opponents try to besmirch
> it).

I've got this list set up as 'reply-to', so maybe they changed something
since you last looked? :)

Note: For me, it's simple enough to set my Mutt up so that [R]eply does
[L]ist-reply by default for these lists, so if we're in the minority,
I'd be willing to consider changing the list settings to no-munging.
(I do NOT want a big flamewar over it, though... I see those almost monthly
on one or another list I'm on! :^) )


So, hopefully, no hard feelings Sam! :^)


-bill!

Re: [Tuxpaint-devel] New Tux Paint mailing lists

[Sam H. <sa...@pr...>]

I actually wasn't aware that the list was switched to lists.sf.net...
Bill, was there a technical reason for the switch?

Personally, I have never been a fan of the sf.net mailing lists as they
do all manner of stuff that I don't like (I am a big fan of reply-to
munging, for example, even if certain vocal opponents try to besmirch
it).

On Tue, 2005-03-22 at 14:02 -0500, Albert Cahalan wrote:
> On Tue, 2005-03-22 at 10:30 -0800, Bill Kendrick wrote:
> > Hello all!  Welcome to the new Tux Paint Developers mailing list
> > (tux...@li...)
> 
> This is still a pretty strange list. I have to manually change
> the address if I want to respond off list. This is awkward
> enough that I sometimes won't bother when I'd normally send a
> quick note to someone. Lots of unimportant stuff ends up on
> the list too.
> 
> Also, people don't get distinct personal replies. I guess this
> isn't terribly important on a low-volume list, but things get
> rough if traffic ever gets to be a few hundred posts per day.
> Then, you really want people using reply-to-all so that people
> can filter the personal copy as high-priority.
> 
> > I'm also considering creating a moderated "tuxpaint-announce" list,
> > simply for announcing new releases, when they come out.
> 
> tuxpaint-news would be shorter

-- 
                                            '''''''''''''''''''''''''
.O.                                         Sam Hart, sa...@pr...
..O                                        Progeny Linux Systems, Inc
OOO                                         <http://www.progeny.com/>

Re: [Tuxpaint-devel] New Tux Paint mailing lists

[Albert C. <al...@us...>]

On Tue, 2005-03-22 at 10:30 -0800, Bill Kendrick wrote:
> Hello all!  Welcome to the new Tux Paint Developers mailing list
> (tux...@li...)

This is still a pretty strange list. I have to manually change
the address if I want to respond off list. This is awkward
enough that I sometimes won't bother when I'd normally send a
quick note to someone. Lots of unimportant stuff ends up on
the list too.

Also, people don't get distinct personal replies. I guess this
isn't terribly important on a low-volume list, but things get
rough if traffic ever gets to be a few hundred posts per day.
Then, you really want people using reply-to-all so that people
can filter the personal copy as high-priority.

> I'm also considering creating a moderated "tuxpaint-announce" list,
> simply for announcing new releases, when they come out.

tuxpaint-news would be shorter

[Tuxpaint-devel] New Tux Paint mailing lists

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

Hello all!  Welcome to the new Tux Paint Developers mailing list
(tux...@li...)

The Tux4Kids lists recently stopped delivering, so I decided to take some
work off of Sam Hart's hands by simply recreating the lists over here at
SourceForge.net.  (This also has the benefit of having centralized archives.)

I've resubscribed everyone who was on 'tuxpaint-dev' onto this new
'tuxpaint-devel' list.  However, I didn't have time to go and adjust users'
settings (e.g., "nodups", "digest", etc.), so if you changed anything from
the defaults, please go in and change them (or send me a note, and when I
have time, I'll adjust your subscription options... just remember: tell me
your subscribed address if it's different from your normal one!)

Later today, as I have time, I'll be resubscribing folks to the new
tuxpaint-commits, tuxpaint-i18n and tuxpaint-stamps lists.
(Or feel free to do so yourself, over at SourceForge.)

Also, I've created a new list, "tuxpaint-users", which will be geared
towards 'end-users' of Tux Paint.  Rather...  the teachers and parents of
those end users, who have questions about Tux Paint, or have specific
features they'd like to see implemented.

I'm also considering creating a moderated "tuxpaint-announce" list,
simply for announcing new releases, when they come out.


Thanks, and enjoy!

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

[Tuxpaint-devel] Testing new list

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

Just a test!

-bill!