Hi Martin

I implemented your suggestion to follow the GtkSpinButton pattern: The 
UnitAdjustment now is to be created manually by the client and then set via 
gimp_unit_entry_set_adjustment(). I removed the majority of functions in 
GimpUnitEntry which mirrored GimpUnitAdjustment. Only set/get_pixels and 
set/get_bounds is remaining. I also added gimp_unit_entries_get_adjustment() in 
addition to gimp_unit_entries_get_entry() so that clients can access the 
adjustment easily.
Have a look at the new API and tell me what you think (especially what part of 
GimpUnitAdjustment we still should mirror in GimpUnitEntry for convenience). I 
think I like it better now ;) But I made it a separate commit so we could 
rewind painlessly...

Best regards

Am 30.07.2011 um 13:30 schrieb Martin Nordholts:

> Hi
> Here are my review comments from a rather detailed review round. I've
> looked carefully at the GimpUnitAdjustment and GimpUnitEntry APIs, as
> I believe we can get the API in a state good enough for inclusion in
> the GIMP 2.10 plug-in API (that will also survive into GIMP 3.0).
> GimpUnitEntries should still be kept around, but not as part of a
> backwards compatible public API, only as a private convenience for us.
> Same goes for your new gimp_prop_*()-functions and GimpUnitParser. I
> did't look very closely at the GimpUnitEntries implementation or API
> this time. I didn't look very close at GimpUnitParser either since
> it's a small internal helper which is always nice.
> The diff with comments can be found here:
> http://files.chromecode.com/gimp/gimp-soc-2011-gimpunitentry-review-2011-07-17.txt
> Your focus now should be on fixing the review comments (and coding
> style and documentation) rather than continuing to port GIMP app to
> use GimpUnitEntry as there is not much time left in the project.
> Keep up the good job :)
> / Martin
> -- 
> My GIMP Blog:
> http://www.chromecode.com/
> "GIMP 2.8 schedule on tasktaste.com"

Gimp-developer mailing list

Reply via email to