Tux Paint

Hi Brendan,

> but it "branched" the existing branches
> under each project. Not pretty. In hindsight it would have been more than
> sufficient to leave the t4kcommon project under root and branch the trunk of
> each project making use of it, separately.

Agree - I think it might not be very feasible to merge e.g.
tux4kids/tuxmath/trunk and
tux4kids/branches/commonification/tuxmath/trunk using svn's merging
feature.  I had a painful experience merging Sarah's GSoC tuxtype
branch with tuxtype's trunk.

> As it is, stuff is so messy right now that I'm not convinced it's even
> salvageable.

I wouldn't go that far - I think libt4k-common is fine.  Last time I
worked on it (maybe two months ago), I had gotten it to build with
autotools as a shared libtool library, and it seemed to install
properly and make a valid tarball with "make dist".  I didn't get
tuxmath to successfully link with it, however, even though the library
appeared to be installed.  However, I pretty much just left it at that
point without any detailed troubleshooting and moved on to other
stuff.

Once someone figures out the linking problem, I would think we could
just start by having the main trunk of tuxmath link to t4k-common but
not actually use it, and then convert one source file at a time to use
the functions in t4k-common instead of e.g. SDL_extras.c.  We could
look at the commonification branch of tuxmath for reference, but not
actually do a svn merge with it.

> In any case, when the dust has settled, here's what I recall remains to be
> done before adopting the common lib (maybe I've missed something):
> -Testing on Win32 and Mac
> -Building/using dynamic (shared) libs
> -Decide on dealing with t4kcommon being unavailable
>
> I think David had mentioned preferring a shared lib to a static one. Was
> there a specific reason for that? Distribution requirements, perhaps?

Yes - the distros really seem to dislike static libs, although what
they really are trying to avoid is having multiple packages each have
their own copy of e.g. libSDL statically linked into the binary.
libt4k-common might be acceptable as a static lib because it belongs
exclusively to our program and is less likely to be used by others.
Nonetheless, if eventually tuxmath, tuxtype, and tuxpaint all use
libt4k-common, I strongly suspect that the distros would want it
packaged separately.

The autotools build of libt4k-common is the first time I've used
libtool, but AFAICT the process is almost identical for building a
shared or static lib, with just a slightly different entry in the
Makefile.am - libtool takes care of the rest.

> The
> extra complexity would mean some additional headaches, I think, especially
> on other platforms.

I have no problem with making libt4k-common a static lib for win32 and
OSX, if it turns out to be easier.


> Oh, git: I've been using git in school, and my experience has been that it's
> _much_ (much!) faster and (after a learning curve) more friendly to merge
> conflicts.

I've been using git-svn for tux4kids for the last several months,
meaning I use git for everything local and git-svn to sync with our
repository.

fwiw, my family is out of town for the next 4 days, giving me an
opportunity to put in more time on this stuff than I've had for a
while.

Best,

David

David,


> > As it is, stuff is so messy right now that I'm not convinced it's even
> > salvageable.
>
> I wouldn't go that far - I think libt4k-common is fine.


That's true, at least :) What I meant was that the substantial work done in
TT and TM will be hard to bring back into their respective trunks, by hand
or with merges.


> Last time I
> worked on it (maybe two months ago), I had gotten it to build with
> autotools as a shared libtool library, and it seemed to install
> properly and make a valid tarball with "make dist".  I didn't get
> tuxmath to successfully link with it, however, even though the library
> appeared to be installed.  However, I pretty much just left it at that
> point without any detailed troubleshooting and moved on to other
> stuff.
>

That's good to hear. I'll see if I can get TM linking properly to a shared
lib. I'm inclined to stick to CMake and leave the autotooling to the
experts, though. Is a libtool library special, or did you just mean you
built with libtool?



> Yes - the distros really seem to dislike static libs, although what
> they really are trying to avoid is having multiple packages each have
> their own copy of e.g. libSDL statically linked into the binary.
>

Fair enough, that's valid.

-Brendan

Hi Brendan,


> That's good to hear. I'll see if I can get TM linking properly to a shared
> lib. I'm inclined to stick to CMake and leave the autotooling to the
> experts, though.

If you know of one, ask him/her to help me with this stuff ;)

> Is a libtool library special, or did you just mean you
> built with libtool?

Built with libtool.  The autotools build of libt4kcommon can be done
from tux4kids/branches/commonification/t4kcommon/trunk with:

autoreconf -i
./configure
make
sudo make install

It creates both libt4kcommon.a (for static linking, I think) and
libt4kcommon.so (for shared linking) as well as some versioning
symlinks and libt4kcommon.la, which is something libtool uses.

The "make install" command also prints the following notice, which
probably tells us what we need to do to get the shared linking working
(I just haven't gotten around to working on it):

==================================

Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.

===============================

Hope this helps.  I'll probably work on this tomorrow.

Best,

David

Hi Brendan,

> Built with libtool.  The autotools build of libt4kcommon can be done
> from tux4kids/branches/commonification/t4kcommon/trunk with:
>
> autoreconf -i
> ./configure
> make
> sudo make install

Well, after an afternoon of puzzlement and RTFMing, I eventually found
that t4k-menu.c had undefined max() and min() functions/macros that
somehow didn't cause errors when I compiled libt4kcommon, but that
caused configure to fail to link libt4kcommon to tuxmath.  After
fixing those, now it works.  Tuxmath in trunk now has an option to
link to libt4kcommon that is disabled by default.  It doesn't do
anything with it yet - none of the files have an #include
t4k-common.h.

To build tuxmath in trunk with the new linkage, first do the above
"./configure; make; sudo make install" for libt4kcommon.  Then build
and install tuxmath with:

./configure --with-libt4kcommon
make
sudo make install

We should now be able to start adapting tuxmath to use the functions
from libt4kcommon.  My only questions are whether we should make
(another) tuxmath branch to do this, and whether we should put out a
tuxmath 1.8.0 "as is" before we get embroiled in the transition to
libt4k.  I'm inclined to push out a new release in the next couple of
days while my family is away.

Best,

David

David,

Cool! I'll take a look at it ASAP. I suppose I'll start (optionally)
adapting TM one function at a time, and polishing the implementation of each
function as I convert it. I'll keep my changes local for today/tomorrow in
case you'd like to do a release (a good idea, IMO). Let's just be extra
careful not to muddle things up, instead of another branching mishap :P

Best,
Brendan

On Sun, Dec 27, 2009 at 9:05 PM, David Bruce <davidstuartbruce@...:

> Hi Brendan,
>
> > Built with libtool.  The autotools build of libt4kcommon can be done
> > from tux4kids/branches/commonification/t4kcommon/trunk with:
> >
> > autoreconf -i
> > ./configure
> > make
> > sudo make install
>
> Well, after an afternoon of puzzlement and RTFMing, I eventually found
> that t4k-menu.c had undefined max() and min() functions/macros that
> somehow didn't cause errors when I compiled libt4kcommon, but that
> caused configure to fail to link libt4kcommon to tuxmath.  After
> fixing those, now it works.  Tuxmath in trunk now has an option to
> link to libt4kcommon that is disabled by default.  It doesn't do
> anything with it yet - none of the files have an #include
> t4k-common.h.
>
> To build tuxmath in trunk with the new linkage, first do the above
> "./configure; make; sudo make install" for libt4kcommon.  Then build
> and install tuxmath with:
>
> ./configure --with-libt4kcommon
> make
> sudo make install
>
> We should now be able to start adapting tuxmath to use the functions
> from libt4kcommon.  My only questions are whether we should make
> (another) tuxmath branch to do this, and whether we should put out a
> tuxmath 1.8.0 "as is" before we get embroiled in the transition to
> libt4k.  I'm inclined to push out a new release in the next couple of
> days while my family is away.
>
> Best,
>
> David
>

On Tue, Dec 22, 2009 at 4:38 PM, Bill Kendrick <nbs@...> wrote:
> On Mon, Nov 16, 2009 at 05:15:37AM -0500, Albert Cahalan wrote:
>> Current status:
>>
>> Lots of stuff is seriously cleaned up.
>
> So where are things now?

It's mostly good I think.

There is a nasty design flaw in the gettext library code.
If a locale is not 100% implemented (currency formats,
telephone formats, etc.) then the locale is forced to C.
The C locale is not UTF-8, and it disables translation.
Also, the default ("" and no environment variables) is C.
None of this is required by any standard; it's just broken.
I have no means to beat the stupid out of gettext/glibc.

The result is that languages like Zapotec are trouble.

Setting LANGUAGE does work, provided that you also
set LC_ALL to some random system-supported locale.
We can essentially call Zapotec a dialect of es_MX.
A trouble with this is that such a setting probably shouldn't
get passed to lpr.

Anybody going to a Linux conference? If so, please find
a glibc or gettext developer to pester in person.

On the bright side, there is potential for fallback languages.

On Sun, Dec 6, 2009 at 5:07 PM, Pere Pujal i Carabantes
<pere@...> wrote:

> Also, there was some problem saving/loading the pixels from a surface
> when it was tinted with some specific color. Now it's just saved the
> alpha channel  and the label generated from it and the stored RGB
> values.
>
> Of course this means that tuxpaint will crash if you try to open a draw
> that has the .label/xxxx.dat file in the old format :(, sorry

Let's get rid of the *.dat file. PNG files can hold this info.

The "iTXt" and "bKGD" chunks are certainly useful.
If needed, we can use a private tag.

On Sun, Dec 06, 2009 at 11:07:27PM +0100, Pere Pujal i Carabantes wrote:
> Of course this means that tuxpaint will crash if you try to open a draw
> that has the .label/xxxx.dat file in the old format :(, sorry

Well, that's really bad. :)  Can you make it store both, with the new
data at the end, so that if it's missing (i.e., because the image was
drawn before 0.9.22) it will simply do it the old way (load via palette
index)?

-bill!

El dl 07 de 12 de 2009 a les 08:32 -0800, en/na Bill Kendrick va
escriure:
> On Sun, Dec 06, 2009 at 11:07:27PM +0100, Pere Pujal i Carabantes wrote:
> > Of course this means that tuxpaint will crash if you try to open a draw
> > that has the .label/xxxx.dat file in the old format :(, sorry
> 
> Well, that's really bad. :)  Can you make it store both, with the new
> data at the end, so that if it's missing (i.e., because the image was
> drawn before 0.9.22) it will simply do it the old way (load via palette
> index)?
> 
Why?, There are not any releases using the .label/xxx.dat file, the only
people that can be anoyed by this change are developpers. Anyway, if
somebody has important label data I can made a tuxpaint.c that loads the
old format then saves in the new one.

Pere

El dg 06 de 12 de 2009 a les 20:35 -0500, en/na Albert Cahalan va
escriure:
> On Sun, Dec 6, 2009 at 5:07 PM, Pere Pujal i Carabantes
> <pere@...> wrote:
> 
> > Also, there was some problem saving/loading the pixels from a surface
> > when it was tinted with some specific color. Now it's just saved the
> > alpha channel  and the label generated from it and the stored RGB
> > values.
> >
> > Of course this means that tuxpaint will crash if you try to open a draw
> > that has the .label/xxxx.dat file in the old format :(, sorry
> 
> Let's get rid of the *.dat file. PNG files can hold this info.
> 
> The "iTXt" and "bKGD" chunks are certainly useful.
> If needed, we can use a private tag.

Do you mean one png for each label? Currently there is no limit for the
number of labels one can put in each draw.
or instead store all the label data in the main png?

Currently in cvs we use:
.tuxpaint/saved/xxxx.png --> the main png whith the labels applied as
plain text.
.tuxpaint/saved/xxxx.dat -->the traditional .dat file (for starter,
mirror...)
.tuxpaint/saved/.label/xxxx.png the image without the labels.
.tuxpaint/saved/.label/xxxx.dat the info about the labels.
.tuxpaint/saved/.thumbs/xxxx.png the thumbnail

It will be good if we reach to reduce the amount of files involved on a
draw.

Pere

BTW the format of the saved/.label/xxxx.dat is currently as follows:
number of labels
width of draw
height of draw

leng of text in first label
text of the label
color R component
color G
color B
label width
label height
label x position
label y position
index of font used in label
Font family
index of text state (bold, italic...)
index of text size
alpha values of each pixel of the label

leng of text in second label...

On Mon, Dec 07, 2009 at 10:58:43PM +0100, Pere Pujal i Carabantes wrote:
> El dl 07 de 12 de 2009 a les 08:32 -0800, en/na Bill Kendrick va
> escriure:
> > On Sun, Dec 06, 2009 at 11:07:27PM +0100, Pere Pujal i Carabantes wrote:
> > > Of course this means that tuxpaint will crash if you try to open a draw
> > > that has the .label/xxxx.dat file in the old format :(, sorry
> > 
> > Well, that's really bad. :)  Can you make it store both, with the new
> > data at the end, so that if it's missing (i.e., because the image was
> > drawn before 0.9.22) it will simply do it the old way (load via palette
> > index)?
> > 
> Why?, There are not any releases using the .label/xxx.dat file, the only
> people that can be anoyed by this change are developpers. Anyway, if
> somebody has important label data I can made a tuxpaint.c that loads the
> old format then saves in the new one.

Oh, I'm sorry, I didn't read carefully enough.  I thought we were
talking about the .dat file for the image itself (which contains info
about the Starter, if any, or background color).

Ignore me. ;)

-bill!

On Tue, Dec 08, 2009 at 12:03:33AM +0100, Pere Pujal i Carabantes wrote:
> Do you mean one png for each label?

Doubtful. :)


> Currently there is no limit for the
> number of labels one can put in each draw.
> or instead store all the label data in the main png?
> 
> Currently in cvs we use:
> .tuxpaint/saved/xxxx.png --> the main png whith the labels applied as
> plain text.
> .tuxpaint/saved/xxxx.dat -->the traditional .dat file (for starter,
> mirror...)
> .tuxpaint/saved/.label/xxxx.png the image without the labels.
> .tuxpaint/saved/.label/xxxx.dat the info about the labels.
> .tuxpaint/saved/.thumbs/xxxx.png the thumbnail
> 
> It will be good if we reach to reduce the amount of files involved on a
> draw.

It would be, but a few things:

(1) is it possible to cram unlimited extra info into a PNG?
    (particularly the label text/position/color/size/etc. data)

(2) other than being a little bit of effort to keep track of
    inside Tux Paint's codebase, who is this bothering?
    (that's a serious question ... in terms of sharing an image to
    your relatives, for example, you just sent them the 'main' PNG;
    do people really share (individual) images across installations
    of Tux Paint?)

Would bundling it all together (either into our own Tux Paint file
format *shudder* or something like a ZIP (like Java JARs or EPUB ebooks))
be more suitable?

Keep in mind we'd want to keep backwards-compatibility, so we'd at least
need to know how to load all of that data, even if we no longer saved
new files out that way.  (And due to that, I feel like it's not worth
the effort.)

-bill!

On Mon, Dec 7, 2009 at 6:15 PM, Bill Kendrick <nbs@...> wrote:
> On Tue, Dec 08, 2009 at 12:03:33AM +0100, Pere Pujal i Carabantes wrote:
>> Do you mean one png for each label?
>
> Doubtful. :)

I didn't realize there could be more than one label.
Not that it matters for label-in-PNG embedding, but
that doesn't seem right as far as UI and concept goes.

>> Currently there is no limit for the
>> number of labels one can put in each draw.
>> or instead store all the label data in the main png?

Everything can go in one file. We can embed arbitrary blobs.

>> It will be good if we reach to reduce the amount of files involved on a
>> draw.
>
> It would be, but a few things:
>
> (1) is it possible to cram unlimited extra info into a PNG?
>    (particularly the label text/position/color/size/etc. data)

Nearly all image formats allow arbitrary blobs.
For sure: PNG, JPEG, TIFF

> (2) other than being a little bit of effort to keep track of
>    inside Tux Paint's codebase, who is this bothering?
>    (that's a serious question ... in terms of sharing an image to
>    your relatives, for example, you just sent them the 'main' PNG;
>    do people really share (individual) images across installations
>    of Tux Paint?)

Consider the OLPC XO using Sugar's Journal. Ideally the
tuxpaint images would be available like anything else.
There are only two ways to make that work. Either we
embed everything in the PNG, or we abstract the extra data
to allow alternate storage mechanisms like Journal metadata.

> Would bundling it all together (either into our own Tux Paint file
> format *shudder* or something like a ZIP (like Java JARs or EPUB ebooks))
> be more suitable?

That makes it inaccessible and slower to load/store.

> Keep in mind we'd want to keep backwards-compatibility, so we'd at least
> need to know how to load all of that data, even if we no longer saved
> new files out that way.  (And due to that, I feel like it's not worth
> the effort.)

It's reasonable to automatically migrate to the new format,
then drop the old format after a couple years.

Even a sudden compatibility loss isn't so terrible though;
as you noted it's primarily the 'main' PNG that people want.

On Tue, Dec 08, 2009 at 05:55:54AM -0500, Albert Cahalan wrote:
> On Mon, Dec 7, 2009 at 6:15 PM, Bill Kendrick <nbs@...> wrote:
> > On Tue, Dec 08, 2009 at 12:03:33AM +0100, Pere Pujal i Carabantes wrote:
> >> Do you mean one png for each label?
> >
> > Doubtful. :)
> 
> I didn't realize there could be more than one label.
> Not that it matters for label-in-PNG embedding, but
> that doesn't seem right as far as UI and concept goes.

What?  Keep in mind we're talking about the new "Label" tool that
allows text to be placed 'over' an image (not becoming part of it).
This is after ~7 years of teachers asking me "how do my students
edit or move the text after they add it?" and my only answer was
"Undo it or erase it by hand". :)


<snip> 
> Nearly all image formats allow arbitrary blobs.
> For sure: PNG, JPEG, TIFF

Ok, cool.  I haven't cared about internals of bitmapped image
formats since I was trying to decode a GIF on my Atari back in
the early 1990s. ;)


<snip>
> Consider the OLPC XO using Sugar's Journal. Ideally the
> tuxpaint images would be available like anything else.
> There are only two ways to make that work. Either we
> embed everything in the PNG, or we abstract the extra data
> to allow alternate storage mechanisms like Journal metadata.

If you load a PNG-full-of-Tux-Paint-junk into another program
(The GIMP, MS Paint, Krita, etc.) and edit it and save it back out,
is it typical for apps to keep that metadata around?  Or does it
vanish the moment the program ignores it during the File->Open process? :)


<snip> 
> It's reasonable to automatically migrate to the new format,
> then drop the old format after a couple years.

Heh, so we could say.  But I'm just discovered Tux Paint 0.9.17 is the
latest version available for Maemo... and it was built this month...!


> Even a sudden compatibility loss isn't so terrible though;
> as you noted it's primarily the 'main' PNG that people want.

That is true.  But honestly, I don't really 'know' my users that well.
(My own son just turned 3, so I'll be learning more _real_ soon :) )

-bill!

On Tue, Dec 8, 2009 at 12:17 PM, Bill Kendrick <nbs@...> wrote:
> On Tue, Dec 08, 2009 at 05:55:54AM -0500, Albert Cahalan wrote:

>> I didn't realize there could be more than one label.
>> Not that it matters for label-in-PNG embedding, but
>> that doesn't seem right as far as UI and concept goes.
>
> What?  Keep in mind we're talking about the new "Label" tool that
> allows text to be placed 'over' an image (not becoming part of it).
> This is after ~7 years of teachers asking me "how do my students
> edit or move the text after they add it?" and my only answer was
> "Undo it or erase it by hand". :)

I don't think that was a bad answer. Not every learning
experience should be fun.

Maybe the tool is misnamed. We now have two tools that
look like they do the same thing. If we didn't have the text tool,
the new tool would be called "text".

To me, a "label" is something that goes outside of the image.
It's pretty much like a caption, header/footer, or title. It could
be used as a window title or filename. Alternately, it's keywords.
All of this has use of course, though it's extra complexity.

>> Consider the OLPC XO using Sugar's Journal. Ideally the
>> tuxpaint images would be available like anything else.
>> There are only two ways to make that work. Either we
>> embed everything in the PNG, or we abstract the extra data
>> to allow alternate storage mechanisms like Journal metadata.
>
> If you load a PNG-full-of-Tux-Paint-junk into another program
> (The GIMP, MS Paint, Krita, etc.) and edit it and save it back out,
> is it typical for apps to keep that metadata around?  Or does it
> vanish the moment the program ignores it during the File->Open
> process? :)

To some extent, this is controlled by the name of the tag.
Tags are 4 letters long. Case distinction is used as 4 bits to
specify things: chunk is critical for decoding, chunk is part
of the standard, chunk is not reserved for future expansion,
chunk may only be copied if no critical chunks have been
modified.

Thus we could use tuXP to discourage keeping the metadata,
or tuXp to encourage it.

Anything that could fit in a standard tag should go there.
Things we could start using: bKGD, iTXt, sBIT, sPLT, tRNS.

>> Even a sudden compatibility loss isn't so terrible though;
>> as you noted it's primarily the 'main' PNG that people want.
>
> That is true.  But honestly, I don't really 'know' my users that well.
> (My own son just turned 3, so I'll be learning more _real_ soon :) )

He may quickly become abnormally good at using Tux Paint.
To have good testers, you need to produce a continuous stream
of children.

El dt 08 de 12 de 2009 a les 09:17 -0800, en/na Bill Kendrick va
escriure:
> On Tue, Dec 08, 2009 at 05:55:54AM -0500, Albert Cahalan wrote:

> > Consider the OLPC XO using Sugar's Journal. Ideally the
> > tuxpaint images would be available like anything else.
> > There are only two ways to make that work. Either we
> > embed everything in the PNG, or we abstract the extra data
> > to allow alternate storage mechanisms like Journal metadata.
> 
> If you load a PNG-full-of-Tux-Paint-junk into another program
> (The GIMP, MS Paint, Krita, etc.) and edit it and save it back out,
> is it typical for apps to keep that metadata around?  Or does it
> vanish the moment the program ignores it during the File->Open process? :)

Who cares? We can provide a plugin for The GIMP, to import/export tuxpaint png
files and convert our stuff to/from gimp entities. We can convert the labels to 
gimp´s text layers or export text layers to tuxpaint labels, even we can embed 
the starter and convert it accordingly, but really, why should we care if other 
apps don´t know about the Tuxpaint file format? Currently they know nothing 
about our .dat files nor our starters.

The only issue I see in embedding all the stuff in one file is the size of that
file, it will be more than the double of the main png, x3 if we embed
too the starter.

Pere

On Thu, Dec 10, 2009 at 4:47 PM, Pere Pujal i Carabantes
<pere@...> wrote:
> El dt 08 de 12 de 2009 a les 09:17 -0800, en/na Bill Kendrick va
> escriure:
>> On Tue, Dec 08, 2009 at 05:55:54AM -0500, Albert Cahalan wrote:

>>> Consider the OLPC XO using Sugar's Journal. Ideally the
>>> tuxpaint images would be available like anything else.
>>> There are only two ways to make that work. Either we
>>> embed everything in the PNG, or we abstract the extra data
>>> to allow alternate storage mechanisms like Journal metadata.
>>
>> If you load a PNG-full-of-Tux-Paint-junk into another program
>> (The GIMP, MS Paint, Krita, etc.) and edit it and save it back out,
>> is it typical for apps to keep that metadata around?  Or does it
>> vanish the moment the program ignores it during the File->Open process? :)
>
> Who cares? We can provide a plugin for The GIMP, to import/export tuxpaint png
> files and convert our stuff to/from gimp entities. We can convert the labels to
> gimp´s text layers or export text layers to tuxpaint labels, even we can embed
> the starter and convert it accordingly, but really, why should we care if other
> apps don´t know about the Tuxpaint file format? Currently they know nothing
> about our .dat files nor our starters.

I care because the older kids want a way out of the captive
file environment. Some may want normal file access, but my
immediate concern is Sugar's Journal.

In the Sugar environment, programs are not supposed to have
access to the filesystem and are not supposed to have their
own storage. The user selects a file first, then this is passed
to the app ("Tux Paint activity") at start-up. If we want to open
a second file, we ask the Sugar services to give the user an
opportunity to select one. I think the user can even do this at
random times, with Tux Paint getting a "here is a file for you!"
message on D-BUS.

Kids want to paint on their photos. Kids want to email their
photos, embed them in those awful school reports, and so on.
Special conversion software, gimp or otherwise, is not OK.

> The only issue I see in embedding all the stuff in one file is the size of that
> file, it will be more than the double of the main png, x3 if we embed
> too the starter.

If we start with a white background and don't add any labels
or other fancy stuff, there must be NOTHING extra. This holds
true no matter how the data is stored.

I think we're way off right now. I saw some stuff in the .labels
directory (which BTW should not be a dotfile) which looked
like uninitialized data in PNG files.

El dv 11 de 12 de 2009 a les 00:16 -0500, en/na Albert Cahalan va
escriure: 
> On Thu, Dec 10, 2009 at 4:47 PM, Pere Pujal i Carabantes
> <pere@...> wrote:
> > El dt 08 de 12 de 2009 a les 09:17 -0800, en/na Bill Kendrick va
> > escriure:
> >> On Tue, Dec 08, 2009 at 05:55:54AM -0500, Albert Cahalan wrote:
> 
> >>> Consider the OLPC XO using Sugar's Journal. Ideally the
> >>> tuxpaint images would be available like anything else.
> >>> There are only two ways to make that work. Either we
> >>> embed everything in the PNG, or we abstract the extra data
> >>> to allow alternate storage mechanisms like Journal metadata.
> >>
> >> If you load a PNG-full-of-Tux-Paint-junk into another program
> >> (The GIMP, MS Paint, Krita, etc.) and edit it and save it back out,
> >> is it typical for apps to keep that metadata around?  Or does it
> >> vanish the moment the program ignores it during the File->Open process? :)
> >
> > Who cares? We can provide a plugin for The GIMP, to import/export tuxpaint png
> > files and convert our stuff to/from gimp entities. We can convert the labels to
> > gimp´s text layers or export text layers to tuxpaint labels, even we can embed
> > the starter and convert it accordingly, but really, why should we care if other
> > apps don´t know about the Tuxpaint file format? Currently they know nothing
> > about our .dat files nor our starters.
> 
I mean that if any other app has _edited_ the png file, then this file
is no more a Tuxpaint png and we should consider it like any other image
that we can import.


> I care because the older kids want a way out of the captive
> file environment. Some may want normal file access, but my
> immediate concern is Sugar's Journal.
> 
> In the Sugar environment, programs are not supposed to have
> access to the filesystem and are not supposed to have their
> own storage. The user selects a file first, then this is passed
> to the app ("Tux Paint activity") at start-up. If we want to open
> a second file, we ask the Sugar services to give the user an
> opportunity to select one. I think the user can even do this at
> random times, with Tux Paint getting a "here is a file for you!"
> message on D-BUS.
> 
> Kids want to paint on their photos. Kids want to email their
> photos, embed them in those awful school reports, and so on.
> Special conversion software, gimp or otherwise, is not OK.

If I understand right, your main concern is having a single file with
all in it.


> 
> > The only issue I see in embedding all the stuff in one file is the size of that
> > file, it will be more than the double of the main png, x3 if we embed
> > too the starter.
> 
> If we start with a white background and don't add any labels
> or other fancy stuff, there must be NOTHING extra. This holds
> true no matter how the data is stored.
> 
> I think we're way off right now. I saw some stuff in the .labels
> directory (which BTW should not be a dotfile) which looked
> like uninitialized data in PNG files.
> 
Yep, I've still not looked in detail at the saving process, basically is
the same as left by GSOC. The more I think on it, the more I am
convinced that it should be changed, but I fail at find a good
alternative.

I am considering from simply store the main png applying the label data
as plain text then discard the label data between sessions, up to store
all the data(image + labels) in a image format that allows multiple
layers, like xcf. Any of the options has its pros and cons.

Pere

On Fri, Dec 11, 2009 at 5:46 PM, Pere Pujal i Carabantes
<pere@...> wrote:
> El dv 11 de 12 de 2009 a les 00:16 -0500, en/na Albert Cahalan va
> escriure:

>> I care because the older kids want a way out of the captive
>> file environment. Some may want normal file access, but my
>> immediate concern is Sugar's Journal.
>>
>> In the Sugar environment, programs are not supposed to have
>> access to the filesystem and are not supposed to have their
>> own storage. The user selects a file first, then this is passed
>> to the app ("Tux Paint activity") at start-up. If we want to open
>> a second file, we ask the Sugar services to give the user an
>> opportunity to select one. I think the user can even do this at
>> random times, with Tux Paint getting a "here is a file for you!"
>> message on D-BUS.
>>
>> Kids want to paint on their photos. Kids want to email their
>> photos, embed them in those awful school reports, and so on.
>> Special conversion software, gimp or otherwise, is not OK.
>
> If I understand right, your main concern is having a single file with
> all in it.

Sort of. The needs are:

1. one file as seen from Sugar's "Journal" file manager
2. trivial to import into other software

An alternative to putting the extra data into the main PNG would
be to have plugins for different ways of storing metadata. Win32
could use alternate file streams or extended attributes for this.
OS/2 could use extended attributes. MacOS could use resource
forks. Linux has something like that too, called xattr I think.
I think the Journal can accept a blob of XML, but I'm not sure.
BeOS certainly has the ability. Files would be the fallback.

I have a feeling that the alternative would be trouble.

> I am considering from simply store the main png applying the label data
> as plain text then discard the label data between sessions, up to store
> all the data(image + labels) in a image format that allows multiple
> layers, like xcf. Any of the options has its pros and cons.

Idea: apply the label to the main PNG, but also supply undo info.
When the image is loaded in Tux Paint, the undo info is applied
to recover the unlabled image.

On Sat, Dec 12, 2009 at 12:23:37AM -0500, Albert Cahalan wrote:
> 1. one file as seen from Sugar's "Journal" file manager
> 2. trivial to import into other software

Time for PhysFS?

-bill!