I tend to think it should be kept the same because a) is easier to write the code (I have a similar script that allows access to the wx Erlang constants) and b) searching the WxWidget docs is easier when the names are the same.

@kerryb what’s the point of the WxObject wrapper if everything else apart from the constants is Erlang syntax?

For those interested I did recently do this, for all 25,000 lines of related constants, mostly through some multi-cursor editing and find/replace regexes. src/ files here.

In my opinion you should follow Elixir’s naming convention, so all of the macros and functions should be snake case.

The main reason I didn’t do that was … well, laziness to be honest, but also I’ve used tools before (eg Java and Ruby bridges to Apple’s Cocoa) where having to keep mentally translating the names of things when reading documentation was confusing.

I understand that it’s for a reason, so instead of converting it to snake case I would rather fit it in Elixir’s standards, for example a call like:

wxALIGN_RIGHT()

could be changed to:

wx(:ALIGN_RIGHT)

I do like that idea – it seems nicer than polluting the namespace by importing hundreds of functions into a module.

Maybe you could use more clear example usage here.

Yes, good point – I just pasted some snippets from a code sample I’d converted, assuming that if anyone was interested they’d already be far more familiar with wx than I am. I ought to replace it with a working “hello world” example.

I’m glad I happened to find it right after you published it! I’ve been meaning to publish something like it, so this saves me some time. Definitely a welcome addition.

As a side note, while I’ve been more focused on the realtime rendering stuff with OpenGL, Metal, Vulkan, and Direct3D, there’s a form builder that would probably be great to integrate better. Micheus, who works on Wings3D, did some work on this but I haven’t really looked into it. Just happened to find it last week and thought it might be interesting.

Interesting project! In my opinion you should follow Elixir’s naming convention, so all of the macros and functions should be snake case. I understand that it’s for a reason, so instead of converting it to snake case I would rather fit it in Elixir’s standards, for example a call like:

wxALIGN_RIGHT()

could be changed to:

wx(:ALIGN_RIGHT)

There should not be a difference in performance. It should also be easier to document it since instead of lots of functions you would have just for example wx/1 and wx_gl/1 functions.

Also I’m not sure if write a __using__ macro makes sense if all you do inside it is just import.

Here is your first example:

use WxEx
import Bitwise # to allow ORing of flags with |||

panel = :wxPanel.new(frame)
label = :wxStaticText.new(panel, wxID_ANY(), "A label", style: wxALIGN_RIGHT())
sizer = :wxBoxSizer.new(wxHORIZONTAL())
:wxSizer.add(sizer, label, flag: wxALL() ||| wxALIGN_CENTRE(), border: 5)

# etc

but it would not work, because frame was not defined. I understand that it should not be a problem for those who used :wx before, but please keep in mind that many people would like to give it a try by running a “quick” session in iex console and then a copy-paste script is very helpful.

Similarly to the second example. Again someone who just want to give it a try would not understand why there is so many :undefined. Maybe you could use more clear example usage here.

Anyway it’s interesting project. The source of mix task looks very clear and easy to read.