On 04/01/2010 10:50 PM, Jake Zhang wrote:
> Hi Martin,
> On Mon, Mar 29, 2010 at 3:03 PM, Martin Nordholts <ense...@gmail.com
> <mailto:ense...@gmail.com>> wrote:
> 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"<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, 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.
My GIMP Blog:
"GIMP 2.8 development still under control"
Gimp-developer mailing list