phatch-dev team mailing list archive

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

>- Could you use the standard lib optparse.OptionParser to parse the
values, which Phatch uses? That allows defaults and type >conversions.
For an example see phatch/app.py

At a quick glance I could not see what specific advantage using
OptionsParser might give in this case. It could parse the predefined
part, yes. I did not see a way to handle parsing in more generic way as
is needed for handling option parameters (ie. Background Color),
however. So at the worst case you would end up using a bit of the old
solution and a bit of new and might end up with two problems instead of
one. :)

>- Please use Fields and don't introduce options. As said before this
action should be implemented as the imagemagick action for now. >The
reason is that in the next release all Imagemagick and Blender actions
will be independent actions, next to the pil actions. So I >prefer that
both Imagemagick and Blender follow the same approach for now.

In the current solution it's quite simple to treat Blender actions as
separate. Sure it takes some shuffling around but not that much. I won't
be spending time restructuring it to the ImageMagick format. I rather
let someone else to do that. :)

-- 
Implementation of "Blender Action for Software Box"
https://bugs.launchpad.net/bugs/392999
You received this bug notification because you are a member of Phatch
Developers, which is subscribed to Phatch.

Status in Phatch = Photo & Batch!: Incomplete

Bug description:
This patch implements https://blueprints.launchpad.net/phatch/+spec/blender-action .

Note that the .blend file provided with the tarball ~must~ be placed into /phatch/data/blender. The current implementation contains only one action, Product Box and it's quite limited functionality wise (only colors/box depth can be changed, it figures out the width/height based on image proportions). As no float sliders are available yet I used integer one. It's scaled by ratio of 0.1 to float (so 10 -> 1.0 etc.).

The basic architecture is quite simple. It is split in two main sections: the Phatch related part and the Blender related part. The Phatch related part consists of two files, .py and .blend. The Phatch related part is implemented in blender.py action file by subclassing BlenderAction as follows:
class ProductBoxAction(BlenderAction):
    name = _t('Product Box')
    filename = 'box' # this refers to the name of the .blend and .py files provided for Blender in /data/blender! it might make sense to use convention here though so you would get the filename based on name (ie. product_box.py and product_box.blend in this case)
    
    def __init__(self):
        self.options[_t('Box Depth')] = ConstrainedFloat(value=1.0,
                                                         min=0.0,
                                                         max=10.0)
        self.options[_t('Floor Color')] = Color('#11133A')
        self.options[_t('Upper Background Color')] = Color('#11133A')
        self.options[_t('Lower Background Color')] = Color('#5B86B5')

Note the way options are defined in __init__. The current implementation uses a model based on which user interface related aspects are generated. Currently there are only two types, ConstrainedFloat and Color, but the system is easy to extend on demand. Please see the implementation of these classes and their parent, Value, for more information. If you add a new type, remember to check out /data/blender/runner.py too as it contains an important mapping function that parses this data into format which the Blender script can then use.

The Blender related files (/data/blender/box.py and /data/blender/box.blend in this case) should be prepared to operate Blender based on input data. Option names are mapped automatically to lowercase format (ie. "Floor Color" maps to "floor_color"). The .py file must implement def set_up_render(args). As may be guessed the options may be accessed via args (ie. args['floor_color'] would return color of the floor in Blender compatible format). The rest is using these options to manipulate Blender data via its API. Please consult the Blender Python API for more information.

Note that the current implementation doesn't support concept of relevant fields yet. It can be extended to support it by extending the model architecture a bit (ie. Choice class or similar). Also it would be good to implement Options class as an ordered one instead of a regular. The same applies for the Actions class.