2011/5/14 Enrico Schröder <enni.schroeder@xxxxxxxxx> > > 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? Hi! 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 classes. 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 has for GIMP_SIZE_ENTRY_UPDATE_SIZE and GIMP_SIZE_ENTRY_UPDATE_RESOLUTION). 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, Martin -- My GIMP Blog: http://www.chromecode.com/ "GIMP 2.8 schedule on tasktaste.com" _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
