Hello Gimp developers,

I'm currently applying for the GimpSizeEntry project for Summer of Code. To keep my application short and to allow further discussion and feedback, I decided to post the detailed description of my proposal on the mailing list instead of in the application itself. My application will contain a link to this mail.

Regards,
Enrico

---------------------
Detailed description:

I will describe briefly the issues of the current implementation of the GimpSizeEntry widget and how I suggest to address them:
Currently, the unit is selected through an external combo box. The new GimpSizeEntry will not have that external combo box. Instead, the unit is
entered directly into the text entry. The input will then be evaluated making
use of the existing parser (gimpeevl.c) which will allow input of simple mathematical terms and sizes in different units (for example "1024px + 2 in"). The result including the unit will then be displayed in the text entry. The unit will be defined through either the entered unit or context sensitive: When there is no unit entered, the previous unit is assumed, or the
unit of a related SizeEntry.

The second issue is size and flexibility. Being based on GtkTable, the current solution consumes too much space and is not flexible enough. The
new GimpSizeEntry will be based on GtkEntry. It will have the necessary interfaces to work together with other SizeEntries or elements such as GimpChainButtons or preview labels. This allows adjusting the SizeEntry for every
use case: be it the use in the new image dialog or in the settings of a tool,
with or without a button to fix aspect ratio etc. while still being able to make it as compact as possible wherever screen space needs to be conserved.

I even imagine the use of just a single GimpSizeEntry for input of height and width together (in the form of ³1024x768 px²). That would especially
be useful in the tool¹s settings, where space needs to be conserved. For example
the Scale tool: We now have a pop-up with basically only a GimpSizeEntry and
Ok/Cancel buttons. Having just a single entry field would allow to move that
into the settings and not having to use the pop-up. Designing the new GimpSizeEntry with that flexibility in mind would make it easy to extend it that way. There might not be enough time for all of that in the scope of Summer of Code, but I¹d be happy to continue developing afterwards to ensure Gimp gets the most out of the new GimpSizeEntry widget.

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

Hello Gimp developers,

I'm currently applying for the GimpSizeEntry widget for SummerOfCode. To keep my application short and allow further discussion and feedback, I've decided to post the detailed description of my proposal on the mailing list instead of in the application itself. My application will contain a link to this mail.

Regards,
Enrico

PS. this time hopefully in human-readable formatting, sorry for the first mail.

---------------------------

Detailed description:

I will describe briefly the issues of the current implementation of the GimpSizeEntry widget and how I suggest to address them:

Currently, the unit is selected through an external combo box. The new GimpSizeEntry will not have that external combo box. Instead, the unit is entered directly into the text entry. The input will then be evaluated making use of the existing parser (gimpeevl.c) which will allow input of simple mathematical terms and sizes in different units (for example "1024px + 2 in"). The result including the unit will then be displayed in the text entry. The unit will be defined through either the entered unit or context sensitive: When there is no unit entered, the previous unit is assumed, or the unit of a related SizeEntry.

The second issue is size and flexibility. Being based on GtkTable, the current solution consumes too much space and is not flexible enough. The new GimpSizeEntry will be based on GtkEntry. It will have the necessary interfaces to work together with other SizeEntries or elements such as GimpChainButtons or preview labels. This allows adjusting the SizeEntry for every use case: be it the use in the new image dialog or in the settings of a tool, with or without a button to fix aspect ratio etc. while still having the possibility to make it as compact as possible wherever screen space needs to be conserved.

I even imagine the use of just a single GimpSizeEntry for input of height and width together (in the form of “1024x768 px”). That would especially be useful in the tool’s settings, where space needs to be conserved. For example the Scale tool: We now have a pop-up with basically only a GimpSizeEntry and Ok/Cancel buttons. Having just a single entry field would allow to move that into the settings and not having to use the pop-up. Designing the new GimpSizeEntry with that flexibility in mind would make it easy to extend it that way. There might be not enough time in the scope of Summer of Code, but I’d be happy to continue developing afterwards to ensure Gimp gets the most out of the new GimpSizeEntry widget.