John Labenski ha scritto:
> In 2.6 there have been a number of additional base clases, for example
> wxTopLevelWindow that were not in 2.4. Since our bindings can lookup
> functions in base classes it would make sense to add wxTopLevelWindow
> even though there's nothing you can do with it in wxLua, because it
> would save on extra bindings functions for wxDialog and wxFrame.
>
> As I update the bindings should I just fix them for 2.6 only? It would
> make life much easier and personally I don't care to use wx 2.4 since
> it has absolutely no advantages over 2.6.
I agree: I think we can safely support 2.6 series only.
>
> =================================
>
> Secondly, static functions....
>
> Since no object exists for them we can't do stuff like this unless we
> hack away at the bindings.
>
> in C++ static int GetMetric(wxSystemMetric index, wxWindow* win = NULL)
> in Lua wx.wxSystemSettings:GetMetric(...)
>
> However! wxPython doesn't do this, they just put an underscore and
> create a new global function like wx.wxSystemSettings_GetMetric(...)
> which would be easy for us to do.
>
> From the 2.6.3 docs:
> "wxPython note: This static method is implemented in Python as a
> standalone function named wxSystemSettings_GetMetric"
>
> This makes things easier too since typically we've been using wxPython
> semantics so the docs for wxPython also apply for us and we don't have
> to write our own. :)
>
> Currently static functions don't work at all.
hacking the bindings to support the
wx.wxSystemSettings:GetMetric
would take much time/trouble ?
If yes, then I think it's not worth the effort. Also, reusing wxpython
docs for wxLua is a Good Thing :)
If it does not take too much work, I'd prefer the
wx.wxSystemSettings:GetMetric syntax over the
wx.wxSystemSettings_GetMetric one as it is more Object Oriented.
This is a delicate choice since once we decide to support first or
second syntax, we cannot change the choice anymore...
Francesco