This doc from 2005 wxErlang A GUI library for Erlang goes into some detail on the generation of the binding code but the specification language it uses doesn’t appear to be used in the present day OTP repo, eg:
Which I think is just Erlang terms.
Is this the specification?
The doc mentions how the xml of the wx headers is used to generate C++ but for special casing the specification language allows for overriding this default for any particular function.
Is wxapi.conf exactly a database of overriding special cases?
I don’t fully understand.
my impression from the cited doc was that because c++ declarations couldn’t be reliably mechanically interpreted (ie. int *arg … might be an array of ints, or an ‘out’ parameter, or in/out, etc), that special casing was necessary; that the xml files were used for a default/simple interpretation from which both a c++ wrapper and an erlang interface file would be derived; and then, if particular functions/methods needed non-default interpretations they would have entries in the wxapi.conf, which gave specialised c++ wrapper/erlang interface versions; that the specialised c++ wrapper would override the xml/default one.
from your remarks: xml files give only c++ wrapper code, while
the wxapi gives both c++ wrapper code and erlang interface code.
could you go into a bit more detail of their relationship?
Your impression is correct but if the class/method is not listed in the wxapi file the class/method will not
be generate at all. i.e. the wxapi doesn’t only contain exceptions to the default rules.
I see thanks.
I went through the keywords used in the wxapi.conf to get
a sense of the tweaking going on to accommodate c++.
are there any major bits, of the interface, left out on account of fundamental incompatibility with erlang/functional approach?
is transfer of ownership ( of some wx resource)
tackled by the erlang binding? (if that is even necessary - the presence of deconstructor bindings suggests to me that resources not attached to the gui tree need to be manually managed).
wxPython (Phoenix), I think, tackles ownership and so truly unused resources can be automatically garbage collected.
are there any major bits, of the interface, left out on account of fundamental incompatibility with erlang/functional approach?
Some things needs to be hand coded.
Events differ in wx since in erlang we prefer message passing, but wxWidgets wants it to be callbacks so in wx we handle both.
In general callbacks or classes that is supposed to be overloaded needs to be handcoded in wx.
Ownership
Each time you do a wx:new() a new memory “environment” is created in the driver. When you do wx:destroy() everything (or all classes that can overload the destroy) will be deleted.
wx is kind of different because erlang is different, erlang is more an OS than an application, in erlang you can start several (gui) applications like observer and debugger and you own gui app, which all runs
in the same OS process (erlang) which wxWidgets is not made to handle so there are some code to support that.
Other than that, there are some design decisions that could have been made better but wx was written before the nif interface and maps existed.
I’ve written a parser for the wxapi.conf file and it handles lots of special cases since I’m using a language with a less flexible type system than erlang.
I think it’s down to erlang’s prolog-like clause capability.
they are from different wx class specifications and the difference
is
"wxDialiog"
vs
[unsigned]
is it the case that the former could have been written
["wxDialog"]
putting the two lines on a more level footing by both having singleton lists in the same position?
I suspect it’s a case of examining the erlang parser on a clause by clause basis to find out if I can collapse my ‘special cases’ into a common structure. I hope not though!
Other than that, there are some design decisions that could
have been made better but wx was written before the nif
interface and maps existed.
I don’t recognise ‘maps’ but the nif interface mention suggests you might have contemplated a non-ported arrangement, correct?
from my experience with a native binding in another language
the failsafe of a port interface seems like a great idea - it is all too easy to provoke wxwidgets to segfault even with faultless bindings to the pertinent function calls!
Oh are your trying to do the same thing in a another language?
Then I wouldn’t re-use the wxapi.conf file directly, use it as an inspiration or copy it and modify
it so it fit your needs.
wx for erlang have been around since wxWidgets 2.6.x so it might have stuff that is obsolete.
Functions and defines that are obsolete and should be removed in a newly built wrapper.
is it the case that the former could have been written ["wxDialog"]
Yes maybe, I have patched/hacked this generator so many years that I have forgotten how
to do things or what the code-generator supported so I might have done the same “overrides” in different syntax in wxapi.conf.
Another reason to not use wxapi.conf directly it needs some love.
Indeed I am. my thought was that wxapi.conf would be a more comprehensive and maintained ‘database’ than the one I’m currently using, which works by ad-hoc additions - it’s sparse and verbose relative to wxapi.
wxPython looked a good candidate with its SIP bindings but then I discovered it had, in addition, a custom coding module for seemingly every class!
what a quandary. I was pinning my hopes on the Ericsson wxapi ‘Oracle’. It would make good sense to have some centrally maintained distillation of the wx interface which makes up for the inadequacies of c++ header language.
if you were to do it all over (!) how would you choose to do it today?
