phatch-dev team mailing list archive

[Juho Vepsäläinen <bebraw@xxxxxxxxx>]

Hi,

While developing the EXIF related patches I noticed it modifies the
metadata of input image(s) in any case (ie. even if "Save" action is
present). Is this by purpose? Modifying image data is non-destructive
so it kind of contradicts with that. I have not worked with
EXIF/metadata related things before so it's all new to me. :)

Is there some specific place where I should put my tests? Do you
prefer to use some specific testing suite (ie. unittest/doctest/some
other?)?

I have used "get_relevant_field_labels" for conditional fields (ie.
fields depending on state of others). The system works, yes. But I
find it a bit suboptimal. Is there some specific reason why not to
determine the relationships between different fields in "interface"? I
think it might be more straightforward this way.

In addition it might be interesting to construct the object hierarchy
based on higher level definition (ie. YAML). Here's an example (ported
"reflection" action to YAML syntax):
ui = '''
PixelField:
    -name: Depth
    -width: 50% # I suppose original 50% meant width. anyway as you
can see it's reader friendly too
    -choices: self.PIXELS[:-1]
PixelField:
    -name: Gap
    -width: 0
    -choices: ['0', '1', '2', '5']
SliderField:
    -name: Opacity
    -value: 60
    -min: 0
    -max: 100
BooleanField:
    -name: Scale Reflection
    -value: False
    -children:
        ImageResampleField:
            -name: Scale Method
            -method: antialias
ColorField:
    -name: Background Color
    -color: black # I prefer to use a library
(http://code.google.com/p/grapefruit/) handling the conversion
SliderField:
    -name: Background Opacity
    -value: 100
    -min: 0
    -max: 100

I'm not 100% sure that it's valid YAML. It should be right enough to
convey the idea though. Basically keys refer to class names and their
attributes to the attributes of the classes. It's a piece of cake to
convert this into a real object hierarchy if needed.

Note that everything needed by interface and get_relevant_field_labels
methods can be generated based on this. So if wanted, this system can
fit on top of the current one instead of replacing it. I think the
system would pretty much pay off for itself in more complex cases (ie.
hierarchies going past two level). Furthermore it could be used to
bring cohesion and consistency to the system.

I suppose many actions have some sort of background color and opacity
defined in them. It would be possible to refer to generic properties
such as this in the structure itself. In this case you would subclass
ColorField and SliderField and end up with something like this:
BackgroundColor
BackgroundOpacity

Of course sometimes you might want to this partially (ie. Opacity):
Opacity: # subclass of SliderField
    -name: just some opacity
    -value: 55 # i'm not happy with the default so let's set it to 55 :)

Anyway those were some initial thoughts after two days of development.
It has been pretty easy to work with phatch so far. :)

Sincerely,
Juho Vepsäläinen