[erlang-questions] wxErlang release
Steve Davis
steven.charles.davis@REDACTED
Fri Mar 6 09:30:47 CET 2009
*First* of all, nice job -- wxErlang seems to cover almost everything in
wxWidgets and isn't too hard to figure out how to use it if you already
know wx or MFC or Swing or another GUI framework (despite the
documentation's current state) :)
*Second* of all, there's a file missing from the build that will
adversely affect Windows XP et seq. users. To get XP to fully use all
its nice-modern-looking native UI elements it needs an ".rc" file in the
dll build. All that file needs contain is the following couple of lines:
--------resource.rc------------
aaaa ICON "wx/msw/std.ico"
#include "wx/msw/wx.rc"
-----------end-----------------
The #include will do the magic on tabs, buttons etc, which will
otherwise look like (and do currently) plain NT controls (YUK! :)
Although I believe the ugly first declaration is (far) less important I
believe that it will stop an "empty icon" appearing in the window frame
decoration when the icon is not explicitly set.
Third of all...
GUI programming is super-laborious, verbose, and boring. Because
wxErlang essentially wraps the CPP interface the programming style is
very reminiscent of all the current frameworks and is very un-Erlang.
When I first saw GS, I thought -- well HELL now that's how to do it!
Seems that by adding a few more elements to the GS interface (i mean the
*interface* not the implementation) it would be possible to create a
facade API for wxErlang that you'd use like GS and still get all the
benefits of all the work in wxErlang, -- I'm thinking of something a bit
like the project "xgs" from erlgtk days.
If that worked out then finally we would have a concise way
(create_tree) to create nice native GUIs from Erlang that could be used
in a much more Erlang-ish fashion... Not to mention the thousands of
hours that could be saved by avoiding having to convert the horrifically
dull wxWidgets documentation so it makes sense for the Erlang API
presented by the wxErlang generated modules.
I ask (Dan in particular, and anyone else who may have an opinion) -- do
you see this as a feasible approach/project? -- is this approach being
considered? -- if not, would you encourage me to have a go at it?
regs
/sd
More information about the erlang-questions
mailing list