WxEx – Elixir wrappers for macros and records in :wx

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.

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?

Sorry, I did not deeply analyse the code. I was thinking it’s a tiny change like:

"  def wx\\2, do: :wx_constants.wx\\2()"

to:

"  def wx(:\\2), do: :wx_constants.wx\\2()"

+ of course the same for gl stuff … You can do the same in Erlang when defining :wx_constants functions …

1. Search feature on hexdocs is case insensitive as far as I know, so there should be no big difference between searching wxALIGN_RIGHT, ALIGN_RIGHT and align_right
2. When I’m searching by wxALIGN_RIGHT I have no results.
3. Edit: I have tried also to search on wxwidgets.org page and it’s also case insensitive

obraz1217×217 17.7 KB

Anyway, it’s your choice. When taking a look at the mix task I have found something else:

https://github.com/kerryb/wx_ex_compiler/blob/2dcdfaa22b6848720f4f10dbb700513889ae9382/lib/mix/task/compiler/wx_ex.ex#L152-L158

Isn’t it simpler to use Code.format_string!/2 or even better Code.format_file!/2 instead? They are available since 1.6.0, so there should be no problem with project requirements.

I’m talking about the WxWidgets docs, not any elixir docs.

wx() is a record that’s needed for references, so that won’t work. Functions are nice since it doesn’t pollute the atom space, but it also requires changing the casing, as some macros are capitalized.

Quaff makes them module attributes, which is really the most consistent, since it prepends them with an underscore, so casing doesn’t matter. Quaff is broken on wxErlang macros because they’re not defined in order. Haven’t bothered patching it.

Part of the oddity is caused by wxWidgets itself - macros don’t have a consistent naming format. WxEx, due to function naming rules in Elixir, forces them all to be wxFOO, even if the actual wxWidgets macro is WXFOO. I don’t love this. I still think the atom approach would be nice, since :wxID_ANY and :WXK_NONE both work, and if any clever people want to write :wxID_ANY and WXK_NONE instead, fine. But it requires a layer to translate the calls.

I suppose another option would be to use strings and do case-insensitive searches, but that’s not great either. Maybe it would be possible to have a macro layer so the wxWidgets macro names match up identically.

Overall, the capitalization isn’t so important for searching, but it’s nice to basically copy and paste wxWidgets macros without thinking about it.

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.

Exactly the conclusion I came to, which is why I removed it in v0.5.0

Attempting to implement it was a good learning exercise though.

Isn’t it simpler to use Code.format_string!/2 or even better Code.format_file!/2 instead? They are available since 1.6.0, so there should be no problem with project requirements.

Yes. I originally used Mix.Tasks.Format.run, but that picked up the library’s formatter config (including Styler) when running in a project that used wx_ex (and failed if Styler wasn’t available). You’re right, Code.format_string!/2 is a better option that won’t try to run plugins.