[erlang-questions] wxErlang release

Dan Gudmundsson <>
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) :)

Thanks.
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:
> 
> --------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.

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.
- performance


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.

Regards
/Dan

> 
> regs
> /sd
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 



More information about the erlang-questions mailing list