tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Thu, May 22, 2008 at 03:06:26AM -0400, Albert Cahalan wrote:
> Choose a brush. A fat one is the default. Paint with it.
> As you paint, a stamp is created. Nothing appears in
> the main canvas as you paint. When you like the stamp,
> simply select it and use it. It works like any normal stamp.
> There is no "cut" operation, and the "copy" operation
> happens implicitly as soon as you start to paint.

So if you select too much, how do you unselect, to get the 'perfect shape'?

Also, I think for kids who are drawing something sparse -- i.e., most of
their picture is background color -- a one-fell-swoop selection (like
rect, ellipse or lasso), with the addition of a 'snap to shape' would be
very useful for duplicating something they just drew.

Unfortunately, I see many ways of complicating the GUI, so I'd better
sit down and think about this more when I'm not doing 3 other things at
the same time. :)

-bill!

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Wed, May 21, 2008 at 8:00 PM, Bill Kendrick <nb...@so...> wrote:
> On Wed, May 21, 2008 at 04:38:15PM -0700, Mark K. Kim wrote:
>> On Wed, May 21, 2008 at 03:01:35AM -0400, Albert Cahalan wrote:

>>> I don't want ANY of those selection operations.
>>
>> I agree.  Too complicated = bad in kids apps.
>>
>> Having said that, it's really up to the users.  But I do agree with
>> Albert that the current plans for the selection tool may be a little too
>> much and needs to slim down a bit.  Just a thought.
>
> Well, we have less than a week before our GSoC students are to begin
> full-time work on Tux Paint!  Let's try to iron it out before then.
>
> Albert, step me through how a user makes a single selection.
> To me, it would seem easier for _most_ things to be able to simply
> 'draw around it' (i.e., Lasso tool we all know and love).  For large
> objects, having to paint every inch of it seems tedious. :^/

Choose a brush. A fat one is the default. Paint with it.
As you paint, a stamp is created. Nothing appears in
the main canvas as you paint. When you like the stamp,
simply select it and use it. It works like any normal stamp.
There is no "cut" operation, and the "copy" operation
happens implicitly as soon as you start to paint.

That seems to avoid the problem of weird hidden state
and tools that seem to do nothing.

My use of complicated stuff:

I don't use the Lasso tool all that much. When working in
the gimp, I mostly just paint on a layer mask. Generally I
will have a green or magenta layer underneath the one I'm
working on. I use regular tools to paint on the layer mask.
Usually the mask is being applied as I work, so I'm seeing
my image appear/disappear as I paint. Sometimes I paint
while the layer mask is inactive, so I can't see anything
happen as I paint. Sometimes I view the layer mask as
itself while I paint.

For GUI mock-ups, I've used rectangle select and
elliptical select. I did this once, a couple years ago,
when designing the current Tux Paint color ovals.

For abusing gimp as a font editor, I've used rectangle
select and lasso select. Here I frequently drag the
selection: select, click inside and drag, click outside
to deselect.

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Wed, May 21, 2008 at 04:38:15PM -0700, Mark K. Kim wrote:
> On Wed, May 21, 2008 at 03:01:35AM -0400, Albert Cahalan wrote:
> > I don't want ANY of those selection operations.
> 
> I agree.  Too complicated = bad in kids apps.
> 
> Having said that, it's really up to the users.  But I do agree with
> Albert that the current plans for the selection tool may be a little too
> much and needs to slim down a bit.  Just a thought.

Well, we have less than a week before our GSoC students are to begin
full-time work on Tux Paint!  Let's try to iron it out before then.

Albert, step me through how a user makes a single selection.
To me, it would seem easier for _most_ things to be able to simply
'draw around it' (i.e., Lasso tool we all know and love).  For large
objects, having to paint every inch of it seems tedious. :^/

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

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Wed, May 21, 2008 at 03:01:35AM -0400, Albert Cahalan wrote:
> I don't want ANY of those selection operations.

I agree.  Too complicated = bad in kids apps.

Having said that, it's really up to the users.  But I do agree with
Albert that the current plans for the selection tool may be a little too
much and needs to slim down a bit.  Just a thought.

-Mark

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

I don't want ANY of those selection operations.
It's way too complicated, and not even all that
useful. Those options take up space that could
instead be used for the user-created stamps.
Quickmask can do everything, and it works well.
There is no need for a "cut" operation either.

Good UI: just like the Stamps tool, except that
one column of buttons is brush sizes. When you
start painting, a new stamp is allocated. I guess
there needs to be a delete button too.

I also don't want any sort of persistent selection.
Once you leave the tool, the selection must go.

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Tue, May 20, 2008 at 02:00:04AM -0400, Reilly Watson wrote:
> Albert, this is a nice idea, it's basically what I had in mind for
> selection.  I would also like some facility for turning one of these
> selections into a regular stamp.
> 
> Bill, I'm still not that keen on having Add/Remove Selection tools.  I
> think multiple selection adds a lot of UI complexity without enough to
> gain from it.  I love the elegance of being able to make a selection
> with a hole in it, but I'm concerned it comes at the expense of having
> some kids not use selections at all because they're bewildered by all
> the buttons.  That said, it's something I'm not against trying out to
> see what actual kids think of it.

I'm also not unwilling to make the 'remove from selection' tools something
that can be disabled for the younger users...

-bill!

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

[Reilly W. <rei...@gm...>]

Albert, this is a nice idea, it's basically what I had in mind for
selection.  I would also like some facility for turning one of these
selections into a regular stamp.

Bill, I'm still not that keen on having Add/Remove Selection tools.  I
think multiple selection adds a lot of UI complexity without enough to
gain from it.  I love the elegance of being able to make a selection
with a hole in it, but I'm concerned it comes at the expense of having
some kids not use selections at all because they're bewildered by all
the buttons.  That said, it's something I'm not against trying out to
see what actual kids think of it.

On 5/17/08, Bill Kendrick <nb...@so...> wrote:
> On Sun, May 11, 2008 at 06:30:11PM -0400, Albert Cahalan wrote:
>> Usage: Choose the select tool. Start painting. As you
>> paint, you get an outline just like the stamp ones.
>> There might be a stamp slot that fills in when you do
>> this, and maybe an opportunity to save it as a regular
>> stamp. Maybe there is more than one slot, with the
>> select tool overwriting the oldest one or causing the
>> list to scroll. Choose the fresh new stamp to use it.
>> Probably there should be a shrink-to-fit operation that
>> gets rid of excess background.
>
> A lot of this is not too far from what I had envisioned:
>
>   http://www.sonic.net/~nbs/tp-selection-mockup.png
>
> --
> -bill!
> bi...@ne...
> http://www.newbreedsoftware.com/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Sun, May 11, 2008 at 06:30:11PM -0400, Albert Cahalan wrote:
> Usage: Choose the select tool. Start painting. As you
> paint, you get an outline just like the stamp ones.
> There might be a stamp slot that fills in when you do
> this, and maybe an opportunity to save it as a regular
> stamp. Maybe there is more than one slot, with the
> select tool overwriting the oldest one or causing the
> list to scroll. Choose the fresh new stamp to use it.
> Probably there should be a shrink-to-fit operation that
> gets rid of excess background.

A lot of this is not too far from what I had envisioned:

  http://www.sonic.net/~nbs/tp-selection-mockup.png

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

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Sun, May 11, 2008 at 05:33:25PM -0600, Martin Fuhrer wrote:
> Interesting idea.  One could provide a variety of paint brush tools to  
> paint/select over regions using different brush patterns.  Reilly, any  
> thoughts on this?

I think this would be great, but as long as we also have some of the
slightly more traditional tools (lasso, rect/oval) too.

-bill!

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

[Martin F. <mf...@gm...>]

Interesting idea.  One could provide a variety of paint brush tools to  
paint/select over regions using different brush patterns.  Reilly, any  
thoughts on this?

Martin

On 11-May-08, at 4:30 PM, Albert Cahalan wrote:

> I think the most kid-friendly way is to do something
> like the gimp's quickmask mode.
>
> Usage: Choose the select tool. Start painting. As you
> paint, you get an outline just like the stamp ones.
> There might be a stamp slot that fills in when you do
> this, and maybe an opportunity to save it as a regular
> stamp. Maybe there is more than one slot, with the
> select tool overwriting the oldest one or causing the
> list to scroll. Choose the fresh new stamp to use it.
> Probably there should be a shrink-to-fit operation that
> gets rid of excess background.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Tuxpaint-devel] cut-and-paste, copy-and-paste

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

I think the most kid-friendly way is to do something
like the gimp's quickmask mode.

Usage: Choose the select tool. Start painting. As you
paint, you get an outline just like the stamp ones.
There might be a stamp slot that fills in when you do
this, and maybe an opportunity to save it as a regular
stamp. Maybe there is more than one slot, with the
select tool overwriting the oldest one or causing the
list to scroll. Choose the fresh new stamp to use it.
Probably there should be a shrink-to-fit operation that
gets rid of excess background.

[Tuxpaint-devel] magic idea: goo (any GSoC student feel like it?)

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

This is a paint-with-goo brush. It would be easiest
as a magic tool, but might be even better as some
sort of check-box tool option for regular painting.

The idea is to paint with something that looks like
toothpaste, puffy fabric paint, caulk, or similar.
You need highlights and shadows. Painting in grey
might look somewhat like metal, or just grey goo.

Painting could work like this:

As the brush moves, it paints to a hidden greyscale
canvas. Updates to the main canvas are computed
from the hidden canvas. The hidden canvas is disposed
of when the mouse button is released, or possibly when
switching tools. (the choice makes some drawings
easier at the expense of others; it determines if mouse
release causes a new layer of goo on top of the old one)
The hidden layer should be linear, not sRGB.

Goo rendering is like an emboss operation, but tinted.
(see the tinter code for making a pallete; do NOT run
the tinter code for every pixel)

Apply a gaussian blur to the hidden layer. You could
save this data, but you won't be needing it later so it
is better to not save it. Compute the normal vector of
the height field of the blurred data. Compute the angle
between this vector and a vector that points to the
light source. (presumed to be toward the top of the
drawing, probably not to either side or maybe you
should localize this for RTL/LTR languages, probably
with the light source at infinity, probably with the light
source elevated at 45 degrees)

Use that angle as an index into a color look-up table.
The table is the one I hinted at above, generated from
running the tinter code for all brightness values. The
table should already be in sRGB form, avoiding the
need to do a conversion for every pixel.

Mask the output against the hidden canvas. You will
want to do this earlier of course, allowing you to avoid
doing calculations for data that will not be used.

[Tuxpaint-devel] plug-in API changes

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

I'm planning to change things as follows. I hope it
does not cause trouble for anybody. Let me know
if you see any problems.

//////////////////////////////////////////
static int bigbricks_click(int x, int y, SDL_Rect * update_rect){
    ....
}

static int smallbricks_click(int x, int y, SDL_Rect * update_rect){
    ....
}

static int bigbricks_release(int x, int y, SDL_Rect * update_rect){
    ....
}

static int smallbricks_release(int x, int y, SDL_Rect * update_rect){
    ....
}

static struct fns{
    .click = bigbricks_click;
    .release = bigbricks_release;
    ...
}bigbricks;

static struct fns{
    .click = smallbricks_click;
    .release = smallbricks_release;
    ...
}smallbricks;

// see below for what PLUG_FUNCTION is about
void PLUG_FUNCTION init(...){
    register_magic(&bigbricks);
    register_magic(&smallbricks);
}
////////////////////////////////////////

Note that left-out functions become NULL. The core
can substitute do-nothing functions as required, or
just check for NULL. (checking at every call is messier
there, but would allow for a const struct that can be
directly used)

The tools call directly into the core. To enable this,
various core functions are marked for export, essentially
like this:

#ifdef WIN32
__declspec(dllexport)
#else
__attribute__((visibility(default)))
#endif

(with a proper define of course, under Makefile control)

That should allow hidden visibility to work, which will
slightly improve start-up performance.

The real goal here is to simplify the problem of making
it possible to build Tux Paint with all the tools compiled in.

Re: [Tuxpaint-devel] Messenger.h??

[lee y. <yor...@gm...>]

Thanks John.
I sugguest  adding the link"http://johnnypops.demon.co.uk/mingw/index.html"
in Sourceforge or Tux's home page, For some windows users:)

Re: [Tuxpaint-devel] Messenger.h??

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

Hi Lee,

Tux Paint doesn't compile with VC6 or any of the Microsoft compilers (as
far as I know).

We cross-compile it using the MinGW/MSYS tools. Here's a page detailing
the (arduous) procedure:

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

You've reminded me that I need to put together a set of binaries so that
Tux Paint can be built without having to build all the libs first,

regards,
John.

On Mon, May 05, 2008 at 07:58:48PM +0800, lee york wrote:
> Hello everyone,
> compiled tux in vc6.0,error:
> fatal error C1083: Cannot open include file: 'Messenger.h': No such file or
> directory
> Messenger,A lib's file?

> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Messenger.h??

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

On Mon, May 5, 2008 at 7:58 AM, lee york <yor...@gm...> wrote:
> Hello everyone,
> compiled tux in vc6.0,error:

vc6.0 is horribly old and broken

AFAIK, gcc is used for all ports now. We might as well
admit this, allowing the use of C99 code.

[Tuxpaint-devel] Messenger.h??

[lee y. <yor...@gm...>]

Hello everyone,
compiled tux in vc6.0,error:
fatal error C1083: Cannot open include file: 'Messenger.h': No such file or
directory
Messenger,A lib's file?

[Tuxpaint-devel] Rép. : Re: Tuxpaint compiling from source

[Francois L. <fle...@ce...>]

Thanks for the tips.

I've finally found someone that had already compile v9.18 (ok for me !) for Slackware with all libs.

See here: http://zur.zenwalk.org/view/package/name/tuxpaint

Thanks,

Francois

>>> Bill Kendrick <nb...@so...> 03/05/08 19:36 >>>
On Wed, Apr 30, 2008 at 10:21:14AM -0400, Francois Legault wrote:
<snip>
>    SDL_Pango-0.1.2 (also tried 0.1.1)
<snip>
>    When I try "make" It tell me that:
>    ##########################
>    bash-3.1# make
>     
>    ...Linking Tux Paint...
>    obj/tuxpaint.o: In function `wordwrap_text_ex':
>    tuxpaint.c:(.text+0x661e): undefined reference to
>    `SDLPango_SetText_GivenAlignment'
>    obj/fonts.o: In function `TuxPaint_Font_OpenFont':
>    fonts.c:(.text+0x1902): undefined reference to
>    `SDLPango_CreateContext_GivenFontDesc'
>    collect2: ld returned 1 exit status
>    make: *** [tuxpaint] Error 1
>    bash-3.1#
>    ############################

Interesting, I see this in my SDL_pango.h on Ubuntu 8.04:

/*! @file
    @brief Header file of SDL_Pango

    @author NAKAMURA Ken'ichi
    @date   2004/08/26
    $Revision: 1.3 $
*/
....
extern DECLSPEC void SDLCALL SDLPango_SetText_GivenAlignment(
    SDLPango_Context *context,
    const char *text,
    int length,
    SDLPango_Alignment alignment);


Do you have an older Pango installed, not from source?  Perhaps Tux Paint
is picking that up?  (e.g., in /usr/lib vs. /usr/local/lib)

Search your system for "libSDL_Pango*" :)


>    If I try "make" with flag to disable PANGO support it don't work eighter. 
>    It tell me that:
>    #############################
>    bash-3.1# make NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB=
>    ...Linking Tux Paint...
>    obj/tuxpaint.o: In function `wordwrap_text_ex':
>    tuxpaint.c:(.text+0x65ce): undefined reference to
>    `SDLPango_SetDefaultColor'
<snip>

Ah, do a "make clean" first, so that it recompiles without Pango.
You had compiled, and it was alright, but the linking step failed.
At this rate, it's still trying to link with what you had compiled before,
WITHOUT disabling pango support in Tux Paint.

Good luck!

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

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tuxpaint-devel mailing list
Tux...@li...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Tuxpaint compiling from source

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

On Wed, Apr 30, 2008 at 10:21:14AM -0400, Francois Legault wrote:
<snip>
>    SDL_Pango-0.1.2 (also tried 0.1.1)
<snip>
>    When I try "make" It tell me that:
>    ##########################
>    bash-3.1# make
>     
>    ...Linking Tux Paint...
>    obj/tuxpaint.o: In function `wordwrap_text_ex':
>    tuxpaint.c:(.text+0x661e): undefined reference to
>    `SDLPango_SetText_GivenAlignment'
>    obj/fonts.o: In function `TuxPaint_Font_OpenFont':
>    fonts.c:(.text+0x1902): undefined reference to
>    `SDLPango_CreateContext_GivenFontDesc'
>    collect2: ld returned 1 exit status
>    make: *** [tuxpaint] Error 1
>    bash-3.1#
>    ############################

Interesting, I see this in my SDL_pango.h on Ubuntu 8.04:

/*! @file
    @brief Header file of SDL_Pango

    @author NAKAMURA Ken'ichi
    @date   2004/08/26
    $Revision: 1.3 $
*/
...
extern DECLSPEC void SDLCALL SDLPango_SetText_GivenAlignment(
    SDLPango_Context *context,
    const char *text,
    int length,
    SDLPango_Alignment alignment);


Do you have an older Pango installed, not from source?  Perhaps Tux Paint
is picking that up?  (e.g., in /usr/lib vs. /usr/local/lib)

Search your system for "libSDL_Pango*" :)


>    If I try "make" with flag to disable PANGO support it don't work eighter. 
>    It tell me that:
>    #############################
>    bash-3.1# make NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB=
>    ...Linking Tux Paint...
>    obj/tuxpaint.o: In function `wordwrap_text_ex':
>    tuxpaint.c:(.text+0x65ce): undefined reference to
>    `SDLPango_SetDefaultColor'
<snip>

Ah, do a "make clean" first, so that it recompiles without Pango.
You had compiled, and it was alright, but the linking step failed.
At this rate, it's still trying to link with what you had compiled before,
WITHOUT disabling pango support in Tux Paint.

Good luck!

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

[Tuxpaint-devel] Tuxpaint compiling from source

[Francois L. <fle...@ce...>]

Hi,
 
I'm new to tuxpaint and compiling in general.  Don't know If I'm at the
right place but I am experiencigng some problem.
 
I'm trying to get the latest tuxpaint running on SLAX live disto (based
on slackware)
 
I have compiled and installed all needed lib but I'm still getting an
error about SDL_Pango when I run "make" for tuxpaint.
 
Lib that I have installed from source:
 
SDL-1.2.13
SDL_image 1.2.5
SDL_mixer-1.2.8
SDL_Pango-0.1.2 (also tried 0.1.1)
SDL_ttf-2.0.9
 
Pango-1.21.0 (Also tried 1.19.4 and 1.20.2)
Libsrvg-2.22.2
Libpng-1.2.27
Libpaper-1.1.23
GTK+-2.20.14
Gettext-0.17
Cairo 1.6.4
 
When I try "make" It tell me that:
##########################
bash-3.1# make
 
...Linking Tux Paint...
obj/tuxpaint.o: In function `wordwrap_text_ex':
tuxpaint.c:(.text+0x661e): undefined reference to
`SDLPango_SetText_GivenAlignment'
obj/fonts.o: In function `TuxPaint_Font_OpenFont':
fonts.c:(.text+0x1902): undefined reference to
`SDLPango_CreateContext_GivenFontDesc'
collect2: ld returned 1 exit status
make: *** [tuxpaint] Error 1
bash-3.1#
############################
 
 
If I try "make" with flag to disable PANGO support it don't work
eighter.  It tell me that:
#############################
bash-3.1# make NOPANGOFLAG=NO_SDLPANGO SDL_PANGO_LIB=
 
...Linking Tux Paint...
obj/tuxpaint.o: In function `wordwrap_text_ex':
tuxpaint.c:(.text+0x65ce): undefined reference to
`SDLPango_SetDefaultColor'
tuxpaint.c:(.text+0x65ef): undefined reference to
`SDLPango_SetMinimumSize'
tuxpaint.c:(.text+0x6604): undefined reference to
`SDLPango_SetBaseDirection'
tuxpaint.c:(.text+0x661e): undefined reference to
`SDLPango_SetText_GivenAlignment'
tuxpaint.c:(.text+0x6629): undefined reference to
`SDLPango_CreateSurfaceDraw'
tuxpaint.c:(.text+0x6687): undefined reference to
`SDLPango_SetDefaultColor'
tuxpaint.c:(.text+0x66a8): undefined reference to
`SDLPango_SetMinimumSize'
tuxpaint.c:(.text+0x66d5): undefined reference to
`SDLPango_SetBaseDirection'
obj/tuxpaint.o: In function `do_render_cur_text':
tuxpaint.c:(.text+0x7ee1): undefined reference to
`SDLPango_SetDefaultColor'
tuxpaint.c:(.text+0x806f): undefined reference to `SDLPango_SetText'
tuxpaint.c:(.text+0x807b): undefined reference to
`SDLPango_CreateSurfaceDraw'
obj/tuxpaint.o: In function `render_text':
tuxpaint.c:(.text+0x11e47): undefined reference to
`SDLPango_SetDefaultColor'
tuxpaint.c:(.text+0x11e55): undefined reference to `SDLPango_SetText'
tuxpaint.c:(.text+0x11e5e): undefined reference to
`SDLPango_CreateSurfaceDraw'
obj/tuxpaint.o: In function `main':
tuxpaint.c:(.text+0x1af1e): undefined reference to `SDLPango_Init'
obj/fonts.o: In function `charset_works':
fonts.c:(.text+0x2ab): undefined reference to
`SDLPango_SetDefaultColor'
fonts.c:(.text+0x2bc): undefined reference to `SDLPango_SetText'
fonts.c:(.text+0x2c8): undefined reference to
`SDLPango_CreateSurfaceDraw'
obj/fonts.o: In function `TuxPaint_Font_OpenFont':
fonts.c:(.text+0x1902): undefined reference to
`SDLPango_CreateContext_GivenFontDesc'
obj/fonts.o: In function `TuxPaint_Font_CloseFont':
fonts.c:(.text+0x1b47): undefined reference to `SDLPango_FreeContext'
collect2: ld returned 1 exit status
make: *** [tuxpaint] Error 1
bash-3.1# 
###############################
 
 
Could someone help me with this?
 
Thank you,
 
François
 

Re: [Tuxpaint-devel] Opportunity for Tux Paint at "Free Knowledge, Free Technology", July 15-17 in Barecelona, Spain

[Pere P. i C. <pe...@fo...>]

Hi!

El dl 28 de 04 de 2008 a les 10:06 -0700, en/na Bill Kendrick va
escriure:
> I recently discovered the "Free Knowledge, Free Technology" (FKFT) conference,
> a new, international conference whose tagline is: "Education for a free
> information society".
> 
> It takes place between July 15th and 17th, 2008, in Barecelona, Spain.

I've never participated on this kind of events. What is suposed one has
to do?


I can go down to Barcelona in those dates, but...



> and:
> 
>   http://fkft.eu/en/submissions

>From here:
Communications must be presented in English.
               ^^^^
My speaked english is close to NULL

Is there a chance to speak in catalan, spanish or french?


Yours
Pere

[Tuxpaint-devel] Opportunity for Tux Paint at "Free Knowledge, Free Technology", July 15-17 in Barecelona, Spain

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

I recently discovered the "Free Knowledge, Free Technology" (FKFT) conference,
a new, international conference whose tagline is: "Education for a free
information society".

It takes place between July 15th and 17th, 2008, in Barecelona, Spain.
Here's their announcement:

  http://fkft.eu/en/announcement


I contacted them to ask whether it was too late to have Tux Paint, or
Tux4Kids in general, participate, and they said no, and encouraged us to
do so.  They recently extended the deadline for their Call for Papers,
but even so, the deadline is in TWO DAYS: April 30th.  See this page:

  http://fkft.eu/en/CFP

and:

  http://fkft.eu/en/submissions


Would anyone here be willing to participate in this event, to talk about
Tux Paint, and/or TuxMath and/or Tux Typing?

(Two years ago, I lucked out, and found someone in France who was able
to go to the Libre Graphics Meeting and represent Tux Paint for me. :) )

Thanks in advance,

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

Re: [Tuxpaint-devel] GSoC student introduction

[vudem a. <aru...@gm...>]

Hi all,

Congratulations to all my fellow students! I am working on a text
manipulation patch for Tuxpaint under Mark. Looking forward to working with
all of you.

Arunodai

Re: [Tuxpaint-devel] Hello and SCM question

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

On Wed, Apr 23, 2008 at 05:54:50PM -0400, Reilly Watson wrote:
>    I was wondering how you guys wanted to handle we students regarding CVS.
>     Did you just want to give us all write access (my SF username is
>    reillywatson), did you want us to submit changes to (this list|our
>    mentors|some whole other place) for review, or would you like that to be
>    negotiated individually between each student/mentor pair?  I have a few
>    things written that are (I think) ready to go.

We already had a discussion about this (surprise surprise!) and most of
the mentors feel that it would not be prudent to give new contributors
write access immediately.  Other than that we left it up to the
student/mentor pair to decide how to proceed.

For my student and I, we will be using a new repository on
code.google.com.  There are several benefits to this:

  1. We can still use a version control system, which will be useful for
  new OSS contributrs to learn.

  2. Google should be more willing to offer up their repository since they
  sponsor GSoC.  Souceforge and Savannah would not likely allow us to
  create new repositories just for a summer.

  3. We will be using Subversion rather than CVS =)

  4. Most importantly, the student's work will be kept in one place, so
  it will be easier to submit a single diff at the end of the summer,
  required by GSoC.

Obviously, at the end of the summer, if we feel that the patch is
beneficial (which is most likely), we will merge the patch into the main
branch and give the student a write access to continue to develop on Tux
Paint.

-Mark

[Tuxpaint-devel] Hello and SCM question

[Reilly W. <rei...@gm...>]

Hello, I'm Reilly, I'll be working on adding selection tools for TuxPaint as
part of SoC.  I think all the mentors have received an introductory email
from me already, but if you are not them then hello.
I was wondering how you guys wanted to handle we students regarding CVS.
 Did you just want to give us all write access (my SF username is
reillywatson), did you want us to submit changes to (this list|our
mentors|some whole other place) for review, or would you like that to be
negotiated individually between each student/mentor pair?  I have a few
things written that are (I think) ready to go.