Re: What we need

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

_______________________________________________
gephex-devel mailing list
[email protected]
http://lists.gephex.org/mailman/listinfo/gephex-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBwhb1Cm3i57PRsbsRArC1AJ9hhJdjUfdyzlLamcoPLtE0DrQ7WgCggNPm
E9sE1EgEKUVVZA+L2B/LmUo=
=JbR6
-----END PGP SIGNATURE-----