2011/5/14 Enrico Schröder <enni.schroe...@gmail.com>
> Hi Martin!
> Parsing is done via GimpEevl which is called from the UnitEntry. I think it 
> makes sense because the entry is responsible for input and output, the 
> UnitAdjustment holds the value. GimpEevl does not require any UI. Or did you 
> mean our get_unit method? Maybe it would make sense to modify GimpEevl to 
> also determine the unit?


Yep I meant the get_unit() method on GimpUnitEntry, it should be
possible to get_unit() also in the non-UI layer.

Yes it probably is a good idea to let gimp_eevl_evaluate() return the
unit of the expression. It shouldn't know anything about the unit
itself though, like today, where the knowledge of units is abstracted
away through a GimpEevlUnitResolverProc parameter.

>> * Have you thought about how the image resolution comes into the picture?
> Would it be ok to have our UnitAdjustment hold the resolution along with the 
> actual value? It does belong together. However, the problem then would be if 
> we want our entry to be used to input a resolution. We could make that work 
> by using just the resolution field of our adjustment, but that would not be a 
> very elegant solution. So another class "GimpResolutionAdjustment"?

It's fine to keep the current resolution in GimpUnitAdjustment. As far
as I know we haven't had problems with
gimp_size_entry_set_resolution() and a similar interface for
GimpUnitAdjustment will make it easier to port code to use the new

To use GimpUnitEntry for resolution input, a good solution would be
based on yet another abstraction, perhaps GimpUnitEntryBehavior, with
subclasses GimpSizeBehavior and GimpResolutionBehavior. We don't want
to end up with lots if cases on some mode variable (like GimpSizeEntry

However, the details of GimpUnitEntryBehavior is hard to predict, so
let's focus on a size-only GimpUnitEntry first. When we're done with
that we can see what of the code we should move out in a
GimpUnitEntryBehavior abstraction to also support resolution input.
Resolution input is in many ways similar to size input, it's just a
different set of units and slightly different constraints.

I think we have thought enough about design matters for now, and it's
time to start writing some code (I suspect you already have started
doing that ;) ). Before doing that though, please update
http://tasktaste.com/projects/enni/gimpsizeentry with as small tasks
as you can. The smaller tasks we have, the better can we track project
progress and discover when we need to do something in order to meet
our deadlines. Don't worry if you can't yet split them up as much as
you'd like to though; we're still early in the project. As we move
along, exactly what we need to do will become more and more clear, and
we can update the schedule accordingly.

Very good job so far!

Best regards,

My GIMP Blog:
"GIMP 2.8 schedule on tasktaste.com"
Gimp-developer mailing list

Reply via email to