[Gimp-developer] GSoC 2011 - Replace GimpSizeEntry widget

2011-04-04 Thread Enrico Schröder
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


[Gimp-developer] GSoC 2011 - Replace GimpSizeEntry widget

2011-04-04 Thread Enrico Schröder
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.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer