Tuxpaint GSoC tracker

I've submitted my survey right now.
It's a very quickly process  ;)


The deadline is July 14th

A version to be tested is ready in alternative repo, so if you want to test it (you will need a svn client):

svn checkout http://tuxpaint-system-file-dialogs.googlecode.com/svn/trunk/ tuxpaint-system-file-dialogs-
read-only

To compile it, use the target gtk
$make gtk

Surely, you will need gtk+
I've tested it using Ubuntu Hardy and libgtk2.0

Please, give me feedback. Any suggestion is welcome =)

Screenshots:
- http://littlechina.org/~dilly/Tuxpaint-Screenshot-Save.png
- http://littlechina.org/~dilly/TuxPaint-Screenshot-Open.png

Last days I've ported two SDL-based games to Playstation 2:

http://www.newbreedsoftware.com/circus-linux/
http://www.newbreedsoftware.com/vectoroids/

Now is time to focus on Tuxpaint.

I received a great new: my application was accepted!

My mentor will be Luc Schrijvers,

Great!!

I think the main arguments against creating a custom dialog box are:
- A lot of work must be done, compared with using a toolkit. The SDL
libraries that are being used don't offer widgets or something like
that.
- Since much code will be written, it will increase the code
complexity, making it harder to maintain; much time will be spend to
debug and document; probably more bugs will be added to the software
than using a toolkit.
- The time and efforts I will spend with this, I could be using to fix bugs and adding requested features

But I don't believe it's like reinventing the wheel, since I didn't
find any project that really matches the projects needs.

I found some SDL C++ toolkits. But I believe there are two problems with these toolkits:

1) I will have to make some wrappers with bindings, since the toolkits I found are written in C++.

2) I'm not confident in anyone. I don't like the idea of adding a dependency of a library maintained by small, non-stable communities.

These are my impressions, but I'm new in the SDL world. So it's very important to hear what the developers have to say about it.

Between making it and doing a custom dialog box, I prefer the second option.

About gtk+, I really like it. I have been working with this in
Inkscape (as part of my last year GSoC work) and in a personal free software project written in python (svn://svn.sarava.org/imcpub). But I'm afraid about three main points:
 - It will increase dependencies to Tux Paint. I don't know yet if
it's considered a great problem for Tux Paint community, but some projects are very
concerned about adding dependencies. Personally, I don't care about,
since it's well maintained.
 - The dialogs will be a bit different of the rest of the graphical interface.
 - GTK+ is not supported for all the platforms that Tux Paint is. I
don't think we have a huge problem here, since this feature is being
requested by schools, where probably the OS used are one of the
supported by GTK+ (UNIX-like, Windows, mac os x).

Considering I'm very familiar with GTK+, if these points are not
enough to discard the possibility of using it, it can be the best
choice.

My intention is to write a proposal about 3 ideas that I read in the
page and in the mailing list archives.

The first idea is to combine and modularize the functions
do_new_dialog(), do_open(), and do_slideshow(). These functions have a
lot of common code, and integrating them is important to keep the code
easy to maintain and debug. I think I understood clearly what should
be done, so I've already started to code. This way I had a better idea
about the work I have to do, so now I can write a more precise
timeline.

The second idea is to add support for system file dialogs. I've
thinking how it could be done, and here are the results of my
research:

1) We could use some kind of toolkit, like gtk+ (www.gtk.org):
 Advantages:
  - Few lines of code will must to be written and maintained
  - It has a vast community that maintain the library for a decade,
so it is stable, and is portable for many platforms(UNIX-like,
windows, mac os x)
  - GTK+ has been involved in a number of embedded initiatives over
the past few years including the development of:
      * Nokia 770 / N800 / N810
      * One Laptop Per Child Project
      * OpenMoko

 Disadvantages:
      - Increases dependencies of tuxpaint
      - The GUI is too diferent of tuxpaint's interface. So it will
has an inconsistent look and feel
      - Some of the platforms supported by tuxpaint will not support
the new feature, since gtk is not supported for all of them.

I took a screenshot of how tuxpaint should look if we use gtk, just to
illustrate what I'm talking about. It's here:
http://www.littlechina.org/~dilly/tuxpaint_gtk.png

2) I have searched for toolkits written in SDL, but I just found some
written in C++, and 2 problems will persist:
 - The inconsistent look
 - One more dependence

3) We could do it ourself. I'm really interested in drawing the dialog
myself. It will avoid extra dependencies and I can learn more about
SDL.

The code to work with the various platforms system file will be
written specifically to each one anyway.
My conclusion is that I shouldn't use extra libraries and do it
myself. What do you think about it?


The third idea is to use the time Google gives to read the project
documentation to rewrite and "put into a more sensible format".

Yesterday, I made my first patch for tuxpaint.

It can be found here: http://www.littlechina.org/~dilly/tuxpaint_modular1.diff

This blog was created just to track the work I will do about my GSoC proposal:

Support for system file dialogs in Tuxpaint

So, if you are interested about it, you should come back in few days, and you will find some news.