On 6/20/05, Ray Gilbert <ray...@sc...> wrote:
> I am currently working on generating a set of *.i files directly from
> wxWidgets headers, instead of hand coding them each time. This will allow=
us
> to maintain a complete up to date binding with less effort.=20
Cool! What about wx24 and groan wx22. Personally, I don't think we
should bother with anything <wx26 at this point. (note: wx22 was the
last win16 version IIRC, if anyone cares)
Unless of course all you need to do is download wx22 and run your
program and poof you get wrappers... :)
=20
> I wonder if it is better to follow the wxWidgets structure of=20
> Base, Gui, Adv, Net, Html, etc=20
> as _wx_base.i _wx_net.i_wx_gui.i _wx_adv.i etc
Might as well, I broke the original (whatever it was called) wrapper
file up into the current state since it was so overwhelming. But now,
I find that having so many of them is annoying in it's own way.
It'd be great if you could keep each .i file ordered by each .h file
so that you can compare them in case something's funny.
> and for specific toolkits=20
> _wx_gui_gtk.i _wx_gui_mac.i _wx_gui_mac_carbon.i _wx_gui_mac_cocoa.i=
=20
> _wx_gui_msw.i _wx_gui_os2.i=20
I suppose you have an idea of how this could work? Mmmm, I think I see
how... the generator doesn't care if you duplicate %classes, it'll
just contine to add members to them. (I'm just talking out loud,
ignore this)
Personally I don't think we have to bother with too much really
platform dependent stuff. wxLua is an interpreted language and as such
can provide a fairly complete system, just using the stuff that works
everywhere.
Things like this are probably useless since you can't do anything with
them anyway.
gdi.i: %win WXHANDLE GetHandle()
gdi.i: %win void SetHandle(WXHANDLE handle)
> (I have been able to get a nice set of *.h files for ctags to use from
> wxWidgets files.bkl)=20
Good, I thought it doesn't handle the #ifdefs though? Anyway I guess
you found a way.
=20
> Internally have still have equivalants of each wxUSE_ with wxLUA_USE_=20
> The will enable end users to only bind the wx modules they are using, and
> the power to customise what is exposed by lua interpreter=20
Good, I think that's important. As you probably know, but just to
reiterate, my idea was to be able to reduce the size and that you can
sandbox wxLua (a little bit, at least) by not wrapping some of the
more dangerous classes like wxApp.
---------------
Some thoughts about rewriting things. :)
I think the wrapper should ignore trailing ";" for class members or
"," for enums.
Additionally do we want to just use=20
%class or %enum
{
stuff
}; (again trailing ";" is ignored)
instead of %class %endclass. Basicly if we could make the wrapper
files as close to c++ as possible it'd be trivial for people to write
their own. Maybe you could even use a visual diff program to compare
them to the original, which would be really nice!
You could even make=20
#ifdef __WXMSW__=20
#elif ...
#endif=20
mean for the wrapper to literally stick the c++ #ifdef around all the
wrappers in the middle without any interpretation of it at all. This
may be a lot more compilicated though... forget it if it's too hard.
Finally might as well change %include to #include right? Since it
implies that we want to do a c++ #include.
Thanks for your work,
John Labenski
|
