[erlang-questions] wxErlang release
Fri Mar 6 10:47:56 CET 2009
Wow feedback :-)
Steve Davis wrote:
> *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) :)
The documentation will continue to lack a lot in R13 :-)
I will not have time to do something about it, in the future
wxWidgets will switch over to use doxygen for it's doc so we will hopefully
be able use the C++ documentation directly.
Then a user guide needs to be written, at least a lot of examples.
> *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:
> aaaa ICON "wx/msw/std.ico"
> #include "wx/msw/wx.rc"
> 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.
Thanks, I didn't know that and have wondered why my apps don't look so XP'ish, when
wxWidgets examples does.
Will get back to you if I need more help :-)
Windows is not my strong side..
> 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?
I really don't have much experience with gui programming (except wings3D)
but I agree with everything you said above, the problems I have with GS is:
- Not so beautiful
- Non native widgets
- Very small widget set
- No (easy) access to widgets that are not in the high level api.
- The packer don't work, everything have hard coded sizes
(in the debugger and erlang tools I have looked at)
which is really bad for platform independent gui programming.
With wxWidgets we get,
- Beautiful... (more native look and feel)
- Native widgets i.e file browser, print dialog and so on.
- large widgets set
- The sizer (packer above) works a lot better and is building stone in wxWidgets.
- Performance (should be better than GS)
But we loose the high-level api and erlang crashes when we do
something wrong (with a coredump if you are lucky which is pretty useless if you haven't
spend a lot of time with the c++ wxWidgets).
So a high-level abstraction like GS with access to the low level stuff would be great.
> erlang-questions mailing list
More information about the erlang-questions