[gephex-devel] What we need

[Martin Bayer]

Hi Jean-Sebastien,

> Mathematically speaking, we don't have a need for n-ary 
> operators for n > 2 since these can be implemented by combining unary 
> and binary operations.

With a haskell hat on i'd say we only need unary functions and functions 
as first class members in the typesystem :)

In gephex we have at the moment only one operation with more than 2 
frame inputs. Its a per pixel mixer with two video inputs and a third 
video input that controls the blending:

lightness( C_{x,y} ) * A_{x,y} + (1.0-lightness( C_{x,y} )) * B_{x,y}

>> - no plugin specific icon
>> - no hints for grouping effects in the userinterface
> 
> We thought about that recently since we started adding this 
> categorisation concept in Drone. However, we came to the conclusion that 
> the best option was to make the categorisation implicit to the 
> localisation of the libraries in the directories hierarchy. For 
> instance, the module whose path would be 
> "$PLUGINS_ROOTDIR/video/io/videosource.so" would be categorized as 
> "video -> io". I like the fact that the categorization is not hardcoded.
> 
> As for icons (and every software-specific characteristics), that could 
> easily be solved by adding an associated description file with the 
> module. This description file wouldn't be in the frei0r specs, but there 
> is no problem to add it in Drone or Gephex.

The idea to store this metainformation external is good. This could be 
as easy as a .ini style file with icon path and categorization 
information. Or something general like using rdf to associate arbitrary 
  metadata to the plugin.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.gephex.org/pipermail/gephex-devel/attachments/20041217/5d37fdd1/signature.bin