Re: Haskell-Cafe Digest, Vol 34, Issue 45

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Haskell-Cafe Digest, Vol 34, Issue 45

Jeremy O'Donoghue
Hi Jason.

My $0.02

On 27/06/06, [hidden email]
<[hidden email]> wrote:
> ---------- Forwarded message ----------
> From: "Jason Dagit" <[hidden email]>

> Requirements:
> Okay, so now that you know why I'm here, let me give you an idea of
> what my *ideal* GUI library would be for this project (roughly in
> order of importance):
> 1) Doesn't require the end user to install anything (no dependencies)
> 2) Looks and feels like windows
> 3) Robust (or mature)
> 4) A pleasure to program (boo @ swing)
> 5) ??
>
> I don't really know the landscape, but this is my (uneducated) idea of
> my options:
> A) wxWidgets
> B) gtk2hs
> C) win32 api
> D) write the gui in C or C++ and use the FFI to invoke it
> E) write the gui in scala or java and use FFI + JNI to invoke it
> F) ?? you tell me
>
> I think (although I have yet to verify) that (A) satisfies #1-4, but
> (B) doesn't satisfy #1.  Is this true?  I tried to install wxHaskell
> but it turned out to be a real pain.  I'm using visual haskell so that
> I have COM support (I need the version of H/Direct that ships with
> VisualHaskell and VisuallHaskell only ships with ghc 6.5) and that
> means I have to compile the less mainstream haskell libraries myself.
> I have yet to successfully install wxHaskell on my dev machine at
> work.

I've developed a couple of projects with wxHaskell, along with a
couple using the lablGtk2 library for Ocaml - in fact, the whole
clunkiness and lack of Windows and (especially) Mac native feel of GTK
on non-Linux platforms is a large part of what brought me to Haskell
:-)

My applications are mainly for internal use at my workplace, and come
with Windows installers (I use Inno setup with wxHaskell - never
managed to make it work with GTK2, so these applications were
delivered as zip files which just had to be unzipped in a certain
place).

To distribute wxHaskell applications you need only two DLLs and an
executable. All can be in the same directory. I think this covers 1)

Look and feel is Windows native. As an added bonus (for me, at least)
it also looks native on Mac and Linux. That's 2)

wxHaskell is fairly robust, but you need to be aware that it does not
have complete coverage of the wxWindows library. I have found layout
behaviour to be incomprehensible at times (although I found this to be
somewhat true of the native wxWindows sizers on which layout is
built). Some of the more exotic widgets (Scintilla, wxGrid) are either
not wrapped, or the wrapping is incomplete. I have not succeeded, in
the general case, in getting sash wiondows to work as I would like
them to (it's possible for some limiting cases, but that is not enough
for my needs)

My impression, sadly, is that little development now goes on on
wxHaskell. The last compiled binaries available from the website are
over a year old now and, as you've already discovered, it's really
quite difficult to get wxHaskell to compile on Windows. For what it's
worth, I gave up on 2.6.x and reverted to 2.4.2, which compiled
cleanly for me.

Because of the appearance that it's withering on the vine, I would be
reluctant to recommend wxHaskell. However, despite the gripes above, I
think it's a superb piece of work. I have managed to produce some very
high performance applications with it - users assumed that I had
written in hand-optimized C (FastPackedStrings also had a big hand in
the performance). If the project were better documented, I really
believe that there's a chance that the project would take off. As an
example, I easily have the knowledge of C/C++ needed to contribute,
and the Haskell is getting there, but the (lack of) documentation
makes it hard for the end user at times - let alone the wannabe
developer.

In short, I'm not sure about 3).

wxHaskell programming is something of a mix of Haskell idioms (layout,
in particular) and C style imperative programming (in IO monad). In
some respects the UI code looks quite similar to wxPython, but at
least you get Haskell goodness for everything else. This is a big
plus.

Back in the day when I was using the Ocaml GTK2 binding, the following
observations were true. I suspect they may be true of GTK2Hs (as they
are mainly observations on GTK2 on Windows per se), but I am not
certain.

Installation of GTK2 on Windows is nothing short of revolting. It's a
completely manual set of 'work out which DLL or library to download
from where and install it in a suitable directory. Building from
source is worse.

I never managed to work out a small, sane set of DLLs which could just
be packaged with the executable I was delivering. It may be possible,
but I didn't manage it. That's a fail on 1), I suspect.

Look and feel is adequate on Windows, for the most part. However, the
file dialog, in particular, caused my users (mainly engineers, so
pretty switched on, on the whole) no end of confusion, and was a major
driver to my dropping Ocaml for this type of work. That's a failure on
2), at least for me.

However, in its defence, GTK2 is stable and capable on Windows. I also
have the impression that GTK2Hs is much more actively developed than
wxHaskell, and this may be a good reason to choose it if what you are
producing is a prototype which will not have wide distribution. I
think you'd have to give GTK2Hs a good rating for 3).

I can't really comment on your other potential solutions.

Regards
Jeremy
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell-Cafe Digest, Vol 34, Issue 45

Jason Dagit
On 6/27/06, Jeremy O'Donoghue <[hidden email]> wrote:

> Hi Jason.
>
> My $0.02
>
> On 27/06/06, [hidden email]
> <[hidden email]> wrote:
> > ---------- Forwarded message ----------
> > From: "Jason Dagit" <[hidden email]>
>
> > Requirements:
> > Okay, so now that you know why I'm here, let me give you an idea of
> > what my *ideal* GUI library would be for this project (roughly in
> > order of importance):
> > 1) Doesn't require the end user to install anything (no dependencies)
> > 2) Looks and feels like windows
> > 3) Robust (or mature)
> > 4) A pleasure to program (boo @ swing)
> > 5) ??
> >
> > I don't really know the landscape, but this is my (uneducated) idea of
> > my options:
> > A) wxWidgets
> > B) gtk2hs
> > C) win32 api
> > D) write the gui in C or C++ and use the FFI to invoke it
> > E) write the gui in scala or java and use FFI + JNI to invoke it
> > F) ?? you tell me
> >
> > I think (although I have yet to verify) that (A) satisfies #1-4, but
> > (B) doesn't satisfy #1.  Is this true?  I tried to install wxHaskell
> > but it turned out to be a real pain.  I'm using visual haskell so that
> > I have COM support (I need the version of H/Direct that ships with
> > VisualHaskell and VisuallHaskell only ships with ghc 6.5) and that
> > means I have to compile the less mainstream haskell libraries myself.
> > I have yet to successfully install wxHaskell on my dev machine at
> > work.
>
> I've developed a couple of projects with wxHaskell, along with a
> couple using the lablGtk2 library for Ocaml - in fact, the whole
> clunkiness and lack of Windows and (especially) Mac native feel of GTK
> on non-Linux platforms is a large part of what brought me to Haskell
> :-)
>
> My applications are mainly for internal use at my workplace, and come
> with Windows installers (I use Inno setup with wxHaskell - never
> managed to make it work with GTK2, so these applications were
> delivered as zip files which just had to be unzipped in a certain
> place).

Do you have any advice about using Inno with haskell?  Have you tried
wix at all?
http://sourceforge.net/projects/wix/

Maybe you have a developer blog I could read?

> To distribute wxHaskell applications you need only two DLLs and an
> executable. All can be in the same directory. I think this covers 1)

Yes, I would say that's almost ideal. (Ideally the user wouldn't even
have to install my progam it would 'just work' ;)

> Look and feel is Windows native. As an added bonus (for me, at least)
> it also looks native on Mac and Linux. That's 2)

Yes, I've used wxPython in the past very successfully.  It's fast,
easy to use, tends to look right. (in my narrow opinion)

> wxHaskell is fairly robust, but you need to be aware that it does not
> have complete coverage of the wxWindows library. I have found layout
> behaviour to be incomprehensible at times (although I found this to be
> somewhat true of the native wxWindows sizers on which layout is
> built). Some of the more exotic widgets (Scintilla, wxGrid) are either
> not wrapped, or the wrapping is incomplete. I have not succeeded, in
> the general case, in getting sash wiondows to work as I would like
> them to (it's possible for some limiting cases, but that is not enough
> for my needs)

Hmm...Yes I've fought extensively with the layout managers for Java
that come with the Net Beans IDE.  I think using a layout manager is a
great idea, but then I'll spend several hours  fighting with getting
just one screen to layout correctly and never want to use layout
managers again.  Perhaps I'm just dense, but the Matisse gui builder
in Net Beans is really frustrating for me.

> My impression, sadly, is that little development now goes on on
> wxHaskell. The last compiled binaries available from the website are
> over a year old now and, as you've already discovered, it's really
> quite difficult to get wxHaskell to compile on Windows. For what it's
> worth, I gave up on 2.6.x and reverted to 2.4.2, which compiled
> cleanly for me.

I took a hint here and downloaded 2.4.2, followed the instructions to
the letter and got things almost working.  It seems that I had spaces
in my paths.  VisualHaskell installed to:
C:\Program Files\Visual Haskell
When I came to the step of compiling wxHaskell I needed to run
configure with these options:
./configure --libdir=C:/Progra~1/Visual~1

The two important things here are: 1) You must use the forward slash
and 2) you cannot use spaces.

After it installed I started getting panics from 'ghc -package wx':
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-October/005632.html
And I found a solution here:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-October/005639.html

Next I found that I needed to add C:\Program Files\Visual Haskell to
my path so that the wxHaskell dlls could be located by windows.

Now I'm at the point where I can compile and run wxHaskell programs (yay!).


>
> Because of the appearance that it's withering on the vine, I would be
> reluctant to recommend wxHaskell. However, despite the gripes above, I
> think it's a superb piece of work. I have managed to produce some very
> high performance applications with it - users assumed that I had
> written in hand-optimized C (FastPackedStrings also had a big hand in
> the performance). If the project were better documented, I really
> believe that there's a chance that the project would take off. As an
> example, I easily have the knowledge of C/C++ needed to contribute,
> and the Haskell is getting there, but the (lack of) documentation
> makes it hard for the end user at times - let alone the wannabe
> developer.

When I used wxPython I was often referencing the C++ docs and I didn't
mind as I'm reasonably fluent in C++.  So (hopefully) this will not
slow me down when using wxHaskell.

> wxHaskell programming is something of a mix of Haskell idioms (layout,
> in particular) and C style imperative programming (in IO monad). In
> some respects the UI code looks quite similar to wxPython, but at
> least you get Haskell goodness for everything else. This is a big
> plus.

This is something I'm looking forward to.  A little bit of
not-as-pretty Haskell with lots of typical Haskell to support it.  I
think it will make my project fun to work on as well as giving me
certain bonuses in the software engineering department (go referential
transparency!).

[snipped testimonials about gtk2hs]
Thanks for the info about gtk2hs.  I feel like GTK is great and I
would gladly use it on an open source project but I think given my
target audience and my requirements it's not right for this project.

>
> I can't really comment on your other potential solutions.

Hopefully I won't need them now :)

Thanks, this was very helpful,
Jason
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell-Cafe Digest, Vol 34, Issue 45

Jeremy O'Donoghue
In reply to this post by Jeremy O'Donoghue
Hi Jason,

Just as a short follow-up on the question of installers:

On 27/06/06, Jason Dagit <[hidden email]> wrote:

> On 6/27/06, Jeremy O'Donoghue <[hidden email]> wrote:
> >
> > My applications are mainly for internal use at my workplace, and come
> > with Windows installers (I use Inno setup with wxHaskell - never
> > managed to make it work with GTK2, so these applications were
> > delivered as zip files which just had to be unzipped in a certain
> > place).
>
> Do you have any advice about using Inno with haskell?  Have you tried
> wix at all?
> http://sourceforge.net/projects/wix/

I haven't looked at Wix. Inno is particularly straightforward as it
has a 'wizard' interface (the script wizard). The basic steps (for
wxHaskell) are:

On screen 1: add application name, version, publisher and website (if
applicable)

On screen 2: add application install base directory and directory
name. Decide if user can change these or not.

On screen 3: add main application executable. Add any other
files/directories used (In my case, I typically have only the main
.exe file, wxmsw24.dll, wxc-msw2.4.2-0.9.4.dll and, possibly, a
bitmaps directory and/or help files).

On screen 4: Decide where in the start menu you will put the application.

On screen 5: Any application documentation: license, pre-install
readme, post-install readme.

On screen 6: Define any language support details.

On screen 7: Define setup compiler output directory, output filename,
any icon to be used and (optionally) a password.

That's it. The wizard generally produces all I need for a simple installer.

> Maybe you have a developer blog I could read?

I don't. I fear that I would start full of good intentions, write a
few posts and then find that I had no time... I'll try to share what I
know via the wiki as Simon suggested (will be putting this installer
stuff, suitably edited, in the wiki shortly).

Regards
Jeremy
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe