Re: [Gimp-developer] [GSoC] Replace the GimpSizeEntry widget

2010-04-03 Thread Martin Nordholts 
On 04/03/2010 03:29 PM, g...@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


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 development still under control"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] Replace the GimpSizeEntry widget

2010-04-03 Thread gg 
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.

regards.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] Replace the GimpSizeEntry widget

2010-04-03 Thread Martin Nordholts 
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


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 development still under control"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] Replace the GimpSizeEntry widget

2010-03-29 Thread Martin Nordholts 
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



-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 development still under control"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer