Re: Tuxpaint UI Refresh

[Andrew-260]

Hi Guys,

First of all I want to say what a great job you have done creating Tuxpaint it is a great and fun
to use application :-)

I was using Tuxpaint recently and I thought that it's UI could use an artistic refresh, so I set to
work creating a new UI based on the Tango Icon style.

The results of my work can be seen below:

Screenshot of UI:
http://i38.tinypic.com/jsdims.png

Screenshot of UI in use:
http://i35.tinypic.com/dra6vl.png

All of my work is licensed under GPL and if you want to use it I would be very happy to supply
the SVG source and the individually exported images :-)

Comments, criticisms etc. please!

--
Andrew

Sunday, 11th October 2009

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Gabriel Gazzán-2]

Hi guys,

Playing with the last released version of Tux Paint I've discovered that in
the Puzzle like (I don't know its exact name) starter image when you try to
use the bucket fill on one of the lower right pieces to colorize it, the
paint pours to other pieces.
There must be a hole in some place, I guess...

Greetings,
Gabriel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Gabriel Gazzán-2]

I'm definetly in favor of a UI look redesign.
I don't know if this one or any other, but it's needed I think.


El Dom 11 Oct 2009 06:34, Andrew escribió:

> Hi Guys,
>
> First of all I want to say what a great job you have done creating Tuxpaint
> it is a great and fun to use application :-)
>
> I was using Tuxpaint recently and I thought that it's UI could use an
> artistic refresh, so I set to work creating a new UI based on the Tango
> Icon style.
>
> The results of my work can be seen below:
>
> Screenshot of UI:
> http://i38.tinypic.com/jsdims.png
>
> Screenshot of UI in use:
> http://i35.tinypic.com/dra6vl.png
>
> All of my work is licensed under GPL and if you want to use it I would be
> very happy to supply the SVG source and the individually exported images
> :-)
>
> Comments, criticisms etc. please!
>
> --
> Andrew
>
> Sunday, 11th October 2009
>
> ---------------------------------------------------------------------------
>--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Tuxpaint-devel mailing list
> Tuxpaint-devel@...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 11, 2009 at 11:54:08AM -0200, Gabriel Gazzán wrote:
> I'm definetly in favor of a UI look redesign.
> I don't know if this one or any other, but it's needed I think.

I honestly still enjoy the 'gem' style buttons.  This (and others I've seen)
look way too flat.

However, Tux Paint needs theme functionality.  And in any case, it also
needs most, if not all, of its icons redrawn.  Preferably as SVGs so that
we can scale them (for when the UI itself can support larger buttons).

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 11, 2009 at 11:51:24AM -0200, Gabriel Gazzán wrote:
> Hi guys,
>
> Playing with the last released version of Tux Paint I've discovered that in
> the Puzzle like (I don't know its exact name) starter image when you try to
> use the bucket fill on one of the lower right pieces to colorize it, the
> paint pours to other pieces.
> There must be a hole in some place, I guess...

The image itself is fine, but the way we're scaling it causes a gap on the
right.  (The 'smudge' effect on the edges should be taking care of this.)

In any case, replacing these with SVGs (and most other lineart Starters)
would be really useful.  If I'm reading this right, it looks like
our builds for RedHat 6.2, 7.3 and 8.0 lack any kind of SVG support.
All the rest use one or the other sets of SVG support libs.

I'll see if I can fix the Starter scaling.  Caroline also has a request
in the SF.net tracker suggesting, for PNG Starters, that we provide a number
of sizes and/or aspect ratios, for cases where the scaling/smudging system
causes really bad results.  (Try "tuxpaint --640x800" and then load the
reef photograph Starter.)

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 11, 2009 at 11:51:24AM -0200, Gabriel Gazzán wrote:
> Hi guys,
>
> Playing with the last released version of Tux Paint I've discovered that in
> the Puzzle like (I don't know its exact name) starter image when you try to
> use the bucket fill on one of the lower right pieces to colorize it, the
> paint pours to other pieces.
> There must be a hole in some place, I guess...

To the best of my knowledge, it looks like the "NondefectiveBlit()"
(a specialized replacement from SDL_BlitSurface() that gets used by
autoscale_copy_smear_free()) was not blitting to the very far edges.
(Or perhaps it was starting one pixel too far to the left and off the top...?)

In any case, making it blit one extra row and column caused the jigsaw to
'work' properly for me in 800x600 mode.  (That is, if I try to use the Fill
magic tool on any of the jigsaw puzzle pieces on the far right or bottom,
the fill doesn't "spill over" into adjacent ones.)

I'll test it at some other sizes.  I also think that a bunch of these
starters need to have their white replaced with black.  (What white?
Well, the whites that happen to be 100% transparent, so you can't see them;
but when we scale, they reappear as grey.  You don't notice it until you
paint over them or fill; then you see these nasty edges around the lines.)

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Albert Cahalan]

On Sun, Oct 11, 2009 at 1:43 PM, Bill Kendrick <nbs@...> wrote:
> On Sun, Oct 11, 2009 at 11:51:24AM -0200, Gabriel Gazzán wrote:

> In any case, replacing these with SVGs (and most other lineart Starters)
> would be really useful.  If I'm reading this right, it looks like
> our builds for RedHat 6.2, 7.3 and 8.0 lack any kind of SVG support.
> All the rest use one or the other sets of SVG support libs.

How is SVG performing?

Also, before we go adding lots of starters, what about the lack of
correct-size thumbnails causing slowdowns for "New"?

> I'll see if I can fix the Starter scaling.  Caroline also has a request
> in the SF.net tracker suggesting, for PNG Starters, that we provide a number
> of sizes and/or aspect ratios, for cases where the scaling/smudging system
> causes really bad results.  (Try "tuxpaint --640x800" and then load the
> reef photograph Starter.)

Putting a 1-pixel white border on some of these starters could help.
Another idea is a flag to do that (add white) when scaling is used.

Adding multiple sizes looks like trouble. If they all show up in the UI,
then we have a bunch of starters that all look the same. Once a size
is chosen, it has to stay with the image forever. Loading up the image
with a different screen size will scale the image, and the starter must
be scaled in exactly the same way.

BTW, what about hardware-specific images? I'd like to do a couple that
are tied to physical screen resolution. (graph paper for the XO)
Except on identifiable hardware, we can't know the real DPI. X lies.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Albert Cahalan]

On Sun, Oct 11, 2009 at 1:33 PM, Bill Kendrick <nbs@...> wrote:
> On Sun, Oct 11, 2009 at 11:54:08AM -0200, Gabriel Gazzán wrote:

>> I'm definetly in favor of a UI look redesign.
>> I don't know if this one or any other, but it's needed I think.
>
> I honestly still enjoy the 'gem' style buttons.  This (and others I've seen)
> look way too flat.

I pretty much agree. I could see flattening the disabled buttons

> However, Tux Paint needs theme functionality.

Theming turns into an excuse for poor defaults. (unusable xine!)

> And in any case, it also
> needs most, if not all, of its icons redrawn.  Preferably as SVGs so that
> we can scale them (for when the UI itself can support larger buttons).

I'd much prefer 128x128 or 256x256 PNG. We can scale that.

Maybe we should render the UI only when we see a new screen resolution
or set of config-disabled buttons. We could cache the whole UI in a PNG.
That would speed up start times when nothing has changed.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 11, 2009 at 02:30:50PM -0400, Albert Cahalan wrote:
> How is SVG performing?

Well, from what I can see.  Bucket fill still gets some white edges,
though that does not happen when using a paintbrush.  (It's an artifact
of our fill tool filling against the background(white)+starter(black&grey).)


> Also, before we go adding lots of starters, what about the lack of
> correct-size thumbnails causing slowdowns for "New"?

Yes, I need to do that.  I'm also thinking of organizing them into
sections, like we did with Stamps.


<snip>
> BTW, what about hardware-specific images? I'd like to do a couple that
> are tied to physical screen resolution. (graph paper for the XO)
> Except on identifiable hardware, we can't know the real DPI. X lies.

One could simply package them along with the other Starters,
unless you're suggesting having some starters which ONLY appear if
the canvas size is some particular WxH...?

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 11, 2009 at 03:11:53PM -0400, Albert Cahalan wrote:
> > However, Tux Paint needs theme functionality.
>
> Theming turns into an excuse for poor defaults. (unusable xine!)

Well, it needs at LEAST some basic support to let us provide
variations for people with vision problems.  (e.g., bigger buttons
with larger icons & text labels... and high-contrast interface.)

<snip>
> I'd much prefer 128x128 or 256x256 PNG. We can scale that.
>
> Maybe we should render the UI only when we see a new screen resolution
> or set of config-disabled buttons. We could cache the whole UI in a PNG.
> That would speed up start times when nothing has changed.

Good point.

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Caroline Ford-2]

On 11 Oct 2009, at 20:53, Bill Kendrick <nbs@...> wrote:

> On Sun, Oct 11, 2009 at 02:30:50PM -0400, Albert Cahalan wrote:
>> How is SVG performing?
>
> Well, from what I can see.  Bucket fill still gets some white edges,
> though that does not happen when using a paintbrush.  (It's an  
> artifact
> of our fill tool filling against the background(white)+starter
> (black&grey).)
>
>
>> Also, before we go adding lots of starters, what about the lack of
>> correct-size thumbnails causing slowdowns for "New"?
>
> Yes, I need to do that.  I'm also thinking of organizing them into
> sections, like we did with Stamps.
>

I agree. I named the frames frame_ to keep them together but  
categories better.

>
> <snip>
>> BTW, what about hardware-specific images? I'd like to do a couple  
>> that
>> are tied to physical screen resolution. (graph paper for the XO)
>> Except on identifiable hardware, we can't know the real DPI. X lies.
>
> One could simply package them along with the other Starters,
> unless you're suggesting having some starters which ONLY appear if
> the canvas size is some particular WxH...?

Yes. You don't want to load starters with smearing at your wxh.  
Widescreen etc. Starter should only appear once in the catalogue.

Caroline
On her phone after a day in the library

>
> ---
> ---
> ---
> ---------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Tuxpaint-devel mailing list
> Tuxpaint-devel@...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Albert Cahalan]

On Sun, Oct 11, 2009 at 3:53 PM, Bill Kendrick <nbs@...> wrote:
> On Sun, Oct 11, 2009 at 02:30:50PM -0400, Albert Cahalan wrote:
>> How is SVG performing?
>
> Well, from what I can see.  Bucket fill still gets some white edges,
> though that does not happen when using a paintbrush.  (It's an artifact
> of our fill tool filling against the background(white)+starter(black&grey).)

No, I mean "performing" as in how fast it goes. Is it usable
on a slow computer?

>> BTW, what about hardware-specific images? I'd like to do a couple that
>> are tied to physical screen resolution. (graph paper for the XO)
>> Except on identifiable hardware, we can't know the real DPI. X lies.
>
> One could simply package them along with the other Starters,
> unless you're suggesting having some starters which ONLY appear if
> the canvas size is some particular WxH...?

If 200 pixels are exactly 1 inch, as measured by an ordinary
physical ruler, and the screen is 1200x900, then things are OK.

I could certainly generate graph paper on demand if I knew the DPI.
The DPI and screen size reported by X are not real; people can and
do set them to random values as required to change font sizes.
Since the world is far from ideal, on-demand generation doesn't work.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Albert Cahalan]

On Sun, Oct 11, 2009 at 5:10 PM, Caroline Ford
<caroline.ford.work@...> wrote:
> On 11 Oct 2009, at 20:53, Bill Kendrick <nbs@...> wrote:
>> On Sun, Oct 11, 2009 at 02:30:50PM -0400, Albert Cahalan wrote:

>>> BTW, what about hardware-specific images? I'd like to do a couple
>>> that
>>> are tied to physical screen resolution. (graph paper for the XO)
>>> Except on identifiable hardware, we can't know the real DPI. X lies.
>>
>> One could simply package them along with the other Starters,
>> unless you're suggesting having some starters which ONLY appear if
>> the canvas size is some particular WxH...?
>
> Yes. You don't want to load starters with smearing at your wxh.
> Widescreen etc. Starter should only appear once in the catalogue.

Oh yes we do!

You only notice the starters for which the current behavior is poor.
(mainly photo-based ones) You don't notice the ones which are OK.
I can trivially produce starters which really benefit from the current
behavior; they will generally be cartoon-like images with any lines
touching the edge being perpendicular to the edge.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 11, 2009 at 08:26:06PM -0400, Albert Cahalan wrote:
> No, I mean "performing" as in how fast it goes. Is it usable
> on a slow computer?

Heh, ok, I wondered if that was what you had meant.  Sadly, I cannot say.
It probably depends on the SVG.  Some are much more complex than others.

My one and only system at the moment is my laptop, a Dell Inspiron 1525.
/proc/cpuinfo shows a pair of these:

  Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz

The SVG ladybug takes a brief moment to come up.  It has a big alpha gradient.

<snip>
> I could certainly generate graph paper on demand if I knew the DPI.
> The DPI and screen size reported by X are not real; people can and
> do set them to random values as required to change font sizes.
> Since the world is far from ideal, on-demand generation doesn't work.

It also doens't help that so many people in the world say nonsensical things
like:

  * send us a 300dpi image

That's like saying "the speed limit is 55 miles per."  :)  Per what!??!

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Albert Cahalan]

On Mon, Oct 12, 2009 at 1:39 AM, Bill Kendrick <nbs@...> wrote:
> On Sun, Oct 11, 2009 at 08:26:06PM -0400, Albert Cahalan wrote:

>> No, I mean "performing" as in how fast it goes. Is it usable
>> on a slow computer?
>
> Heh, ok, I wondered if that was what you had meant.  Sadly, I cannot say.
> It probably depends on the SVG.  Some are much more complex than others.
>
> My one and only system at the moment is my laptop, a Dell Inspiron 1525.
> /proc/cpuinfo shows a pair of these:
>
>  Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz

Dang.

My laptop is about as fast as a 200 MHz Pentium.
It's also saddled with 1200x900 worth of 5:6:5 pixels.
About a million kids have the same hardware.

Maybe you could run Tux Paint in a emulator. Suggestions:

1. Any big-endian emulator (PowerPC Mac for example)
2. Valgrind
3. Valgrind with the cachegrind option

All three of those have benefits beyond just being slow.
You're in an especially good position to run valgrind; it is
currently not working for me.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Mon, Oct 12, 2009 at 03:20:38AM -0400, Albert Cahalan wrote:
> My laptop is about as fast as a 200 MHz Pentium.

Mine acts like one half the time.  (Between KDE4, Firefox, and screwed up
audio drivers.  I finally purged PulseAudio from my system, and I want
to chuck my laptop out a window less often.)

> It's also saddled with 1200x900 worth of 5:6:5 pixels.
> About a million kids have the same hardware.
>
> Maybe you could run Tux Paint in a emulator. Suggestions:
>
> 1. Any big-endian emulator (PowerPC Mac for example)
> 2. Valgrind
> 3. Valgrind with the cachegrind option
>
> All three of those have benefits beyond just being slow.
> You're in an especially good position to run valgrind; it is
> currently not working for me.

Yeah, I need to learn valgrind.

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Mon, Oct 12, 2009 at 09:56:47AM -0700, Bill Kendrick wrote:
> Yeah, I need to learn valgrind.

Oh nice.  It looks like fontconfig(?) causes Tux Paint to up and die
when run under valgrind.

==31782== Process terminating with default action of signal 11 (SIGSEGV)
==31782==  Bad permissions for mapped region at address 0x569D480
==31782==    at 0x481A0F7: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/tls/i686/cmov/libpthread-2.9.so)
==31782==    by 0x568C78E: (within /var/cache/fontconfig/865f88548240fee46819705c6468c165-x86.cache-2)
==31782==    by 0x48164FE: start_thread (in /lib/tls/i686/cmov/libpthread-2.9.so)
==31782==    by 0x444949D: clone (in /lib/tls/i686/cmov/libc-2.9.so)
==31782==

:(

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Sundag 11. oktober 2009 skreiv Gabriel Gazzán:
>I'm definetly in favor of a UI look redesign.
>I don't know if this one or any other, but it's needed I think.

Whatever happened to the UI redesign suggested by
Jonathan Blois in April 2008? I thought it looked great,
and was a vast improvement over the current UI.

--
Karl Ove Hufthammer
http://huftis.org/
Jabber: karl@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Fri, Nov 06, 2009 at 11:11:20PM +0100, Karl Ove Hufthammer wrote:
> Sundag 11. oktober 2009 skreiv Gabriel Gazzán:
> >I'm definetly in favor of a UI look redesign.
> >I don't know if this one or any other, but it's needed I think.
>
> Whatever happened to the UI redesign suggested by
> Jonathan Blois in April 2008? I thought it looked great,
> and was a vast improvement over the current UI.

First off, I'm being careful about UI changes, esp. in terms of how
Tux Paint 'looks.'  For one, people are used to it, and I don't want
a backlash from parents or children over a change.

Second, the application code itself needs to be updated to make UI
swaps easy to do.  (For example, if we DO decide to change the default
look and feel, it might be nice to provide the 'original' as an
option.  More importantly, tweaking the UI is important to me not
so much in terms of "making it look better," but in terms of
"making it more accessible."  Themes for low-vision users.
Right/left swapping for Hebrew and Arabic locales, too.)

Thirdly, there have been other fish to fry.  Some of them important,
some of them less important.  One thing I'm learning as I continue
to work on Tux Paint (and act as the lone developer and CTO for
a quickly-growing company, and spend lots of time helping raise my
toddler): sometimes I just need to do something that I WANT to do,
not necessarily something that's the highest priority for the
project.  Hence that crazy music Magic tool I whipped together.


Sorry if I'm being terse.  I'm a bit busy, and kind of in a bad
mood the last coupla days. :(

-bill!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel