Freddie Witherden schreef: > On 8 Sep 2008, at 00:47, Giel van Schijndel wrote: >> Author: muggenhor >> Date: Mon Sep 8 01:47:53 2008 >> New Revision: 5963 >> >> URL: http://svn.gna.org/viewcvs/warzone?rev=5963&view=rev >> Log: >> * Add a Lua interface to (parts of) betawidget >> * Partially generated by SWIG >> * Partially handcrafted >> * Already supports registering Lua functions as event handlers of >> `widget` derivatives >> * Slight change in betawidget headers because the struct typedef's >> somehow confused the compiler >> * Use libtool for linking with Lua > > Some questions/musings: > > - My typedefs!?! Is it SWIG has a problem with typedef struct <x> > <y>? As several of the typedefs at the start of widget.c can be > converted to typedef struct { ... } <y>. (Namely the event ones.) > > - The '_' burn my eyes, please reject them in place of the holy > camelCase. > > - What is with all of the crazy const <type> * const WZ_DECL_PURE > WZ_DECL_INNOCENT WZ_DECL_REALLY_REALLY_CONST <name>. I am sure that > const <type> *<name> will do. We don't want it turning into pie vector.
Probably me being "statically typed"... I hope that at least something
good has come of this: to demonstrate that statically typed languages
have their disadvantages as well.
> - The widget class shouldn't need an allocating constructor (i.e.,
> one that malloc's memory). Widget should be considered an abstract
> class (there are several methods which it does not implement which are
> needed for it to function. The normal way to 'create' a class is with
> the *Create function, e.g. hBoxCreate which allocates the memory and
> calls the constructor. Not sure if it is possible to do this within
> the context of the C++ wrapper, however.
Just marking the undefined functions as pure virtual ("virtual rettype
func(params) = 0;") should do the trick.
> - The lua_widget_addEventHandler and lua_widget_addTimerEventHandler
> can probably be generalised into one. The share such a large amount of
> code (just addEventHandler sets the interval to -1). Should be able to
> factor a common function out.
They share a lot of code yes... But due to the fact that
addTimerEventHandler basically is addEventHandler with another parameter
placed *in*the*middle* addTimerEventHandler basically has a lot of
function calls with a parameter 1 larger or smaller. Don't get me wrong
though API wise I think it should be there though!
> - Do we have any ideas about how to make updating the interface file
> easier, so to reduce the amount of maintenance it will require?
Use SWIG wherever possible... Another possibility might be to extend
SWIG's Lua interface generator to produce "directors" and SWIG's main
parser to deal with callbacks. Callbacks will be the most difficult of
the two.
> - Any ideas on how to best handle event structures, as they use the
> same kind of inheritance scheme widget and friends do. Since lua is
> much more dynamic than C there may be a nicer way of passing these
> structures, which are crucial for event handling.
Duplicating the inheritance structure in Lua is simple enough (this is
where SWIG comes into play).
As for converting an event structure from C to Lua. I guess that we'll
need some code that performs "down casting" to *all* event types and
instantiates the appropriate type in Lua (this *will* be a newly
allocated structure, so a memcpy will be required as well). The
instantiation is simple enough. The maintenance burden will be in
writing that "switch (event->type)" block of code.
> - Shall we extern "C" { ... } all of the betawidget headers? As the Qt
> platform code (coming soon!) will be in C++ so it might be worth it.
Yes, please.
--
Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
