On 03/27/2010 08:31 PM, Jake Zhang wrote:

Hi Martin,
I have send an email to Gimp developer list. I am not sure if the email has gone through. I am sending it to you (mentor of this project) and the list again...
Thank you.
Jake.

On Fri, Mar 26, 2010 at 1:55 AM, Jake Zhang > wrote:

Hello,

I am interested in the "Replace the GimpSizeEntry widget" project for Gimp in GSoC 2010. I found this project is relevant to my experiences and suitable for me. I look forward to having more details about specs.

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. Am I looking at the correct point? If so, it is an important element, because almost every user will use it.

If getting this project, I can make some simple and intuitive design for the UI and interaction, and possibly clean and refactor some relevant source code. I invite your input and advice.

I have strong skills and work experiences in software development, mostly in graphics area. I have developed graphics editors in C, C++, Java and Python (for image processing and manipulation). One of the programs has been used by hundreds of customers every year. I am familiar the work to deal with dimensions, DPI, the ratio between pixels displayed and physical sizes of the object or image.

I have experiences in C, GTK+, GObject, and Git. Regards,
Jake.

Hi

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:s 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 combobox used to choose unit is awkward to use, would be better to have that handled inside the GtkEntry, simply "40 px" or "9 in"

/ Martin

On 04/01/2010 10:50 PM, Jake Zhang wrote:

Hi Martin,

On Mon, Mar 29, 2010 at 3:03 PM, Martin Nordholts > wrote:

Hi

The current GimpSizeEntry widget has a few outstanding problems * The code is a giant mess

Thank you for your feedback. I understand it basically. I will start to write a proposal for this project. Should I share a draft with you and the list first, before I submit it for Google?

Doesn't hurt to share it here first I guess.

* The combobox used to choose unit is awkward to use, would be better to have that handled inside the GtkEntry, simply "40 px" or "9 in"

/ Martin

I thought choosing unit is a common way. When I first read about the text entry in the idea list page, I have a few questions: - Does the UI need to provide examples for the new text entry, e.g. "40 px" or "9 in" near the text fields?

Not in the UI, rather in the manual.

- Does the user need to type "px", "in", or "mm" every time?

No, because the context will make it possible to assume what unit 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, unitless input for that image can be assumed to be in the same unit as the rulers, i.e. pixels.

If we are without context I think we should assume pixels.

- Is there existing parsing functions/methods for these new text entry, with both values and units? If not, I can write a parser to deal with this.

We have 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.

Best regards, Martin

On 04/03/2010 03:29 PM, gg@catking.net wrote:

On 04/03/10 09:46, Martin Nordholts wrote:

I thought choosing unit is a common way. When I first read about the text entry in the idea list page, I have a few questions: - Does the UI need to provide examples for the new text entry, e.g. "40 px" or "9 in" near the text fields?

Not in the UI, rather in the manual.

some care should be exercised here. If the interface is to become less clear and it is now necessary to go and read the manual in order to understand how to use such a basic and important input, I would be very inclined to see this as a regression not an improvement.

This current interface , despite its shortcomings is clear and explicit about what is available.

Replacing this approach with RTFM hardly seems appropriate.

I didn't mean that I want a hard-to-use widget that you need to read a manual to understand. It needs to be easy to use and intuitive of course. It could have autocompletion of available units for example.

I'm just saying that we should not have examples of how to use the widget near it in the UI, that would take up way too much space. Maybe in the tooltip for it though.

/ Martin