[erlang-questions] wxErlang release

[Steve Davis]

Dan Gudmundsson wrote:
> Wow feedback :-)

Now that made me laugh. Not getting feedback generally means one of 
three things:
1) Nobody cares you did it
2) Nobody understands what you did
3) You got it pretty right

Given the usefulness of being able to code up a cross-platform gui, and 
that a lot of people know wx quite well, I suspect that in this case it 
must be 3. :)

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


I think you may have misunderstood my idea. The GS implementation does 
have all those issues, and wxErlang does solve them. What I'm actually 
thinking of is a separate "facade" layer over the top of wxE that you 
code to like you would code to like you code to GS, and it transforms 
the calls into wxE calls.

The GS-style facade can then add all the extra control goodness of wxE 
to the GS interface but would shield you from some (most?) of the labor. 
That way you get the best of both worlds. Another way of looking at it 
is an erlang-style XRC that is specified as a term and thus could be 
read by file:consult and just junked into a xxx:create_tree call.

Given your answer - I guess this isn't being worked on, so I'll have a 
bash at a POC as I get time.

Best,
Steve