On Sun, Mar 22, 2009 at 03:04 PM, MrGoil wrote:
> Hiho!
hi!
> I summarize my suggestions for the scripting bindings.
> This means all bindings! This means some renaming in the c++ for swig.
I'm adding some notes I wrote down while reading your page plus a brief
summary of the classes we'll probably have with the FrameRing design
please, feel free to add them to your wiki page as you wish..
> I want to replace the register_controller(), add_layer() with unique
> methods using the linklist stuff.
completely agree! see below..
> So for JS I want a simple Thread Object like the TriggerController with
> methods/callbacks like .setTimeout / .setInterval as WebBrowsers offer.
> This is less hassle.
yep, probably some timed-triggers will be enough for javascript
namespace:
put all objects in a global space, provided we're able to create an ad-hoc
context with the objects we want
getter/setter:
I prefer them because they provide a cleaner API in c++, if methods are
declared inline (we might put them inside class declaration) no performance
issues
linklist proposal:
re-implement them with std::list to clean and shrink codebase, to provide
iterators and to avoid Entry subclassing
classes (outside: c++ / swig bindings):
Jobject
is a freej base object a good idea to provide garbage collection
and similar features?
Layer
it only has filters + properties related to each layer type (fixed
geometry as we have blit/crop/zoom inside ViewPort)
FrameRing
basically is layer output, can be associated to multiple ViewPort
ViewPort
a screen, it contains blit/crop/zoom infos for each FrameRing
registered
Encoder
we might decide to associate an Encoder to a ViewPort or to implement
it as a ViewPort: probably the former option is easier to use while the
latter might result in a cleaner and smaller code
Controller
various controller types
ControllerEngine
we register there our controllers (probably this will be the only
'singleton' class inside freej)
Context
basically a dumb set of containers (linklist):
layer/framering/viewport/encoder/controller
we pass it to an instance of Interpreter to create an enviroment
Interpreter
???
classes (inside: javascript):
- questions:
what are we allowed to create from a javascript?
layer/framering/encoder/controller - of course
viewport/context/interpreter - it may be nice as well
(more to come)
luca
--
Beware of programmers who carry screwdrivers.
-- Leonard Brandwein
http://shammash.homelinux.org/ -
http://www.artha.org/ -
http://www.yue.it/
