Hi,

I have submitted a proposal for Gsoc on line - Proposal: Replace the GimpSizeEntry widget

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jake007/1#

Last year, I have talked with Martin about this project and learned many details. This year, I am applying as a second time to the project.

The proposal content is in the following. Comments will be appreciated, and may be easily to be inserted for this email. Thank you very much.

*************************************************************************

*Objective*

This project is to implement a simple and intuitive design for the GUI and interaction for GimpSizeEntry. The source code will be cleaned and refactored based on the requirements/specs and instruction of the mentor. It is to add some intelligence to the widget, modify its code structure, and create a new approach for text entry with values and units. The outcome will be a better GUI for entering image/canvas size that will be meaningful, user-friendly and extensible in long-term.

*Relevant experiences*

My name is Jake Zhang, a 25 years old undergraduate student, majoring in Computer Information System, in Saint Mary’s University. My email address is jake.zhang.007@gmail.com.

I think that Gsoc is a great opportunity for me to learn and produce some improvements for Gimp, a large and well-known image manipulation application. I am highly motivated to open source software development, particularly graphics editors.

* *

My skills and work experiences are in software development and mostly in graphics area. I have developed graphics editors in C, C++, Java and Python (for image processing and manipulation). I am familiar with the work to deal with dimensions, DPI, the ratio between pixels displayed and physical sizes of the object or image.

I have done similar architecture design and rewrite tasks for about three years in the software industry, including for every large software applications. My coop and work experiences are 80% GUI-based image processing software development. They are widely applied in multimedia, advertising and security industries. Once I have done it for a few times, I know that I can make it work.

In image manipulation, I have experiences in both graphics design and algorithm development. I used Gimp to edit images for many years. I have written many image processing algorithms, e.g. image filtering in spatial domain and frequency domain, image enhancement, image segmentation, and image compression.

I have experiences in C, GTK+, GObject, Git, and Linux. A brief review for these techniques and comparison with some other ones:

C: Perfect for image processing in speed, especially for complex algorithms, anything with loops and large matrix. More work for programmers, compared to Java and C#. More debugging work too, e.g. segmentation faults are annoy, which I only saw using C, not in Java, Python and C#. However, good programmers should not complain this. Some experienced programmers (10+ year) that I worked with do not use debuggers often, since they started programming before debuggers exist. They print.

GTK+: signals. Longer code than other GUI widgets. Java Swing and C# .NET has drag and drop toolboxes, designing visually. I found working with GTK+ is similar to Python and pywidget, and wxWidget. wxWidget is so widely used.

GObject: Very interestingly, C can be OOP. Someone asked me if it is similar to Objective C. It is still quite different. A decent OOP knowledge will help on its dev.

Git, bazaar, and SVN: These are very similar, but use different and same terms, e.g. pull, push, checkout, clone, commit, update, log, add, rebase, branch, merge, fetch, and so on. I know which is for which, but just listed a few of them.

Linux: It is great platform for daily use and developing software. It has a great deal of features that Windows does not have. There are so many useful open source applications to use in Linux. Mac OS is good too.

Basically, I am confident to develop a better GimpSizeEntry widget than the existing one.

*Project Analysis*

In order to deepen my understanding of the nature of this new technology, I have read lots of papers and books in this field. I find that this project is relevant to my experiences and suitable for me.

With a quick search for GimpSizeEntry, I found and read its docs:

http://developer.gimp.org/api/2.0/libgimpwidgets/GimpSizeEntry.html

When creating a new image, there are some fields to set the size, resolution, and units for the image, and printing. It is an important element, because almost every user will use it.

I have checked out the source code and reviewed it. It was said that code is rather messy. I have reviewed gimpsizeentry.c and gimpsizeentry.h in libgimpwidgets, agreed with the fact.

After 2005, there are around five commits for this code. The most recent large change was done near a year ago with only one commit.

There is well summarized issue list (as quoted below), according to the mentor of this project, Martin.

******************

The current GimpSizeEntry widget has a few outstanding problems: * The code is a giant mess.
* This makes it very hard, close to impossible, to add feature like "preserve aspect ratio between numbers in two GimpSizeEntry: while typing in one of them, updated live".
* It takes up a lot of space, and is generally clumsy, a GimpSizeEntry inherits from GtkTable but it should rather inherit from GtkEntry. * The combo box used to choose unit is awkward to use, would be better to have that handled inside the GtkEntry, simply "40 pixel" or "9 in"

* This makes it very hard, close to impossible, to add feature like "preserve aspect ratio between numbers in two GimpSizeEntry: while typing in one of them, updated live"

* It takes up a lot of space, and is generally clumsy, a GimpSizeEntry inherits from GtkTable but it should rather inherit from GtkEntry:

******************

struct _GimpSizeEntry

{

GtkTable table;

GSList *fields;

gint number_of_fields;

…

The above is the gimpsizeentry.h code, as well as its .c code (showing GtkTable type), that needs to be worked on. Due to the issue with extensibility, new features are either not possible to add, or going to amplify the issues of existing code.

A new method and intuitive design of choosing unit will be implemented. Its advantages are:

- The user does not need to type "px", "in", or "mm" every time.

- The UI does not need to provide examples for the new text entry, e.g. "40 px" or "9 in" near the text fields. Although it could be described in the user manual, most users will find it easy to understand and use.

With several emails with Martin as to this project, I have received helpful information on the following organized quoted points. These can be used as guides for the implementation.

******************

1. The logic of text input with values and units:

The context will help in the assumption of units to use. For example, if a size entry contains "40 in" and a user changes to "60", we can assume that he didn't want to change unit, so the entry would evaluate to "60 in" and "60 in" would then be put in the entry after the user presses Return or focuses another widget.

Another example: If there are four consecutive size entries for X, Y, Width and Height and the user enters "10 in" in the first one, then tabs to the next one and enters "15", we can assume the unit of the previous entry, i.e. it would evaluate to "15 in".

We can also use the display shell unit. If the rulers are shown in pixels, unit less input for that image can be assumed to be in the same unit as the rulers, i.e. pixels.

If no context, assume pixels.

2. Make use of the existing parser in gimpeevl.c:

There are existing parsing functions/methods for the new text entry, with both values and units.

Gimp has a very nice parser already written by Fredrik Alströmer which lives in libgimpwidgets/gimpeevl.c. It is integrated with the GimpSizeEntry and allows you to write simple math expressions in them and have the result evaluated, like "50 in + 20 px" or "2 * 40 px" or "50%" to get half of the previous value. This is really nice and a GimpSizeEntry rewrite would have to make sure to preserve this feature. The parser is very modular though so it shouldn't be a problem.

******************

All these points are reflected by the task list below.

Note: I got a message saying this email is too long. Please see the full Time line and Milestone sections in the on line link:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jake007/1#

*Tasks lists*

1. Code review, studies of the code base and docs, and retrieval of background, methods, and tools needed.

2. A good class structure for the new GimpSizeEntry

3. Better OOP design

...

...

13. Make use of the existing parser in gimpeevl.c:

14. Possible fine-tuning:

- Have auto completion of available units - have text entry examples in the tool tip (not in the UI to save space)

*Milestones*

**...

...

Sincerely,

Jake.