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


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.



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....@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:


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"<RET>, 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:


*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)





Gimp-developer mailing list

Reply via email to