wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] 3 Layout quiz

[L.Guo <lea...@gm...>]

Hi MailList wxHaskell user:

    I am new to wxhaskell.
    In reading examples and writing my test program, I need some help about Layout controls.

    Reading wxhaskell/samples/wx/Layout.hs, here is the code piece.

>  set f [defaultButton := ok
>        ,layout := container p $
>                   margin 10 $
>                   column 5 [boxed "coordinates" (grid 5 5 [[label "x:", hfill $ widget xinput]
>                                                           ,[label "y:", hfill $ widget yinput]])
>                            ,floatBottomRight $ row 5 [widget ok,widget can]]
>        ]

    I donot know why there must be an container p out of the layout of the controls. I
have tried remove the container, after that, the text boxes and buttons dispeared. Why ?

    In my test, I have written a piece of code like this.

>  set f [layout := column 2 [hfill $ row 1 [hfill $ label "Left"
>                                           ,vfill $ vrule 2
>                                           ,hfill $ label "Right"]
>                            ,hfill $ hrule 1
>                            ,floatCenter . margin 1 . grid 5 5 $
>                               map (\i -> map (label . show) [i..(i+5)]) [1..5]
>                            ]
>        ...

    In the above code, the frame f has a status bar. I have two questions about it.

    My purpose of the top row, is to make these two labels in the same width, which
the above code does not. How to achieve the purpose ?

    Resizing the window, when it is very small, the label grid may out of the bound.
How to deal with it ?


    My system / env.:
        WinXP Pro SP3 + GHC 6.10.1 + wxHaskell 0.11.0


    I suppose the first question and the third question are the same. Not so sure.
    Anyway, thanks for your reading through.


    Regards
--------------
L.Guo
2009-05-07

Re: [wxhaskell-users] Moderation

[Daniel C. <dan...@th...>]

No problem! Cheers.

Jeremy O'Donoghue wrote:
> Hi all,
> 
> Regrettably, we had to turn on moderation for all new subscribers about
> a year ago after list spamming started to happen frequently.
> 
> Our policy is that as soon as it is clear that a mail is coming from
> someone with an issue appropriate to this list, we turn off moderation.
> I put my hands up and apologize for forgetting to do this in your case,
> Daniel.
> 
> Regards
> Jeremy
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 

Re: [wxhaskell-users] Moderation

[Jeremy O'D. <je...@o-...>]

Hi all,

Regrettably, we had to turn on moderation for all new subscribers about
a year ago after list spamming started to happen frequently.

Our policy is that as soon as it is clear that a mail is coming from
someone with an issue appropriate to this list, we turn off moderation.
I put my hands up and apologize for forgetting to do this in your case,
Daniel.

Regards
Jeremy

Re: [wxhaskell-users] Moderation

[GŸuenther S. <re...@fe...>]

Hi Mads,

it's set so for me too.

You sure it's not set like that for everyone?

Günther

Mads Lindstrøm schrieb:
> Hi
>
> Daniel Carrera wrote:
>   
>> Is it normal that all my emails have to go through moderation? I am 
>> subscribed to this list. It seems odd that my emails require moderation.
>>     
>
> I do not know why the moderation flag was set for you. Maybe Mailman do
> it automatically somehow. I have removed it now.
>
>
> /Mads
>
>   
>> Daniel.
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations 
>> Conference from O'Reilly Media. Velocity features a full day of 
>> expert-led, hands-on workshops and two days of sessions from industry 
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> wxhaskell-users mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>>     
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations 
>> Conference from O'Reilly Media. Velocity features a full day of 
>> expert-led, hands-on workshops and two days of sessions from industry 
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> wxhaskell-users mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>>     

Re: [wxhaskell-users] Moderation

[Mads L. <mad...@ya...>]

Hi

Daniel Carrera wrote:
> Is it normal that all my emails have to go through moderation? I am 
> subscribed to this list. It seems odd that my emails require moderation.

I do not know why the moderation flag was set for you. Maybe Mailman do
it automatically somehow. I have removed it now.


/Mads

> 
> Daniel.
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] General questions

[Daniel C. <dan...@th...>]

Mads Lindstrøm wrote:
> However, personally I have no desire to use Glade or XRC files. But I
> know others do - to each his own.

Personally I have no opinion on Glade as I've never used it. When I say 
I like the idea of specifying a GUI with XML, the picture in my mind is 
something like XUL or HTML (hey, I'm a web developer). But these are 
much simpler than Glade XML. AFAIK you are not supposed to write Glade 
XML by hand.

Daniel.

[wxhaskell-users] Moderation

[Daniel C. <dan...@th...>]

Is it normal that all my emails have to go through moderation? I am 
subscribed to this list. It seems odd that my emails require moderation.

Daniel.

Re: [wxhaskell-users] General questions

[Mads L. <mad...@ya...>]

Hi

Jeremy O'Donoghue wrote:

> Someone (Mads, I think) showed a proof of concept for type safety on
> XRC, but I haven't had the time to implement it fully so far.

Yes, that was me. See
http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/364/match=xrc

I do not think it would take a long time, to make this usable for 90-95%
of the widgets in a XRC file.

However, personally I have no desire to use Glade or XRC files. But I
know others do - to each his own.

I do not want to develop this any further, for an imaginary user who may
or may not exists. However, if somebody wants to this further developed
and is willing to be ginnypig I could do so. But it is only second best.
The best would be for somebody with a GUI app using XRC file, to
implement type-safe XRC accessors themselves.


Greetings,

Mads

Re: [wxhaskell-users] General questions

[Jeremy O'D. <jer...@gm...>]

2009/4/30 Daniel Carrera <dan...@th...>:
>
> Btw, can you compile and deploy a wxHaskell program using only FOSS? For
> example, can you use mingw an still get the one DLL? Is it hard to get
> the one DLL?

I've never tried - I use Visual Studio to build wxWidgets and wxC -
but it should work, as more users seem to use FOSS build chains than
Microsoft, and all of the Unix platforms use exclusively FOSS tools to
build. The wxWidgets build system is very configurable, and most build
options seem to exist on all supported platforms. In general, I've
found that if wxWidgets team claim something works, it works well
(i.e. they do their QA!)

There are people who use mingw to build the wxC component of wxHaskell.

The single DLL aspect may require some minor fiddling with the wxC
makefiles, but I suspect it should work once you've found the correct
set of options.

> Oh, I just thought of a new question: WebKit. I know that there is a
> project to port WebKit to wxWidgets. Can wxHaskell use wxWebKit? That
> would be uber-cool? (I don't know if I can use it for anything, but I
> can say it would be cool).

In principle, once it is in wxWidgets, it's pretty easy (trivial for a
reasonably experienced C++ programmer) to wrap any new components -
that's to say, once you have built wxWebKit, making it accessible from
wxHaskell is easy (if tedious - for large/complex APIs).

A quick glance at the wxWebKit website shows that there are a very
large number of dependencies for building the component, so it might
be tricky to incorporate into the standard wxHaskell distribution (I
suspect many people would be put off by having to compile 9
significant Open Source libraries to get wxWidgets to build).

Jeremy

Re: [wxhaskell-users] General questions

[Jeremy O'D. <jer...@gm...>]

2009/4/30 Daniel Carrera <dan...@th...>:
> Oh, can one use wxGlade with wxHaskell? I'm thinking of the XRC files (XML
> description of the UI). Personally I'm a big fan of using XML to describe
> GUIs.

You can use XRC files with wxHaskell, although I should note that they
are not currently type-safe (so you will get a crash if you load a
resource and treat it as the wrong type of object (e.g. load a button
into a list box).

Someone (Mads, I think) showed a proof of concept for type safety on
XRC, but I haven't had the time to implement it fully so far.

I use something called wxFormBuilder on Windows to create my XRC
files, which seems a little more complete than wxGlade, although both
will do the job.

There's a sample provided with wxHaskell which shows how to use XRC
files, should you decide to go this way.

Jeremy

Re: [wxhaskell-users] General questions

[Daniel C. <dan...@th...>]

Oh, can one use wxGlade with wxHaskell? I'm thinking of the XRC files 
(XML description of the UI). Personally I'm a big fan of using XML to 
describe GUIs.

Come to think of it, a lot of toolkits seem to be going in that 
direction. Mozilla has XUL, Gtk has Glade, QtDesigner makes XML files, 
and wxWidgets has wxGlade which can make XRC files.

Cheers,
Daniel.

Re: [wxhaskell-users] General questions

[Daniel C. <dan...@th...>]

Jeremy O'Donoghue wrote:
> Depending on how you build wxWidgets / wxHaskell, you can have just a
> single DLL to distribute along with your application (the default
> build creates about 10 DLLs and uses dynamically linked C library, but
> Microsoft has recently invented a whole new version of 'DLL hell' with
> the use of Manifest library descriptions. I find it much simpler (i.e.
> more or less guaranteed to work on any client machine) to build a
> single DLL containing wxWidgets, C runtime and the wxC bindings (to
> which wxHaskell talks via FFI).

Btw, can you compile and deploy a wxHaskell program using only FOSS? For 
example, can you use mingw an still get the one DLL? Is it hard to get 
the one DLL?

> Depends on how critical your users are. Qt and wx are probably fine
> for all but the most demanding UI zealots. I think Qt has its own
> (non-native) implementations of a few widgets on Mac, but they are
> probably avoidable if you really must look native.

In all honesty, I'm not willing to put the effort in being 100% native, 
and I don't think my users would care either.

Oh, I just thought of a new question: WebKit. I know that there is a 
project to port WebKit to wxWidgets. Can wxHaskell use wxWebKit? That 
would be uber-cool? (I don't know if I can use it for anything, but I 
can say it would be cool).

Daniel.

Re: [wxhaskell-users] General questions

[Jeremy O'D. <jer...@gm...>]

Hi Daniel,

2009/4/30 Daniel Carrera <dan...@th...>:
> Jeremy O'Donoghue wrote:
>> 2009/4/30 Daniel Carrera <dan...@th...>:
>>> 1) First, a broad question: Why do you like wxHaskell?
[snip]
>> The company I work for has major issues with LGPL (we're flat out
>> forbidden to use anything LGPL, although GPL is OK in certain
>> circumstances), whereas wxWidgets (and hence wxHaskell) has a license
>> that unambiguously allows for closed source development.
>
> That's very interesting. This isn't an issue for me (my employer is
> happy with any FOSS license), but it's interesting anyways.

Flame war material on many lists, but it's my employer's rule (or
rather, my employer's lawyers' rule...), so I need to stick by it.

>> I like that it is stable, has pretty much all of the features I need
>> in a GUI, is easy to distribute (i.e. roll up into an installer) and
>> looks good on all three major platforms.
>
> The "easy to distribute" part is interesting. Is there something that
> makes Qt or Gtk harder to distribute? Maybe it's the license...

Nothing to do with the license, and all about building an installer :-)

Depending on how you build wxWidgets / wxHaskell, you can have just a
single DLL to distribute along with your application (the default
build creates about 10 DLLs and uses dynamically linked C library, but
Microsoft has recently invented a whole new version of 'DLL hell' with
the use of Manifest library descriptions. I find it much simpler (i.e.
more or less guaranteed to work on any client machine) to build a
single DLL containing wxWidgets, C runtime and the wxC bindings (to
which wxHaskell talks via FFI).

Gtk+ is composed of a very large number of DLLs - it's not too hard to
package up, but I've run into problems in the past where more than one
Gtk+ application is installed on a machine and the 'other' Gtk+ DLL
appears earlier on the path than the correct version. None of this is
insurmountable, just tedious to track down and fix if it happens.

Worth mentioning that these packaging issues are pretty much confined
to Windows targets. Linux and Mac seem to be less problematic,
probably because libraries tend to live in a small number of locations
and shared libraries can coexist in multiple versions more readily.

>>> 2) I've heard that wxWidgets doesn't work that well on Mac OS X, but
>>> looking at the screen shots, it looks very native to me. How is OS X
>>> support?

[snip]

>> but it is closer (out of the box) to OS X native look and
>> feel than either of Gtk+ or Qt IMHO.
>
> Qt too? That's interesting. I sort of assumed that Qt would be better on
> Mac, but I haven't checked. Later on I'll reboot into OS X and install a
> couple of Qt and Wx apps and see how they look.

Depends on how critical your users are. Qt and wx are probably fine
for all but the most demanding UI zealots. I think Qt has its own
(non-native) implementations of a few widgets on Mac, but they are
probably avoidable if you really must look native. The latest (native
Mac) versions of Gtk+ are getting considerably better, but still have
a way to go, and native Gtk+ is not really production ready on Mac as
yet, although Gtk2Hs has been demonstrated to work with it.

Regards
Jeremy

Re: [wxhaskell-users] General questions

[Daniel C. <dan...@th...>]

Hi Jeremy,

Thanks for the reply. Very good information.

Jeremy O'Donoghue wrote:
> 2009/4/30 Daniel Carrera <dan...@th...>:
>> 1) First, a broad question: Why do you like wxHaskell?
> 
> Well, the wxHaskell list may not be the place to get objective advice, but...

For GUI toolkits, I think you can get advice that is either objective or 
useful, but not both. I prefer subjective-but-useful.


> The company I work for has major issues with LGPL (we're flat out
> forbidden to use anything LGPL, although GPL is OK in certain
> circumstances), whereas wxWidgets (and hence wxHaskell) has a license
> that unambiguously allows for closed source development.

That's very interesting. This isn't an issue for me (my employer is 
happy with any FOSS license), but it's interesting anyways.


> I like that it is stable, has pretty much all of the features I need
> in a GUI, is easy to distribute (i.e. roll up into an installer) and
> looks good on all three major platforms.

The "easy to distribute" part is interesting. Is there something that 
makes Qt or Gtk harder to distribute? Maybe it's the license...


>> 2) I've heard that wxWidgets doesn't work that well on Mac OS X, but
>> looking at the screen shots, it looks very native to me. How is OS X
>> support?
> 
> To get a *really* native OS X look and feel, you will need to do a few
> platform specific pieces of code, but it looks pretty good out of the
> box with just a recompile.

I see. Thanks.


> but it is closer (out of the box) to OS X native look and
> feel than either of Gtk+ or Qt IMHO.

Qt too? That's interesting. I sort of assumed that Qt would be better on 
Mac, but I haven't checked. Later on I'll reboot into OS X and install a 
couple of Qt and Wx apps and see how they look.

The only real problem I see with Qt is that the qtHaskell bindings are 
very new. It looks like a one-man project. Even if it works, one still 
has to think about community support and documentation.

> I've never used or seriously looked at QtHaskell, so I'm not very
> qualified to judge. The only comment I would make (after 15 minutes
> browsing the documentation) is that it looks as though the bindings
> are a fairly low level wrapper around the Qt libraries just now. I
> would expect the library itself to be pretty stable, as once you get
> the wrapper generating code correct, most things just work.

Ok. That's good to know. I thought QtHaskell might be unstable. In any 
case, if I ever write a GUI app with Haskell (knock on wood) I would 
write at a small program with each GUI before choosing one.


> There's little to choose, technically, between Gtk2Hs and wxHaskell, I
> think, and any choice you make is more likely to be about the
> platforms you care about most than about functionality or stability.

Good to know. In the context of my job, Windows and Linux are the most 
important, and Mac would be nice.

Currently we use web applications because that is automatically 
cross-platform and trivially deployed. But some users have said that 
they aren't always on-line, so I thought it might be nice to make a 
desktop alternative some day. I've also been looking for an excuse to 
use Haskell for something.


> Pragmatically, both Gtk2Hs and wxHaskell have pretty much everything
> most people would need, and more besides. There are probably more
> active developers of Gtk2Hs, but both projects are actively and
> enthusiastically maintained. Both also offer some higher level
> syntactic sugar over the bindings to make programming a bit easier,
> although in both cases it all feels a bit 'imperative' - you do all of
> the GUI stuff inside a 'do', and the code is pretty reminiscent of
> what you'd write in C++.
> 
> Hope this helps, and more importantly, I hope you decide to write a
> GUI application in Haskell.

Thanks for the help. Very good information.

Cheers,
Daniel.

Re: [wxhaskell-users] General questions

[Jeremy O'D. <jer...@gm...>]

Hi Daniel,

2009/4/30 Daniel Carrera <dan...@th...>:
>
> 1) First, a broad question: Why do you like wxHaskell?

Well, the wxHaskell list may not be the place to get objective advice, but...

The main reason I got started with wxHaskell was that I needed to put
together a GUI application for Windows, and I wanted to use Haskell to
do it. At the time (it's much better now) Gtk+ was a pig to get
working on Windows, and didn't have anything like a native look and
feel. Mac was also 'nice to have' for me, and again, Gtk+ at the time
worked only on the Mac X server.

The company I work for has major issues with LGPL (we're flat out
forbidden to use anything LGPL, although GPL is OK in certain
circumstances), whereas wxWidgets (and hence wxHaskell) has a license
that unambiguously allows for closed source development.

I like that it is stable, has pretty much all of the features I need
in a GUI, is easy to distribute (i.e. roll up into an installer) and
looks good on all three major platforms.

> 2) I've heard that wxWidgets doesn't work that well on Mac OS X, but
> looking at the screen shots, it looks very native to me. How is OS X
> support?

To get a *really* native OS X look and feel, you will need to do a few
platform specific pieces of code, but it looks pretty good out of the
box with just a recompile. It's not perfect (no cross-platform toolkit
really can be), and there are a few more bugs on Mac than other
platforms, but it is closer (out of the box) to OS X native look and
feel than either of Gtk+ or Qt IMHO.

Having said that, I think you can achieve excellent results with all
of the toolkits, and if you want to go further, you'd better use HOC,
which allows access to OS X native tools such as InterfaceBuilder -
although the project does not appear to be very active these days.

> The last couple of days I have been trying to learn about cross-platform
> GUIs with Haskell. In general I like Gtk+, WX and Qt, I think they are
> all great. But it looks like qtHaskell is too new, and Gtk doesn't
> support Mac well at all. But on the other hand, a lot of Haskell people
> seem to like Gtk2Hs.

I've never used or seriously looked at QtHaskell, so I'm not very
qualified to judge. The only comment I would make (after 15 minutes
browsing the documentation) is that it looks as though the bindings
are a fairly low level wrapper around the Qt libraries just now. I
would expect the library itself to be pretty stable, as once you get
the wrapper generating code correct, most things just work.

There's little to choose, technically, between Gtk2Hs and wxHaskell, I
think, and any choice you make is more likely to be about the
platforms you care about most than about functionality or stability.
For me, platform importance is Windows, Mac, Linux (in descending
priority) and I think wxHaskell is a slightly better fit to my needs.
I suspect that many in the community use mainly or only Linux, in
which case Gtk2Hs is probably a better fit.

Pragmatically, both Gtk2Hs and wxHaskell have pretty much everything
most people would need, and more besides. There are probably more
active developers of Gtk2Hs, but both projects are actively and
enthusiastically maintained. Both also offer some higher level
syntactic sugar over the bindings to make programming a bit easier,
although in both cases it all feels a bit 'imperative' - you do all of
the GUI stuff inside a 'do', and the code is pretty reminiscent of
what you'd write in C++.

Hope this helps, and more importantly, I hope you decide to write a
GUI application in Haskell.

Regards
Jeremy O'Donoghue

[wxhaskell-users] General questions

[Daniel C. <dan...@th...>]

Hello,

I am not actually a wxHaskell user. I'm not even planning to make a GUI 
app soon. I am just a curious person and I was hoping I could ask a few 
questions:

1) First, a broad question: Why do you like wxHaskell?

2) I've heard that wxWidgets doesn't work that well on Mac OS X, but 
looking at the screen shots, it looks very native to me. How is OS X 
support?


The last couple of days I have been trying to learn about cross-platform 
GUIs with Haskell. In general I like Gtk+, WX and Qt, I think they are 
all great. But it looks like qtHaskell is too new, and Gtk doesn't 
support Mac well at all. But on the other hand, a lot of Haskell people 
seem to like Gtk2Hs.

Is there anyone here that can compare wxHaskell with Gtk2Hs and/or 
qtHaskell?

Daniel.

[wxhaskell-users] Selection of noncontiguous text!

[Eric <er...@ma...>]

Dear all,

In most text editors one can select noncontiguous pieces of text. In the 
TextCtrl, however, this feature does not seem to exist. Is there a way 
to enable it?

Sincerely,
Eric M

[wxhaskell-users] let's make wxc part of the official wxWidgets tree!

[Eric K. <eri...@gm...>]

Dear wxc users,

So a few years ago, Surendra Singhi suggested that we automate the
generation of the C wrappers for wxWidgets.  Now with wxWidgets 2.8 out
for some time and the wxWidgets team is busy working towards 3.0, I
would like to suggest that we revisit this discussion.  Let's not update
this wrapper to work with wxWidgets 3.0.  Instead, how about starting
over from something that's completely automatically generated?

In fact, we've just had some discussion on this on the wxHaskell mailing
list, in which we attempt to generate these bindings from the Doxygen
XML output (thanks to Kevin Ollivier from the wxWidgets team for the
idea):

* https://sourceforge.net/mailarchive/message.php?msg_name=20090409175728.GA15805%40brighton.ac.uk
* https://sourceforge.net/mailarchive/message.php?msg_name=8AD3AF71-4A6A-4984-8925-3C42F7F9B0E2%40theolliviers.com

Having this kind of automatically generated code could save us a lot of work
and help us to keep our bindings up to date.  If we play our cards right, we
may be able to get this script into the official wxWidgets tree (!), which
could considerably simplify matters.

So are there any wxOcaml and wxEiffel or other wxC users around?  If so, could
you comment on whether this technique could work well for you, or what you
would need from a WXC binding?  In particular, wxHaskell seems to make use of
extra type information for our marshalling layer:
  http://code.haskell.org/wxhaskell/wxc/include/wxc_types.h
How about you?  And how can we move forward?

Thanks!

Eric

PS.  Below is a small extract of the automatically-generated code:
> /* Constructor */
> wxButton wxButton_wxButton ();
> /* Constructor */
> wxButton wxButton_wxButton (wxWindow * _parent, wxWindowID _id,
> wxString & _label, wxPoint & _pos,
> wxSize & _size, long _style,
> wxValidator & _validator, wxString & _name);
> void wxButton_Destruct (wxButton * _obj);
> bool wxButton_Create (wxButton _obj, wxWindow * _parent, wxWindowID _id,
> wxString & _label, wxPoint & _pos, wxSize & _size,
> long _style, wxValidator & _validator,
> wxString & _name);
> wxString wxButton_GetLabel (wxButton _obj);
> wxWindow *wxButton_SetDefault (wxButton _obj);
> void wxButton_SetLabel (wxButton _obj, wxString & _label);
> wxSize wxButton_GetDefaultSize (wxButton _obj);

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] autogenerating wxc from wxWidgets Doxygen output?

[Kevin O. <ke...@th...>]

Hi Eric, Mads, and all,

On Apr 12, 2009, at 10:38 AM, Eric Y. Kow wrote:

> On Sun, Apr 12, 2009 at 19:23:01 +0200, Mads Lindstrøm wrote:
>> * Convince the wxWidgets team to maintain the script. I guess this
>> involves not just talking to the wxWidges team, but also show that  
>> other
>> people will find the c-wrapper useful.
>
> This would be a big win and I think we may be able to pull this off.
> After all, wxOCaml, wxEiffel, and wxHaskell all use some variant of
> wxc.  wx.NET have this thing they call wx-c, which I guess is to
> C# what wxc is to C.  Maybe we could somehow adapt this technique?
> I can foresee this sort of thing helping wxWidgets become useful for
> new languages as well, or maybe even people who want to use wxWidgets
> in C for whatever reason.

What I'd recommend you guys do is get the other ports that use C  
wrappers in together and try to work out a standardized wxC syntax for  
all the ports to use. (e.g. I see wxHaskell seems to use some TClass,  
etc. types but I'm not sure what they're for.) I don't think the wx  
developers will have any problem with hosting the script as part of  
the official wx tree, but we'd need people who are familiar with the  
needs of the C bindings to come up with the design of it and help out  
on maintaining the scripts.

Regards,

Kevin

> -- 
> Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
> PGP Key ID: 08AC04F9

Re: [wxhaskell-users] autogenerating wxc from wxWidgets Doxygen output?

[Eric Y. K. <eri...@gm...>]

On Sun, Apr 12, 2009 at 19:23:01 +0200, Mads Lindstrøm wrote:
> * Convince the wxWidgets team to maintain the script. I guess this
> involves not just talking to the wxWidges team, but also show that other
> people will find the c-wrapper useful.

This would be a big win and I think we may be able to pull this off.
After all, wxOCaml, wxEiffel, and wxHaskell all use some variant of
wxc.  wx.NET have this thing they call wx-c, which I guess is to
C# what wxc is to C.  Maybe we could somehow adapt this technique?
I can foresee this sort of thing helping wxWidgets become useful for
new languages as well, or maybe even people who want to use wxWidgets
in C for whatever reason.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] autogenerating wxc from wxWidgets Doxygen output?

[Mads L. <mad...@ya...>]

Hi

I made another version of the c_wrapper.py program. I have attached the
program, a new smaller diff to doxymlparser.py and output from running
the program. The output can compile now:

> python c_wrapper.py out/xml/classwx_button.xm
> g++ `wx-config --libs` `wx-config --cxxflags` -c wrapped_wxButton.cpp

I have not tried hooking it up to Haskell, as I cannot compile wxHaskell
with the svn-checkout of wxWidgets and as I could not find the
doxygen-directory in my older version of wxWidgets (2.8.7) which do work
with wxHaskell.

Also I think we should consider how to proceed.

Should we proceed with making a python program like c_wrapper.py ?

And how much work is there in this? I guess we need to:

* Finish the c_wrapper.py script. It will properly need a lot of
debugging before working properly.

* Re-hook wxHaskell up to the output of c_wrapper.py script. This may
take some time, as function names and some parameters will change. And a
lot of code will have small changes, so there is a lot of possibility
for error :-(

* Convince the wxWidgets team to maintain the script. I guess this
involves not just talking to the wxWidges team, but also show that other
people will find the c-wrapper useful.

Especially the second task seems big, but the others are not small
either.

If people are interested in working on c_wrapper.py, I would be happy to
put it into our Darcs repo.


Greetings,

Mads Lindstrøm



Mads Lindstrøm wrote:
> Hi
> 
> Kevin Ollivier wrote:
> > Hi Eric,
> > 
> > On Apr 9, 2009, at 11:18 AM, Eric Kow wrote:
> > 
> > > On Thu, Apr 09, 2009 at 18:57:29 +0100, Eric Kow wrote:
> > >> This is where Kevin Ollivier of wxWidgets pointed out something
> > >> interesting: in the current wxWidgets trunk, it should be possible to
> > >> automatically generate the C bindings from the Doxygen XML output.   
> > >> In
> > >> fact, he has already done something similar for Python, metadata to
> > >> Python objects:
> > >>
> > >> http://trac.wxwidgets.org/browser/wxWidgets/trunk/docs/doxygen/doxymlparser.py
> > >
> > > Following up on this, I did
> > >
> > >  svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk  
> > > wxWidgets
> > >  cd wxWidgets/doc/doxygen
> > >  ./regen.sh
> > >  python doxymlparser.py --report out/xml/classwx_button.xml
> > >
> > > Attached is the XML file (input) and the output of this script.
> > >
> > > Here is a small extract of the output:
> > >
> > >  Class: wxButton
> > >  Bases: wxControl
> > >  Inlcudes: []
> > >  Brief Description:
> > >
> > > And...
> > >
> > >  Method: SetLabel
> > >  Return Type: void
> > >  Params: [{u'type': u'const&', u'declname': u'label'}]
> > >  Prototype: void wxButton::SetLabel(const wxString &label)
> > >  Brief Description:
> > >
> > > What can we do with this?
> > 
> > As a start, with a few lines of Python code after the  
> > doxyparser.parse(file) calls in the script, you can do something like:
> > 
> > # start code to autogenerate wxc.h
> > wxc_header = ""
> > 
> > for aclass in doxyparse.classes:
> > 	for amethod in methods:
> > 		self_ref = "TSelf"
> > 		if amethod.name == "Create":
> > 			self_ref = "TClass"
> > 			wxc_header += "%s(%s) " % (self_ref, aclass.name)
> > 		else:
> > 			wxc_header += "%s " % (wxc_type_for_type(amethod.return_type)
> > 
> > 		wxc_header += "%s_%s( %s _obj" % (aclass.name, amethod.name,  
> > self_ref + (" + aclass.name + ")")
> > 
> > 		for param in amethod.params:
> > 			wxc_header += ", %s %s" % (wxc_type_for_type(param["type"]), "_" +  
> > param["declname"])
> > 			# Note: uncomment this if you support adding default values
> > 			# if "defval" in param:
> > 			#	wxc_header += "=" + param["defval"]
> > 		wxc_header += " );\n"
> > 
> > wxc_file = open("wxc.h", "wb")
> > wxc_file.write(wxc_header)
> > wxc_file.close()
> > 
> > # end code
> > 
> > This is all just pseudo-code, and methods like wxc_type_for_type would  
> > need implemented, and you'd also need to probably work out some  
> > special logic for constructors, a list of classes to exclude, etc. but  
> > this should give you an idea of how to start things off. Ideally you'd  
> > actually have your own generate_c_bindings.py file that does an  
> > "import doxyparser", then runs "doxyparse.parse()" itself rather than  
> > extending the doxymlparser.py script, but anyway, just some ideas.
> 
> I have made an initial attempt at a c_wrapper.py program. It is far from
> finished, but like the XSLT program, I did it to see if it was feasible.
> I have attached the program.
> 
> My initial imprecision is that this could work out. Python is a very
> nice language, and it was a joy to make my little program. I am already
> further along than with the XSLT program, and I have spend a third of
> the time. And more importantly, it did not feel painful at all.
> 
> I had to change doxymlparser.py a bit though, otherwise we get
> type-names like constwxString:
> 
> > svn diff:
> 
> Index: doxymlparser.py
> ===================================================================
> --- doxymlparser.py	(revision 60099)
> +++ doxymlparser.py	(working copy)
> @@ -98,7 +98,11 @@
>          if child.nodeType == child.ELEMENT_NODE and child.nodeName == "ref":
>              text += getTextValue(child)
>          if child.nodeType == child.TEXT_NODE:
> -            text += child.nodeValue.strip()
> +            #text += child.nodeValue.strip()
> +            # We changed line above to remove qualifiers. Maybe we need another field on parameters?
> +            for token in string.split(child.nodeValue.strip()):
> +                if (token != "virtual" and token != "static" and token != "const"):
> +                    text += token
>              
>      return text
> 
> Kevin, what do you think about this change?
> 
> 
> The output looks like:
> 
> > python c_wrapper.py out/xml/classwx_button.xml | indent
> 
> /* Constructor */
>        wxButton wxButton_wxButton ();
> /* Constructor */
>      wxButton wxButton_wxButton (wxWindow * _parent, wxWindowID _id,
> 				 wxString & _label, wxPoint & _pos,
> 				 wxSize & _size, long _style,
> 				 wxValidator & _validator, wxString & _name);
>      void wxButton_Destruct (wxButton * _obj);
>      bool wxButton_Create (wxButton _obj, wxWindow * _parent, wxWindowID _id,
> 			   wxString & _label, wxPoint & _pos, wxSize & _size,
> 			   long _style, wxValidator & _validator,
> 			   wxString & _name);
>      wxString wxButton_GetLabel (wxButton _obj);
>      wxWindow *wxButton_SetDefault (wxButton _obj);
>      void wxButton_SetLabel (wxButton _obj, wxString & _label);
>      wxSize wxButton_GetDefaultSize (wxButton _obj);
> 
> 
> Greetings,
> 
> Mads Lindstrøm
> 

Re: [wxhaskell-users] autogenerating wxc from wxWidgets Doxygen output?

[Mads L. <mad...@ya...>]

Hi

Kevin Ollivier wrote:
> Hi Eric,
> 
> On Apr 9, 2009, at 11:18 AM, Eric Kow wrote:
> 
> > On Thu, Apr 09, 2009 at 18:57:29 +0100, Eric Kow wrote:
> >> This is where Kevin Ollivier of wxWidgets pointed out something
> >> interesting: in the current wxWidgets trunk, it should be possible to
> >> automatically generate the C bindings from the Doxygen XML output.   
> >> In
> >> fact, he has already done something similar for Python, metadata to
> >> Python objects:
> >>
> >> http://trac.wxwidgets.org/browser/wxWidgets/trunk/docs/doxygen/doxymlparser.py
> >
> > Following up on this, I did
> >
> >  svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk  
> > wxWidgets
> >  cd wxWidgets/doc/doxygen
> >  ./regen.sh
> >  python doxymlparser.py --report out/xml/classwx_button.xml
> >
> > Attached is the XML file (input) and the output of this script.
> >
> > Here is a small extract of the output:
> >
> >  Class: wxButton
> >  Bases: wxControl
> >  Inlcudes: []
> >  Brief Description:
> >
> > And...
> >
> >  Method: SetLabel
> >  Return Type: void
> >  Params: [{u'type': u'const&', u'declname': u'label'}]
> >  Prototype: void wxButton::SetLabel(const wxString &label)
> >  Brief Description:
> >
> > What can we do with this?
> 
> As a start, with a few lines of Python code after the  
> doxyparser.parse(file) calls in the script, you can do something like:
> 
> # start code to autogenerate wxc.h
> wxc_header = ""
> 
> for aclass in doxyparse.classes:
> 	for amethod in methods:
> 		self_ref = "TSelf"
> 		if amethod.name == "Create":
> 			self_ref = "TClass"
> 			wxc_header += "%s(%s) " % (self_ref, aclass.name)
> 		else:
> 			wxc_header += "%s " % (wxc_type_for_type(amethod.return_type)
> 
> 		wxc_header += "%s_%s( %s _obj" % (aclass.name, amethod.name,  
> self_ref + (" + aclass.name + ")")
> 
> 		for param in amethod.params:
> 			wxc_header += ", %s %s" % (wxc_type_for_type(param["type"]), "_" +  
> param["declname"])
> 			# Note: uncomment this if you support adding default values
> 			# if "defval" in param:
> 			#	wxc_header += "=" + param["defval"]
> 		wxc_header += " );\n"
> 
> wxc_file = open("wxc.h", "wb")
> wxc_file.write(wxc_header)
> wxc_file.close()
> 
> # end code
> 
> This is all just pseudo-code, and methods like wxc_type_for_type would  
> need implemented, and you'd also need to probably work out some  
> special logic for constructors, a list of classes to exclude, etc. but  
> this should give you an idea of how to start things off. Ideally you'd  
> actually have your own generate_c_bindings.py file that does an  
> "import doxyparser", then runs "doxyparse.parse()" itself rather than  
> extending the doxymlparser.py script, but anyway, just some ideas.

I have made an initial attempt at a c_wrapper.py program. It is far from
finished, but like the XSLT program, I did it to see if it was feasible.
I have attached the program.

My initial imprecision is that this could work out. Python is a very
nice language, and it was a joy to make my little program. I am already
further along than with the XSLT program, and I have spend a third of
the time. And more importantly, it did not feel painful at all.

I had to change doxymlparser.py a bit though, otherwise we get
type-names like constwxString:

> svn diff:

Index: doxymlparser.py
===================================================================
--- doxymlparser.py	(revision 60099)
+++ doxymlparser.py	(working copy)
@@ -98,7 +98,11 @@
         if child.nodeType == child.ELEMENT_NODE and child.nodeName == "ref":
             text += getTextValue(child)
         if child.nodeType == child.TEXT_NODE:
-            text += child.nodeValue.strip()
+            #text += child.nodeValue.strip()
+            # We changed line above to remove qualifiers. Maybe we need another field on parameters?
+            for token in string.split(child.nodeValue.strip()):
+                if (token != "virtual" and token != "static" and token != "const"):
+                    text += token
             
     return text

Kevin, what do you think about this change?


The output looks like:

> python c_wrapper.py out/xml/classwx_button.xml | indent

/* Constructor */
       wxButton wxButton_wxButton ();
/* Constructor */
     wxButton wxButton_wxButton (wxWindow * _parent, wxWindowID _id,
				 wxString & _label, wxPoint & _pos,
				 wxSize & _size, long _style,
				 wxValidator & _validator, wxString & _name);
     void wxButton_Destruct (wxButton * _obj);
     bool wxButton_Create (wxButton _obj, wxWindow * _parent, wxWindowID _id,
			   wxString & _label, wxPoint & _pos, wxSize & _size,
			   long _style, wxValidator & _validator,
			   wxString & _name);
     wxString wxButton_GetLabel (wxButton _obj);
     wxWindow *wxButton_SetDefault (wxButton _obj);
     void wxButton_SetLabel (wxButton _obj, wxString & _label);
     wxSize wxButton_GetDefaultSize (wxButton _obj);


Greetings,

Mads Lindstrøm

Re: [wxhaskell-users] autogenerating wxc from wxWidgets Doxygen output?

[Mads L. <mad...@ya...>]

Hi

Eric Y. Kow wrote:
> On Sat, Apr 11, 2009 at 01:57:30 +0200, Mads Lindstrøm wrote:
> > Besides the overly verbose syntax, I did not feel like XSLT were a good
> > match for the task.
> 
> I realise you weren't talking about the syntax, but in case it plays a
> role in this, there is always PXSL, which has significantly dampened my
> dislike of all things XML
>   http://community.moertel.com/pxsl/
> 
> PXSL also has some XSLT shortcuts which are handy...

PSXL looks nice.

Actually, syntax was part of the problem. Maybe my English was not too
good in my post.

After "everything" turning XML in Java-land, I used to joke about people
making a programming language with XML syntax, which I thought to be
obviously stupid. So lesson is: Be careful about what you joke about it,
it might come true...


Greetings,

Mads Lindstrøm

Re: [wxhaskell-users] autogenerating wxc from wxWidgets?Doxygen output?

[Mads L. <mad...@ya...>]

Hi

Eric Y. Kow wrote:
> Thanks, Kevin!
> 
> I'm just forwarding to wxhaskell-users in case Mads has a reply :-)
> 
> I'll note that in the body of my message, I only cut and paste a small
> extract of the output.  Maybe this is what Mads was referring to?
> 
> email message attachment
> > -------- Forwarded Message --------
> > From: Kevin Ollivier <ke...@th...>
> > To: Eric Y.Kow <eri...@gm...>
> > Subject: Re: [wxhaskell-users] autogenerating wxc from
> > wxWidgets?Doxygen output?
> > Date: Fri, 10 Apr 2009 15:46:38 -0700
> > 
> > Hi Eric,
> > 
> > 
> > The return type bug should be fixed now if you update your script.
> > However, I see both wxButton::wxButton constructors (one that takes
> > no params, and one that takes several) in your output. Do you not
> > see them?

Not the first time - I must go have my eyes checked - hehe.

Cool with respect to the return type bug. I will check it out tomorrow,
as it is getting really late where I live.


Greetings,

Mads Lindstrøm

Re: [wxhaskell-users] autogenerating wxc from wxWidgets Doxygen output?

[Eric Y. K. <eri...@gm...>]

On Sat, Apr 11, 2009 at 01:57:30 +0200, Mads Lindstrøm wrote:
> Besides the overly verbose syntax, I did not feel like XSLT were a good
> match for the task.

I realise you weren't talking about the syntax, but in case it plays a
role in this, there is always PXSL, which has significantly dampened my
dislike of all things XML
  http://community.moertel.com/pxsl/

PXSL also has some XSLT shortcuts which are handy...

> It was hard to factor out common patterns - aka. the
> composability of XSLT seems poor. But this may just be my lack of
> experience with XSLT. If I could have done something smarter I am all
> ears.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9