wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] [Haskell-cafe] Re: wxHaskell - using XRC files

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

Hi Guenther, Gour

On Wed, 27 Jan 2010 13:38 +0100, "Gour" <go...@go...> wrote:
> On Wed, 27 Jan 2010 11:09:06 +0100
> >>>>>> "Günther" == Günther Schmidt <gue...@we...> wrote:
> 
> Günther> I'm looking for documentation on using XRC files with
> Günther> wxHaskell.
> 
> I'd like to find it too...so, far I've found only two samples:
> xrcmenu.xrc & controls.xrc.

You have found just about all there is, I'm afraid. It's on my list for
a Blog article, but as you may have realised, my list is quite long, and
the rate of service rather slow.

The basics are pretty straightforward if you have read and understood
the wxWidgets documentation on XRC.

- An XRC file needs to be loaded into a top level window.
- The objects created when the XRC file is loaded can be made available
to wxHaskell by name using the <widget>Res functions (you will find most
of them in Graphics.UI.WX.Controls)

There are quite a few things to watch out for:
- XRC is incompatible with Layout (the XRC contains its own sizers, and
Layout creates sizers suitable for a given window layout)
- You must load your control as a child of the window in which you
loaded the XRC file
- If you try to fetch a control whose name doesn't exist, or if you load
a control by name as the wrong type of control, you will almost
certainly crash irrecoverably (the crash is usually in the wxWidgets
.DLL/.so/.dylib)
- It is not really possible to control an XRC-based menu very well. As
an example, I have never succeeded in disabling a menu option
- I also have not succeeded in getting XRC to work with wxHaskell custom
controls (and I've tried fairly hard). This is currently a show-stopper
for me. I very much doubt that this will ever work without putting
wxHaskell support into a GUI builder, since wxHaskell custom widgets do
not look (to C++) quite the same as C++ custom widgets.

The whole of the XRC support really needs a typesafe veneer over it (if
you search the wxhaskell-devel archives, there was a proof of concept
for doing this proposed about 8 months ago), and probably some
wxHaskell-specific work in a GUI builder.

I'll do my best to answer any specific questions you have.

Best regards
Jeremy

> Günther> BTW: I'm using wxFormBuilder, any other good tools out there?
> 
> Besides wxFormBuilder I played with DialogBlocks (eval version 'cause
> it's not free).
> 
> 
> Sincerely,
> Gour
> 
> -- 
> 
> Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
> ----------------------------------------------------------------
-- 
  Jeremy O'Donoghue
  jer...@gm...

Re: [wxhaskell-users] learning wxhaskell

[Fernando B. <gre...@gm...>]

Hi Gour, I think I was in the same situation as yourself when I begun  
the development of my project, λPage, and what I did was simply dive  
into wxHaskell without any previous reading.
Some tools were very useful to me (and they still are):

Hayoo! Whenever I wanted to, say, paste something on a textbox, I  
tried to find something like textCtrlPaste or something like that and  
then learn (or guess :P) what the attributes of that function may  
represent
Google Code Search As the wxhaskell project is open-sourced, looking  
for something like "textCtrlPaste lang:haskell" should take to  
(hopefully) a piece of code where it was used or, at least, the  
definition of the function
The Online Documentation It may not be complete in the sense that it  
doesn't explain everything but at least there're all the available  
functions and their names are pretty declarative.  And, if you've  
found a function there and you don't know what it does exactly, you  
can always break its name into class and method (e.g. TextCtrl::Paste)  
and use...
The WxWidgets Official Documentation

<--! Advertisement - skip this part if you just want information :P -->
Of course, you can use λPage to work instead of ghci and take  
advantage of its GUI, its Hayoo! and Cabal integration and, of course,  
its open-sourced code.
Man, I need to spread the word about my work, right? :P
<--! Advertisement ended -->

Finally, you can subscribe to a great blog, recently started by Jeremy  
O'Donoghue and keep learning new tips and tricks there.

Hope this helps,
cheers

Fernando Benavides
wxHaskell User & Hawk Oculyst
gre...@gm...


On Jan 27, 2010, at 9:41 AM, Gour wrote:

> Hiya!
>
> I'm interested what do you recommend for learning wxhaskell for
> someone who does not 'speak well' C++: using e.g. wxpython
> docs/literature or official C++ doc and/or wxWidgets book (until we
> get complete docs for wxhaskell) ?
>
>
> Sincerely,
> Gour
>
> -- 
>
> Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
> ----------------------------------------------------------------
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com_______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] learning wxhaskell

[Gour <go...@go...>]

Hiya!

I'm interested what do you recommend for learning wxhaskell for
someone who does not 'speak well' C++: using e.g. wxpython
docs/literature or official C++ doc and/or wxWidgets book (until we
get complete docs for wxhaskell) ?


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] GUI: Custom widgets - wxHaskell or gtk2hs ?

[Andy G. <ha...@gi...>]

Hi Günther,

> I need to create a custom widget and I wonder which of the above gui- 
> toolkits makes that easier.

I can't comment on anything other than wx, but you might find this  
(recently started, and thus up-to-date and active) blog interesting -  
it discusses custom widget creation using wx:

http://wewantarock.wordpress.com/2010/01/07/custom-controls-in-wxhaskell-part-1/

(is the start page)

Hope this helps,

-Andy

--
Andy Gimblett
http://gimbo.org.uk/

[wxhaskell-users] about FunctionalForms

[Günther S. <gue...@we...>]

Hi,

does anyone have any practical experience with FunctionalForms 
(http://www.sandr.dds.nl/FunctionalForms/)?

It seems interesting and might possibly still run. Does it help to 
remove boilerplate code?

Günther

[wxhaskell-users] [RESOLVED] Re: wxhaskell vs. gtk2hs

[Gour <go...@go...>]

On Wed, 20 Jan 2010 18:35:08 +0000
>>>>>> "Jeremy" == "Jeremy O'Donoghue" wrote:


Jeremy> I wish you luck in your decision, and will try to support you
Jeremy> if you choose wxHaskell

Let me just tell you that after being informed from the people working
on Gtk-OSX project that "If OSX is an important platform for you, I
strongly recommend you choose wx over gtk. Gtk's OSX support has
gotten much better since last summer, but OSX is still very much an
afterthought to the Gtk+ developers." and some more info, I've decided
that we'll try to build our desktop GUI application using wxhaskell
libs.


Thanks everyone for all the input.


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] Folding a widget

[Henk-Jan v. T. <hj...@ch...>]

I attached the program to this e-mail, as the copy-paste in the previous  
one went horribly wrong (seems to be a Windows XP problem).

On Sat, 23 Jan 2010 22:41:16 +0100, Henk-Jan van Tuyl <hj...@ch...>  
wrote:

> On Sat, 23 Jan 2010 17:33:33 +0100, Günther Schmidt <gue...@we...>
> wrote:
>
>> Hi,
>>
>> I'd like to be able to "fold" away a widget on button click. I manage to
>> make it disappear but the space it used to occupy is still occupied.
>>
>> How can I "fold" it away? Like in a Tree View?
>>
>> Günther
>
>
> You could do it the like this (if you press the button "Remove me", its
> place will be taken by button "Close"):
>
>> import Graphics.UI.WX
>
>> main :: IO ()
>> main = start $
>>  do
>>   f  <- frame   [ fontSize   := 18
>>                 , clientSize := sz 200 200                ]
>>
>>   ok0 <- button f [ on command := close f
>>                   , text       := "Close"                  ]
>>   ok1 <- button f [ text       := "Remove me"                  ]
>>
>>   set ok1 [ on command :=              do                set ok1 [
>> visible := False ]
>>                 set f   [ layout  := column 1 [ widget ok0 ] ]
>>           ]
>>
>>   set f [ layout :=            column 1 [ widget ok1
>>                      , widget ok0
>>                      ]
>>         ]
>>
>>   return ()
>
>
> Met vriendelijke groet,
> Henk-Jan van Tuyl
>
>
> --
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> --
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important issues  
> through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users


-- 
Met vriendelijke groet,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://functor.bamikanarie.com
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

Re: [wxhaskell-users] Folding a widget

[Henk-Jan v. T. <hj...@ch...>]

On Sat, 23 Jan 2010 17:33:33 +0100, Günther Schmidt <gue...@we...>  
wrote:

> Hi,
>
> I'd like to be able to "fold" away a widget on button click. I manage to
> make it disappear but the space it used to occupy is still occupied.
>
> How can I "fold" it away? Like in a Tree View?
>
> Günther


You could do it the like this (if you press the button "Remove me", its  
place will be taken by button "Close"):

> import Graphics.UI.WX

> main :: IO ()
> main = start $
>  do
>   f  <- frame   [ fontSize   := 18
>                 , clientSize := sz 200 200                ]
>
>   ok0 <- button f [ on command := close f
>                   , text       := "Close"                  ]
>   ok1 <- button f [ text       := "Remove me"                  ]
>
>   set ok1 [ on command :=              do                set ok1 [  
> visible := False ]
>                 set f   [ layout  := column 1 [ widget ok0 ] ]  
>           ]
>
>   set f [ layout :=            column 1 [ widget ok1
>                      , widget ok0
>                      ]
>         ]
>
>   return ()


Met vriendelijke groet,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Gour <go...@go...>]

On Sat, 23 Jan 2010 10:47:33 -0800
>>>>>> "Conal" == Conal Elliott wrote:

Conal> I'm adopting this term "denotative" from Peter Landin's seminal
Conal> paper "The Next 700 Programming Languages".  See
Conal> http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882.
Conal>   Previously I've been using the alternative "denotational".

Thanks for the reference.

Conal> I expect that even libraries like wx/gtk+ *can* be used as part
Conal> of a faithful implementation of denotative GUI programming, if
Conal> we take great care to insulate our denotation from the complex
Conal> semantics of those libraries. However, this insulation may be so
Conal> difficult to establish and maintain that it's easier to start
Conal> from scratch.

It would be good to be able to use those libs considering that Haskell
community (at the moment) does not even have evenough man-power to
adequately maintain language bindings, what to speak of developing &
maintaining the whole toolkit.

Otoh, I'm aware it won't come soon...


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Conal E. <co...@co...>]

2010/1/22 Günther Schmidt <gue...@we...>

> Hi Conal,
>
> I recently switched my app from Haskell to Smalltalk because I was
> unable to code interdependent widgets with wxHaskell, ie. a bunch of
> dropdowns where changing the value of one needs to change the set of
> elements available in others.
>
> Well I was unable to code this in Haskell without using tons of either
> MVars or IORefs.
>
> If you know of a way or an example to do this in wxHaskell I'd certainly
> appreciate it if you'd share it with us.
>

I haven't delved far into what can be done with wxHaskell.  I've been more
interested in exploring functional/denotative GUI programming.


> The plain business logic of the app was so simple to code in haskell it
> was a pleasure. But I could not code the GUI part in wxHaskell, I just
> wouldn't know how and neither in gtk2hs for that matter.
>
> I also had the impression that the higher level projects in the GUI or
> FRP department are all started and then gotten stuck and abandoned, it
> seems to be an unsolved issue, please correct me if I'm wrong.
>

> Günther
>


Yes, I'd say unsolved as well.  Work continues.  I'm optimistic.

   - Conal


Am 23.01.10 02:15, schrieb Conal Elliott:
> > Hi Gour,
> >
> > I've worked with both wxhaskell and gtk2hs.  I prefer wxhaskell for
> > elegant design.  And I like that it gives me a native Mac OS X look.
> > There is a partially working native Gtk for Mac, but I don't think it
> > works with 3D, which was a requirement for me.  The X11 mode is painful
> > & ugly, and awfully disappointing considering how much more expensive a
> > Mac is than a Linux machine.
> >
> > In spite of these reasons, I'm using gtk2hs for the time being, because
> > wxhaskell has a problem that makes it very unfriendly to ghci.  The
> > second attempt to display a GUI kills its host process.  This behavior
> > is okay for many (but not all) compiled programs, but is a killer for
> > interactive/exploratory development.  As soon as I hear that this
> > problem is fixed, I'll very happily return to wxhaskell.
> >
> > Longer term, I want Haskell GUI programming to move away from these
> > massively complex OO imperative frameworks to something much more
> > elegant and harmonious with the spirit and benefits of pure
> > functional/denotative programming.
> >
> > Regards,  - Conal
> >
> > On Tue, Jan 19, 2010 at 1:59 AM, Gour
> > <go...@go...
> > <mailto:go...@go...>> wrote:
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Conal E. <co...@co...>]

On Fri, Jan 22, 2010 at 11:23 PM, Gour <go...@go...> wrote:

> On Fri, 22 Jan 2010 17:15:00 -0800
> >>>>>> "Conal" == "Conal Elliott" wrote:
>
> Hello Conal,
>
> Conal> I've worked with both wxhaskell and gtk2hs.  I prefer wxhaskell
> Conal> for elegant design.  And I like that it gives me a native Mac OS
> Conal> X look.  There is a partially working native Gtk for Mac, but I
> Conal> don't think it works with 3D, which was a requirement for me.
>
> This is nice to hear about wxhaskell.
>
> Conal> In spite of these reasons, I'm using gtk2hs for the time being,
> Conal> because wxhaskell has a problem that makes it very unfriendly to
> Conal> ghci.  The second attempt to display a GUI kills its host
> Conal> process.  This behavior is okay for many (but not all) compiled
> Conal> programs, but is a killer for interactive/exploratory
> Conal> development.  As soon as I hear that this problem is fixed, I'll
> Conal> very happily return to wxhaskell.
>
> Isn't it that, at one point of time, gtk2hs has similar problem when
> working within ghci?
>

I don't know gtk2hs's history.


> Conal> Longer term, I want Haskell GUI programming to move away from
> Conal> these massively complex OO imperative frameworks to something
> Conal> much more elegant and harmonious with the spirit and benefits of
> Conal> pure functional/denotative programming.
>
> I must say that I'm looking/reading your FRP stuff from the distance
> thinking it's way above the head of this Haskell noob, but I tend to
> agree that it should be possible to do GUI in Haskell in a different
> way.
>

And not just a *different* way, but specifically a *denotative* way, i.e. in
which our programs are built entirely out of pieces that have tractably
precise meanings.

I'm adopting this term "denotative" from Peter Landin's seminal paper "The
Next 700 Programming Languages".  See
http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882.
  Previously I've been using the alternative "denotational".


> Do you consider it can be achieved on the top of present libs like
> wx/gtk+ or it would require writing new stuff?
>

I expect that even libraries like wx/gtk+ *can* be used as part of a
faithful implementation of denotative GUI programming, if we take great care
to insulate our denotation from the complex semantics of those libraries.
However, this insulation may be so difficult to establish and maintain that
it's easier to start from scratch.

   - Conal

[wxhaskell-users] Question about compilation

[Matthieu Ouellette-V. <mat...@gm...>]

Hello everyone,

I would like to know how can I tell wxHaskell to choose a different
wxWidegts build than the default one that comes with Mac OS X ? I tried
different things but didn't succeeded for now. I tried to change my PATH
environment variable and also tried to set the WXWIN variable but without
success. Also tried to set CPPFLAGS and LDFLAGS to the output generated by
wx-config --cxxflags and wx-config --libs respectively but again, no
success.

Thanks in advance,
Matt

[wxhaskell-users] Folding a widget

[Günther S. <gue...@we...>]

Hi,

I'd like to be able to "fold" away a widget on button click. I manage to 
make it disappear but the space it used to occupy is still occupied.

How can I "fold" it away? Like in a Tree View?

Günther

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Gour <go...@go...>]

On Fri, 22 Jan 2010 17:15:00 -0800
>>>>>> "Conal" == "Conal Elliott" wrote:

Hello Conal,

Conal> I've worked with both wxhaskell and gtk2hs.  I prefer wxhaskell
Conal> for elegant design.  And I like that it gives me a native Mac OS
Conal> X look.  There is a partially working native Gtk for Mac, but I
Conal> don't think it works with 3D, which was a requirement for me.

This is nice to hear about wxhaskell.

Conal> In spite of these reasons, I'm using gtk2hs for the time being,
Conal> because wxhaskell has a problem that makes it very unfriendly to
Conal> ghci.  The second attempt to display a GUI kills its host
Conal> process.  This behavior is okay for many (but not all) compiled
Conal> programs, but is a killer for interactive/exploratory
Conal> development.  As soon as I hear that this problem is fixed, I'll
Conal> very happily return to wxhaskell.

Isn't it that, at one point of time, gtk2hs has similar problem when
working within ghci?

Conal> Longer term, I want Haskell GUI programming to move away from
Conal> these massively complex OO imperative frameworks to something
Conal> much more elegant and harmonious with the spirit and benefits of
Conal> pure functional/denotative programming.

I must say that I'm looking/reading your FRP stuff from the distance
thinking it's way above the head of this Haskell noob, but I tend to
agree that it should be possible to do GUI in Haskell in a different
way.

Do you consider it can be achieved on the top of present libs like
wx/gtk+ or it would require writing new stuff?


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Günther S. <gue...@we...>]

Hi Conal,

I recently switched my app from Haskell to Smalltalk because I was 
unable to code interdependent widgets with wxHaskell, ie. a bunch of 
dropdowns where changing the value of one needs to change the set of 
elements available in others.

Well I was unable to code this in Haskell without using tons of either 
MVars or IORefs.

If you know of a way or an example to do this in wxHaskell I'd certainly 
appreciate it if you'd share it with us.

The plain business logic of the app was so simple to code in haskell it 
was a pleasure. But I could not code the GUI part in wxHaskell, I just 
wouldn't know how and neither in gtk2hs for that matter.

I also had the impression that the higher level projects in the GUI or 
FRP department are all started and then gotten stuck and abandoned, it 
seems to be an unsolved issue, please correct me if I'm wrong.

Günther




Am 23.01.10 02:15, schrieb Conal Elliott:
> Hi Gour,
>
> I've worked with both wxhaskell and gtk2hs.  I prefer wxhaskell for
> elegant design.  And I like that it gives me a native Mac OS X look.
> There is a partially working native Gtk for Mac, but I don't think it
> works with 3D, which was a requirement for me.  The X11 mode is painful
> & ugly, and awfully disappointing considering how much more expensive a
> Mac is than a Linux machine.
>
> In spite of these reasons, I'm using gtk2hs for the time being, because
> wxhaskell has a problem that makes it very unfriendly to ghci.  The
> second attempt to display a GUI kills its host process.  This behavior
> is okay for many (but not all) compiled programs, but is a killer for
> interactive/exploratory development.  As soon as I hear that this
> problem is fixed, I'll very happily return to wxhaskell.
>
> Longer term, I want Haskell GUI programming to move away from these
> massively complex OO imperative frameworks to something much more
> elegant and harmonious with the spirit and benefits of pure
> functional/denotative programming.
>
> Regards,  - Conal
>
> On Tue, Jan 19, 2010 at 1:59 AM, Gour
> <go...@go...
> <mailto:go...@go...>> wrote:
>

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Conal E. <co...@co...>]

Hi Gour,

I've worked with both wxhaskell and gtk2hs.  I prefer wxhaskell for elegant
design.  And I like that it gives me a native Mac OS X look.  There is a
partially working native Gtk for Mac, but I don't think it works with 3D,
which was a requirement for me.  The X11 mode is painful & ugly, and awfully
disappointing considering how much more expensive a Mac is than a Linux
machine.

In spite of these reasons, I'm using gtk2hs for the time being, because
wxhaskell has a problem that makes it very unfriendly to ghci.  The second
attempt to display a GUI kills its host process.  This behavior is okay for
many (but not all) compiled programs, but is a killer for
interactive/exploratory development.  As soon as I hear that this problem is
fixed, I'll very happily return to wxhaskell.

Longer term, I want Haskell GUI programming to move away from these
massively complex OO imperative frameworks to something much more elegant
and harmonious with the spirit and benefits of pure functional/denotative
programming.

Regards,  - Conal

On Tue, Jan 19, 2010 at 1:59 AM, Gour <go...@go...> wrote:

> Hiya!
>
> Haskell noob considering to write desktop gui app by developing on
> Linux...
>
> Moreover, I'd like the application to be multi-platform and to be
> nicely supported on Mac OS X and finally (the least priority) on
> Windows.
>
> For long time I was considering gtk2hs (yeah, I'm 'learning' Haskell
> too long), but recently one of the important targets for the app
> switched from Windows to Mac, and now I'm considering wxhaskell as
> well...
>
> Now, based on what I know so far wxhaskell may be better supported on
> Mac since GTK+ port is not finished. otoh, I'm a bit concerned about
> "Since the core interface is generated automatically from the wxEiffel
> binding..." and visiting the project show the status notice:
>
> "The 0.7 release will probably be the last official release.
>
> The project lost its core developer following the 0.7 release in late
> June 2003 and it is unlikely that anyone will be able to take on this
> vital role. "
>
> So, my question is if this dependency on wxEiffel will change soon,
> especially considering the upcoming wx-3.0 release?
>
> Another concern is question of memory management touched upon in the
> following article:
>
> http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/
>
>
> So, can someone share some thoughts about gtk2hs vs. wxhaskell with
> the reference to ease of use, learning curve etc. for a noob not being
> too familiar with none of the toolkits and considering suitability for
> multi-platform development in Haskell for (priority order) Linux, Mac
> and Windows?
>
>
> I've noticed that wxhaskell is improving ease of install (I'm arch
> user) -
>
> http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/
>
> and it may be that more devs are actively working on it atm.
>
> Otoh, wx toolkit is often not very much likened (upon mentioning it),
> at least, on Linux platform where people recommend Qt and GTK+ (in
> general, I prefer GTK+ look over Qt which I do not consider as
> option). Why is it so?
>
>
> Sincerely,
> Gour
>
> --
>
> Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
> ----------------------------------------------------------------
>

Re: [wxhaskell-users] FindReplaceData Issue

[Fernando B. <gre...@gm...>]

Hi, me again... I'm using the current darcs version of wxhaskell (darcs get
--partial --set-scripts-executable http://code.haskell.org/wxhaskell/) and
seems like this patch is not applied and the code in eljfindrepldlg.cpp is
wrong again.
Can someone check it out, please?
Thanks.


Marie von Ebner-Eschenbach<http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html>
- "Even a stopped clock is right twice a day."

2009/10/1 shelarcy <she...@gm...>

> Pushed. Thanks,
>
>
> On Thu, 01 Oct 2009 11:05:54 +0900, shelarcy <she...@gm...> wrote:
>
>> On Thu, 01 Oct 2009 06:01:36 +0900, Eric Y. Kow <eri...@gm...>
>> wrote:
>>
>>> On Wed, Sep 30, 2009 at 17:59:00 -0300, Fernando Benavides wrote:
>>>
>>>> I'm attaching the patch because (after just 5'' trying - I'm in my
>>>> workplace
>>>> now :P) I couldn't get darcs send to work.
>>>>
>>>
>>> Thanks for being a good sport about this!  Could somebody on the
>>> wxHaskell Team take a look at Fernando's patch?
>>>
>>
>> I think this is a reasonable change. So, I'll push his patch after
>> trying to build wxHaskell with it.
>>
>
> --
> shelarcy <shelarcy    hotmail.co.jp>
> http://page.freett.com/shelarcy/
>

Re: [wxhaskell-users] wxHaskell documentation

[Gour <go...@go...>]

On Thu, 21 Jan 2010 11:59:01 +0000
>>>>>> "Jeremy" == "Jeremy O'Donoghue" wrote:

Jeremy> Documentation and its layout are not always as clear as they
Jeremy> could be for wxHaskell. Despite the fact that it is not the
Jeremy> most 'interesting' or 'fun' thing for me to work on, I plan to
Jeremy> do quite a bit of work on this in the coming weeks. 

Hooray!

Jeremy> Some will reflect itself in updated documentation in the source
Jeremy> code and other aspects will probably turn into blog
Jeremy> (http://wewantarock.wordpress.com) articles.

The only wxhaskell tutorials are those referenced on the wiki?

Jeremy> 1) The wrappings over the wxWidgets library. These are
Jeremy> essentially C versions of wxWidgets C++ APIs,

It means one can practically call any low-level C-API wxwidgets
function?

Jeremy> 3) Higher-level (i.e. more declarative) functionality in
Jeremy> Graphics.UI.WX - again, sparsely but adequately
Jeremy>    documented.

Having some more complete/advanced tutorial would probably help to
become familiar with usage of higher-level API.

Jeremy> To really interpret what the functions do, you need to find the
Jeremy> appropriate method names. One rule you need to know is that
Jeremy> <widgetname>Create is a wrapper for the C++ constructor - in
Jeremy> other words, we should look at wxGrid() to find out what
Jeremy> gridCreate does. Things get a bit more complicated for
Jeremy> overloaded constructors and methods, but it's usually not too
Jeremy> hard to work out.

Heh, the above 'rule' really helps. Is there any doc which explains
those wxwidgets <---> wxhaskell mappings?

Jeremy> The bad (and not really satisfactory, from a Haskell
Jeremy> perspective) aspect of this is that you really need to have at
Jeremy> least a limited ability to read C++ to understand this.

I hope that 'limited' really means 'quite limited' in order that we can
avoid jumping into C++ (I did it long ago in the era of Zortech C++
compiler, but then I was 'young' and now I'm not interested in C++
whatsoever.)

Jeremy> I hope that documentation will be an aspect of wxHaskell which
Jeremy> improves significantly in the near future.

That would be wonderful and give us inspiration to work on enhancing
wxhaskell further?

Have you considered moving the project to some (other) public hosting
with better bug tracker etc. ?

SF is really becoming obsolete. (Although I'm darcs fan myself, I'll
probably use Launchpad for other aspect of project managament - their
bugtracker has decent email interface as well.)

Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Gour <go...@go...>]

On Thu, 21 Jan 2010 12:32:16 +0000
>>>>>> "Jeremy" == "Jeremy O'Donoghue" wrote:

Jeremy> I have just updated the wiki text here. Thanks for the
Jeremy> information.

Thanks a lot. Now it's much more encouraging for someone considering
to use wxhaskell.

Jeremy> I need to look into this a bit further.

OK.

Jeremy> I expect that this investigation will turn into a blog article,
Jeremy> as it really involves tracing the lifecycle of a control.

That would be very good since the referenced article makes some strong
statements as: "...wxHaskell in that sense is worse than any Java
Swing/AWT application since even there you don’t have to worry about
freeing objects."

Jeremy> Almost all of the core widgets are wrapped, although some of
Jeremy> the more complex ones are not. Much of the non-essential and
Jeremy> non-GUI related functionality does not get much attention
Jeremy> because Haskell generally already has very satisfactory (and
Jeremy> idiomatic) libraries for these..


Nice to hear...Maybe it would be good to have some kind of 'status'
page generated showing what is remaining to be bound and what is
covered to help potential contributors to know where/how to help?

Jeremy> To be honest, it will probably happen (almost immediately)
Jeremy> when Haskell Platform is released with 6.12.x - I really
Jeremy> don't have the time Jeremy> to compile GHC and the minimum 
Jeremy> set of libraries myself. It may even work out of the box 
Jeremy> (at most with minimal library dependency changes).

Thank you. Now it's clear that wxhaskell is following HP.

Jeremy> From what I can see of wxWidgets 2.9.x, it's pretty
Jeremy> evolutionary without radical changes. We already use the 
Jeremy> Unicode build of wxWidgets, and pervasive Unicode is one 
Jeremy> of the headline features for 2.9.x/3.0

OK.

I saw one thread in wx mailing list (http://tinyurl.com/yandrh3) from
where I've concluded that VZ has on mind something more drastic than
what 3.0 brings up.

Jeremy> I believe any tools should generate the same XRC. I found
Jeremy> wxFormBuilder to be fine, but DialogBlocks is probably a 
Jeremy> good alternative.

Thanks for the tips.

Jeremy> One issue for me is that XRC really violates type-safety in
Jeremy> wxHaskell. 

Hmm...afaics, looking at gtk2hs glade-example, I've feeling that
type-safety works there:

************* code-here*********************
-- load up the glade file
	 dialogXmlM <- xmlNew "simple.glade"
	 let dialogXml = case dialogXmlM of
	       (Just dialogXml) -> dialogXml
	       Nothing -> error "can't find the glade file \"simple.glade\" \
				\in the current directory"
	 
	 -- get a handle on a couple widgets from the glade file
	 window <- xmlGetWidget dialogXml castToWindow "window1"
	 button <- xmlGetWidget dialogXml castToButton "button1"

 [...]
************* code-here ****************************************

Is it possible to achieve it with XRC?

Jeremy> I think a better way forward in the long run will be
Jeremy> to have a tool which generates code from XRC, rather than
Jeremy> loading the resources using the resource subsystem.

Huh, that would be terrific, but it should (probably) come from the
wxhaskell team adding support to some GUI tool, do you agree?


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] [Gtk2hs-users] GUI: Custom widgets - wxHaskell or gtk2hs ?

[Axel S. <Axe...@in...>]

Hi Günther,

I suppose that at the end of the day, both toolkits will provide a  
very similar interface: You create some sort of raw widget  
(DrawingArea for Gtk2Hs) and then react to expose events. Gtk2Hs also  
has some other widgets that allow you to have widgets within your  
custom widget (Layout widget). See demo/cairo, demo/fastdraw demo/ 
graphic or demo/carsim on examples for DrawingArea.

Hope this helps,
Axel.

On 21.01.2010, at 14:22, Günther Schmidt wrote:

> Hi,
>
> I need to create a custom widget and I wonder which of the above
> gui-toolkits makes that easier.
>
> Günther
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Gtk2hs-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-users

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

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

Hi Gour,

On 20 January 2010 19:30, Gour <go...@go...> wrote:

> On Wed, 20 Jan 2010 18:35:08 +0000
> >>>>>> "Jeremy" == <
> jer...@pu...> wrote:
> Please, for the sake of wxhaskell, remove/explain/resolve this issue.
>
> I have just updated the wiki text here. Thanks for the information.


> Jeremy> > Another concern is question of memory management touched upon
> Jeremy> > in the following article:
> Jeremy> >
> Jeremy> >
> http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/
>
> What about this issue?
>

I need to look into this a bit further.

The wxHaskell documentation (Graphics.UI.WXCore.WxcOjbect) says "Objects are
not automatically deleted. Normally you can use a delete function like
windowDelete to delete an object. However, almost all objects in the
wxWindows library are automatically deleted by the library. The only objects
that should be treated with acre are resources [such] as bitmaps, fonts and
brushes" (the latter are reference counted objects in wxWidgets).

I expect that this investigation will turn into a blog article, as it really
involves tracing the lifecycle of a control.

How much (in %) of wxwidgets is bound in wxhaskell?
>

Almost all of the core widgets are wrapped, although some of the more
complex ones are not. Much of the non-essential and non-GUI related
functionality does not get much attention because Haskell generally already
has very satisfactory (and idiomatic) libraries for these..

>
> Jeremy> We have put a lot of effort into making wxHaskell
> Jeremy> installation 'just work' on all platforms using Cabal
> Jeremy> recently. You can generally cabal install wx on any
> Jeremy> platform with a working (recent) wxWidgets
> Jeremy> installation and it works perfectly.
>
> What is the plan for 6.12.1 support?
>
> To be honest, it will probably happen (almost immediately) when Haskell
Platform is released with 6.12.x - I really don't have the time to compile
GHC and the minimum set of libraries myself. It may even work out of the box
(at most with minimal library dependency changes).


> Is wx-3.0 part of wxTNG or the latter is quite different concept not
> coming into existance soon?
>

>From what I can see of wxWidgets 2.9.x, it's pretty evolutionary without
radical changes. We already use the Unicode build of wxWidgets, and
pervasive Unicode is one of the headline features for 2.9.x/3.0

>
> May I just ask, if it is relevant for you, do you use some GUI
> designer tool?
>
> I'm thinking about DialogBlocks (looks as better option for wxhaskell
> considering one needs only XRC support) vs. free wxFormBuilder,
> i.e. is DialogBlock justifies to be supported over free tool to be
> used for wxhaskell?
>
> I believe any tools should generate the same XRC. I found wxFormBuilder to
be fine, but DialogBlocks is probably a good alternative.

One issue for me is that XRC really violates type-safety in wxHaskell. I
think a better way forward in the long run will be to have a tool which
generates code from XRC, rather than loading the resources using the
resource subsystem.

Regards
Jeremy

[wxhaskell-users] GUI: Custom widgets - wxHaskell or gtk2hs ?

[Günther S. <gue...@we...>]

Hi,

I need to create a custom widget and I wonder which of the above 
gui-toolkits makes that easier.

Günther

Re: [wxhaskell-users] wxHaskell documentation

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

Hi David,

No-one else has answered, so I will do my best for you...

On Thu, 14 Jan 2010 13:15 +1300, "David Streader"
<ds...@cs...> wrote:
>     So *Question one*:  What is the best source of documentation?
> An example - I have successfully  used grids to generate layout for a 
> frame/ dialog.  But I need to know the name of a grid so that I can 
> later set some of its attributes (add rows cols, ....).  The only 
> commands I have found (in example code) to do this are

Documentation and its layout are not always as clear as they could be
for wxHaskell. Despite the fact that it is not the most 'interesting' or
'fun' thing for me to work on, I plan to do quite a bit of work on this
in the coming weeks. Some will reflect itself in updated documentation
in the source code and other aspects will probably turn into blog
(http://wewantarock.wordpress.com) articles.

The first thing to realize is that there are really three parts to
wxHaskell:

1) The wrappings over the wxWidgets library. These are essentially C
versions of wxWidgets C++ APIs,
   and they are mainly auto-generated from C code. The wrappings are
   almost undocumented beyond
   their types, and are mainly in the Graphics.UI.WXCore.Wxc****
   hierarchy. I recommend using the
   wxWidgets documentation to find out more about these - it is
   generally pretty straightforward
   to work out what wxWidgets class and function is involved, and it is
   often particularly useful
   to look up functions in WxcClassesAL and WxcClassesMZ, which covers
   most of the lowest level
   wrapping.
2) Low level bindings over the library wrapper (rest of WXCore) - these
are sparsely, but generally
   adequately documented
3) Higher-level (i.e. more declarative) functionality in Graphics.UI.WX
- again, sparsely but adequately
   documented.
 
> g <- gridCreate parent id rect flags
> gridCreateGrid g 0 0 0
> 
> But I have failed to find and documentation for gridCreate or 
> gridCreateGrid  where should I look.

For this specific example, look in the documentation for
Graphics.UI.WXCore.WxcClassesAL for 'Grid'. This lists a considerable
number (I didn't count, but it must be around 100) of functions,
including gridCreate and gridCreateGrid.

The documentation you will see is extremely brief. It says:

gridCreate :: Window a -> Id -> Rect -> Style -> IO (Grid ())
usage: (gridCreate prt id lfttopwdthgt stl)

gridCreateGrid :: Grid a -> Int -> Int -> Int -> IO ()
usage: (gridCreateGrid obj rows cols selmode)

To understand what these *really* do, we need to go look at the
wxWidgets documentation, which in this case is at
http://docs.wxwidgets.org/stable/wx_wxgrid.html#wxgrid. 

To really interpret what the functions do, you need to find the
appropriate method names. One rule you need to know is that
<widgetname>Create is a wrapper for the C++ constructor - in other
words, we should look at wxGrid() to find out what gridCreate does.
Things get a bit more complicated for overloaded constructors and
methods, but it's usually not too hard to work out.

So, finally, for your examples above:

gridCreate is a wrapper for wxGrid::wxGrid(wxWindow* parent, wxWindowID
id, const wxPoint& pos = wxDefaultPosition, const wxSize& size =
wxDefaultSize, long style = wxWANTS_CHARS, const wxString& name =
wxPanelNameStr)

"Constructor to create a grid object. Call either wxGrid::CreateGrid or
wxGrid::SetTable directly after this to initialize the grid before using
it."

gridCreateGrid is a wrapper for wxGrid::CreateGrid(int numRows, int
numCols, wxGrid::wxGridSelectionModes selmode =
wxGrid::wxGridSelectCells)
"Creates a grid with the specified initial number of rows and columns.
Call this directly after the grid constructor. When you use this
function wxGrid will create and manage a simple table of string values
for you. All of the grid data will be stored in memory.
For applications with more complex data types or relationships, or for
dealing with very large datasets, you should derive your own grid table
class and pass a table object to the grid with wxGrid::SetTable."

The bad (and not really satisfactory, from a Haskell perspective) aspect
of this is that you really need to have at least a limited ability to
read C++ to understand this.

> *Question two*: Would it be better to use the wxWidgets documentation?  
> if so is there any documented way to translate wxWidgets method calls  
> into Haskell?

Hopefully the example above covers this sufficiently?

I hope that documentation will be an aspect of wxHaskell which improves
significantly in the near future.

Best regards
Jeremy
-- 
  Jeremy O'Donoghue
  jer...@gm...

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Gour <go...@go...>]

On Wed, 20 Jan 2010 18:35:08 +0000
>>>>>> "Jeremy" == <jer...@pu...> wrote:

Hiya Jeremy,

Jeremy> > I'm not sure where you found this quote. A (small) team of
Jeremy> > developers took on maintenance of wxHaskell over three years
Jeremy> ago, and we have been keeping it up to date ever since.

Well, wiki page (http://haskell.org/haskellwiki/WxHaskell) under
Status section says: "Since the core interface is generated
automatically from the wxEiffel binding..." with the link to wxEiffel
project and there is Project Status/Warning (25 July 2003) link
leading to: http://elj.sourceforge.net/status/

and, believe me, it looks quite depressive for potential wxhaskell user.

Jeremy> While there are some vestiges of the Eiffel heritage in the
Jeremy> wxHaskell source code, there is no dependency on the wxEiffel
Jeremy> binding. The dependency on wxEiffel really disappeared before I
Jeremy> became involved in the project.

Please, for the sake of wxhaskell, remove/explain/resolve this issue.


Jeremy> The latest wxHaskell release supports wxWidgets 2.8.10 (which I
Jeremy> believe is the most recent stable version), and we will update
Jeremy> to wxWidgets 3.0 shortly after this becomes available.

This sounds great!!

Jeremy> > Another concern is question of memory management touched upon
Jeremy> > in the following article:
Jeremy> >
Jeremy> > http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/

What about this issue?

Jeremy> I suspect in practice that the learning curves are pretty
Jeremy> similar. I haven't done enough gtk2hs programming to be
Jeremy> certain, but the samples look really pretty similar, and the
Jeremy> programing style is a bit more imperative than many Haskell
Jeremy> programmers really like in both cases. This is somewhat
Jeremy> unavoidable given that the underlying toolkits are stateful
Jeremy> object-oriented in design.

This is nice to hear that wx(haskell) is not much harder that gtk(2hs).

As far as imperative style is concerned, it seems that FRP is not
ready yet, so noting to complain about here.

Jeremy> I originally became involved with wxHaskell after doing some
Jeremy> GTK GUIs (in Ocaml) for Windows at home, and being disappointed
Jeremy> with the results (and licensing issues - see below) - in fact,
Jeremy> this is how I first came to look at Haskell...

I'm too long involved with Haskell without learning it, but I'm not
giving it up and this time really determined to seriously jump
in. (I'm reading RWH atm.)

Jeremy> Mac is another story.

I'm more interested to get good support for Mac than on Windows.

Jeremy> AFAIK, the native GTK for Mac is still considered to be pretty
Jeremy> unstable, and the default theme, while functional, looks
Jeremy> like... GTK on Linux.

Yeah, I've found out that Imendio is not in business and GTK port is
not complete.

Jeremy> wxWidgets (and wxHaskell) works very well on Mac - we have
Jeremy> support for creating application bundles, and UIs look
Jeremy> completely native. The same is true for Windows (I work about
Jeremy> 90% on Windows with wxHaskell)

How much (in %) of wxwidgets is bound in wxhaskell?

Jeremy> wxHaskell works fine on Linux, but since it depends on GTK to
Jeremy> render widgets, you'll have better performance and a smaller
Jeremy> app footprint if you just use gtk2hs, to be honest.

This is not critical for my app. The main number crunching will be,
anyway, done with Haskell bindings for some C-lib.

Jeremy> I guess the scorecard is therefore:
Jeremy> 
Jeremy>    - Ease of use - wxhaskell and gtk2hs about equal

:-)
Jeremy>    - Linux development - both work well, but gtk2hs scores
Jeremy> slightly for performance and app footprint

:-)

Jeremy>    - Mac development - I definitely prefer wxHaskell. Native
Jeremy> look is *vital* for acceptability on Mac

:-D

Jeremy>    - Windows development - both work well, but wxhaskell scores
Jeremy> for performance and app footprint

:-))

Jeremy>  This means you will really need to weigh up the importance of
Jeremy> portability.

Here the weight goes to wxhaskell. It seems that's easier to learn
wx(widgets)haskell and have decent native look & feel instead of
fiddling with some platform-related issues by using some other
toolkit.

Jeremy> You don't mention documentation. I think the truth here is that
Jeremy> neither gtk2hs nor wxHaskell is as well documented as it should
Jeremy> be. 

Well, I must say that, although it is improving, it is something one
has to learn when having encounter with libs in Haskell. :-/


Jeremy> There are certainly bugs and strange behaviour in wxHaskell
Jeremy> that are not really documented well. I'm trying to change this
Jeremy> (in particular, the lack of 'intermediate level' on wxHaskell
Jeremy> information) in a new blog: http://wewantarock.wordpress.com

I saw it - it looks intriguing to create custom controls in Haskell,
but it is still way above my head.

Jeremy> We have put a lot of effort into making wxHaskell
Jeremy> installation 'just work' on all platforms using Cabal 
Jeremy> recently. You can generally cabal install wx on any 
Jeremy> platform with a working (recent) wxWidgets 
Jeremy> installation and it works perfectly.

What is the plan for 6.12.1 support?

Jeremy> If I was writing a cross-platform app in C++, money no object,
Jeremy> I would probably choose Qt. Honestly, it's the best documented,
Jeremy> best designed and most complete of the toolkits. It does
Jeremy> require an (expensive) developer license for commercial
Jeremy> applications, which limits the appeal.

Heh, somehow I do not like Qt and although the licensing had changed,
I prefer to use community-driven toolkit instead of depending on some
corporation's mercy. Just see the situation with Maemo...

Jeremy> For me, wxWidgets is a good alternative because it provides a
Jeremy> 'native' UI experience on all platforms, is pretty robust and
Jeremy> complete, well documented and liberally licensed (commercial
Jeremy> applications explicitly permitted by the license). The
Jeremy> programming style is not as nice as Qt, but is, for me,
Jeremy> slightly preferable to GTK (my personal opinion is that the API
Jeremy> design is jut a little more consistent.

Is wx-3.0 part of wxTNG or the latter is quite different concept not
coming into existance soon?

Jeremy> The final killer with GTK for me is that I use (try to
Jeremy> evangelize) Haskell at work for certain tasks. My employer has
Jeremy> an absolute ban on the use of LGPL licensed code in any
Jeremy> internal project. This is not negotiable (before anyone tells
Jeremy> me that LGPL does allow commercial development, I'll only say
Jeremy> that I know that this is the opinion of some in the legal
Jeremy> profession, and certainly of many (most) developers, but not of
Jeremy> the lawyers who advise my employer, and they are not going to
Jeremy> change their minds on this). Therefore, in practice, gtk2hs is
Jeremy> not an option for me anyway.

Although I plan to release my app as open-source, it may happen that
my 'superior' may want to have some plugin as close-source, and then
the above info will be very helpful. Thanks a lot.

Jeremy> I am not sure how much I have helped you to move forward. The
Jeremy> truth is that either library would let you do the job, neither
Jeremy> is quite as well supported as it really ought to be, and the
Jeremy> reasons for and against each are rather finely balanced.

Your post is providing excellent info and gives me much more
confidence in wxhaskell. I really appreciate it.

May I just ask, if it is relevant for you, do you use some GUI
designer tool?

I'm thinking about DialogBlocks (looks as better option for wxhaskell
considering one needs only XRC support) vs. free wxFormBuilder,
i.e. is DialogBlock justifies to be supported over free tool to be
used for wxhaskell?

Jeremy> I wish you luck in your decision, and will try to support you
Jeremy> if you choose wxHaskell

I was looking (and helped a bit with their site) for quite some time
at gtk2hs project (Duncan persuaded me) :-) ,but since my teacher
recently moved to Mac OS, I'v e started to think that wxhaskell may be
better option.

In any case, I'll still think a bit - by the end of the month we're
going to vacation during February, and then by the March we'll know
for certain...although, based on all the info you've provided about
wxhaskell, I do not see any advantage in using gtk2hs (except that
memory issue which I mentioned above).

If I decide to go with wxhaskell, I'll definitely try to help the
project with all the skills I have.


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

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

Hi Gour,

2010/1/19 Gour <go...@go...>

> Now, based on what I know so far wxhaskell may be better supported on
> Mac since GTK+ port is not finished. otoh, I'm a bit concerned about
> "Since the core interface is generated automatically from the wxEiffel
> binding..." and visiting the project show the status notice:
>
> "The 0.7 release will probably be the last official release.
>
> The project lost its core developer following the 0.7 release in late
> June 2003 and it is unlikely that anyone will be able to take on this
> vital role. "
>
So, my question is if this dependency on wxEiffel will change soon,
> especially considering the upcoming wx-3.0 release?
>
> I'm not sure where you found this quote. A (small) team of developers took
on maintenance of wxHaskell over three years ago, and we have been keeping
it up to date ever since.

While there are some vestiges of the Eiffel heritage in the wxHaskell source
code, there is no dependency on the wxEiffel binding. The dependency on
wxEiffel really disappeared before I became involved in the project.

The latest wxHaskell release supports wxWidgets 2.8.10 (which I believe is
the most recent stable version), and we will update to wxWidgets 3.0 shortly
after this becomes available.


> Another concern is question of memory management touched upon in the
> following article:
>
> http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/
>
>
> So, can someone share some thoughts about gtk2hs vs. wxhaskell with
> the reference to ease of use, learning curve etc. for a noob not being
> too familiar with none of the toolkits and considering suitability for
> multi-platform development in Haskell for (priority order) Linux, Mac
> and Windows?
>

I suspect in practice that the learning curves are pretty similar. I haven't
done enough gtk2hs programming to be certain, but the samples look really
pretty similar, and the programing style is a bit more imperative than many
Haskell programmers really like in both cases. This is somewhat unavoidable
given that the underlying toolkits are stateful object-oriented in design.

I originally became involved with wxHaskell after doing some GTK GUIs (in
Ocaml) for Windows at home, and being disappointed with the results (and
licensing issues - see below) - in fact, this is how I first came to look at
Haskell...

I understand that the GTK situation on Windows is much better now, and that
the GTK theme for Windows looks pretty close to native unless you look very
closely. Mac is another story. AFAIK, the native GTK for Mac is still
considered to be pretty unstable, and the default theme, while functional,
looks like... GTK on Linux.

wxWidgets (and wxHaskell) works very well on Mac - we have support for
creating application bundles, and UIs look completely native. The same is
true for Windows (I work about 90% on Windows with wxHaskell)

wxHaskell works fine on Linux, but since it depends on GTK to render
widgets, you'll have better performance and a smaller app footprint if you
just use gtk2hs, to be honest.

I guess the scorecard is therefore:

   - Ease of use - wxhaskell and gtk2hs about equal
   - Linux development - both work well, but gtk2hs scores slightly for
   performance and app footprint
   - Mac development - I definitely prefer wxHaskell. Native look is *vital*
   for acceptability on Mac
   - Windows development - both work well, but wxhaskell scores for
   performance and app footprint

 This means you will really need to weigh up the importance of portability.

You don't mention documentation. I think the truth here is that neither
gtk2hs nor wxHaskell is as well documented as it should be. There are
certainly bugs and strange behaviour in wxHaskell that are not really
documented well. I'm trying to change this (in particular, the lack of
'intermediate level' on wxHaskell information) in a new blog:
http://wewantarock.wordpress.com

I've noticed that wxhaskell is improving ease of install (I'm arch
> user) -
>
> http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/
>
> We have put a lot of effort into making wxHaskell installation 'just work'
on all platforms using Cabal recently. You can generally cabal install wx on
any platform with a working (recent) wxWidgets installation and it works
perfectly.


> and it may be that more devs are actively working on it atm.
>

The number is small for both, I suspect. Almost everyone interested in
maintaining this stuff has a day job and very little time to spare.


> Otoh, wx toolkit is often not very much likened (upon mentioning it),
> at least, on Linux platform where people recommend Qt and GTK+ (in
> general, I prefer GTK+ look over Qt which I do not consider as
> option). Why is it so?
>

I think you need to look at the toolkits in respect of their origins - to
some extent, language bindings exist slightly outside of these issues.

On Linux, Qt was the choice of the KDE devs and GTK was developed as a part
of the Gnome project. Back in the day (more than 10 years ago) there were
huge flamewars about licensing, freedom and the merits of C++ over C. The
end result is that, at least on Linux, Qt is seen as 'KDE-centric' and GTK
is seen as Gnome-centric. People often express an (unreasoned) preference
depending on their preferred desktop.

wxWidgets was never used by a major Linux desktop, and is sometimes decried
as 'portable MFC' - there is some truth in this, as the project essentially
started out as a portable and liberally licensed implementation of something
very like MFC. In addition, since it relies on GTK (on Linux) for its widget
drawing, there is no compelling reason to use it, at least for a desktop
environment (which, by its very nature tends to be OS-specific).

While I personally think that it was a strange choice to write GTK in C
rather than C++ (the underlying gobject library is, to some extent, an
implementation of a small subset of C++ object oriented facilities without
the compiler support), the fact is that being based on C means that it is
*much* easier to write a language binding for GTK than for wxWidgets or Qt
(both of which are written in C++) since every language has a C binding and
almost none have C++ bindings.

If I was writing a cross-platform app in C++, money no object, I would
probably choose Qt. Honestly, it's the best documented, best designed and
most complete of the toolkits. It does require an (expensive) developer
license for commercial applications, which limits the appeal.

For me, wxWidgets is a good alternative because it provides a 'native' UI
experience on all platforms, is pretty robust and complete, well documented
and liberally licensed (commercial applications explicitly permitted by the
license). The programming style is not as nice as Qt, but is, for me,
slightly preferable to GTK (my personal opinion is that the API design is
jut a little more consistent.

The final killer with GTK for me is that I use (try to evangelize) Haskell
at work for certain tasks. My employer has an absolute ban on the use of
LGPL licensed code in any internal project. This is not negotiable (before
anyone tells me that LGPL does allow commercial development, I'll only say
that I know that this is the opinion of some in the legal profession, and
certainly of many (most) developers, but not of the lawyers who advise my
employer, and they are not going to change their minds on this). Therefore,
in practice, gtk2hs is not an option for me anyway.

I am not sure how much I have helped you to move forward. The truth is that
either library would let you do the job, neither is quite as well supported
as it really ought to be, and the reasons for and against each are rather
finely balanced.

I wish you luck in your decision, and will try to support you if you choose
wxHaskell

Best regards
Jeremy