Re: [wxhaskell-users] Haskell Platform roadmap?

[Henning Thielemann]

On Thu, 16 Jun 2011, Heinrich Apfelmus wrote:

> I'm currently working on the FRP part [1]. It turns out that FRP is
> completely orthogonal to wxHaskell; there is no need to add special
> support for FRP in the GUI library. A handful of convenience wrappers
> [2] are enough to transform wxHaskell into a fully featured FRP-GUI
> library.

+1

> In other words, you can simply focus on the mid-level GUI
> bindings and get that into the platform.

May I advertise my enumset library that allows to handle flag sets as the 
ones in Graphics.UI.WXCore.WxcDefs in a safe and efficient way:
http://hackage.haskell.org/package/enumset


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Haskell Platform roadmap?

[Heinrich Apfelmus]

Jeremy O'Donoghue wrote:
> - Extend Graphics.UI.WX so that more of the core functionality has 
> high-level wrappers, e.g. for Grid, List boxes etc. I would love to
> see an FRP wrapper around parts of wxHaskell, and think we could 
> reinstate one or more of the FRP libraries, for example. Making GUI
> programming less like C programming would do a lot to promote Haskell
> GUI development, but it requires much better Haskell-fu than I have
> to offer.

I'm currently working on the FRP part [1]. It turns out that FRP is 
completely orthogonal to wxHaskell; there is no need to add special 
support for FRP in the GUI library. A handful of convenience wrappers 
[2] are enough to transform wxHaskell into a fully featured FRP-GUI 
library. In other words, you can simply focus on the mid-level GUI 
bindings and get that into the platform.


If anything, it would be very useful to fix the GHCi issue. Developing 
an FRP library is still a very experimental activity and having GHCi 
support makes prototyping a lot faster. (Conal Elliott would agree with 
that.)


   [1]: http://hackage.haskell.org/package/reactive-banana
   [2]: http://hackage.haskell.org/package/reactive-banana-wx

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] Haskell Platform roadmap?

[Jeremy O'Donoghue]

Hi all,

This is a call for help. There's been some discussion both on this list and
on the cafe about getting a GUI into Haskell Platform.

The formal requirement is that inclusion needs to be supported by at least
one library maintainer, and from a practical perspective it should be
something which builds and works well on all supported platforms, i.e.
Linux, Windows and Mac, and should have a team of maintainers who are able
to maintain the code over a long term basis.

While there have been some fantastic contributions to wxHaskell over the
past years from any people, the reality is that most of the work gets done
by me, and some may have noticed that I don't have a lot of time - certainly
nothing like enough to commit to inclusion in Haskell Platform.

The call for help is this: can we get together a team which would be able to
field enough effort to make a submission for Haskell Platform realistic? I
believe that such a team would look something like the following:


   - Project lead, release co-ordinator and mentor to others. That will be
   me then.
   - Target leads for Linux, Mac and Windows. Responsible for building tip
   code for their platforms and providing fixes when it breaks. In the case of
   Mac and Linux, extra points if you can make things work using the platform
   built-in wxWidgets.
   - A number of specific functional areas to be addressed:
  - Fix the long-standing bug preventing GHCi use of wxHaskell. In my
  opinion, this is best addressed by factoring the C wrapper for
wxHaskell (we
  call it wxC) into a separate library which is built as a dynamically
  loadable library. I know, in principle, how to do this for Windows and
  Linux, but would need help for Mac. Anyone who wants to help should know
  that this involves lots of revolting work with linkers, and is especially
  suitable for masochists. That's probably me as well.
  - Make it easier to wrap some of the optional wxWidgets libraries.
  This requires work on wxDirect. This is probably the easiest
area to work on
  as wxDirect is a self-contained executable, and is small and
fairly simple
  to understand.
  - Using the above, wrap some of the optional libraries. STC should be
  reinstated in wxHaskell now (it's part of the core in wxWidgets 2.9), but
  there are many others. OpenGL canvas, AUI and the media framework look
  particularly interesting.
  - Consider a pure Haskell replacement for wx-config, at least on
  Windows, but potentially on all targets. We currently bundle a 3rd party
  wx-config replacement for Windows, but it doesn't work very well on
  wxWidgets 2.9.
  - Extend Graphics.UI.WX so that more of the core functionality has
  high-level wrappers, e.g. for Grid, List boxes etc. I would love
to see an
  FRP wrapper around parts of wxHaskell, and think we could
reinstate one or
  more of the FRP libraries, for example. Making GUI programming
less like C
  programming would do a lot to promote Haskell GUI development, but it
  requires much better Haskell-fu than I have to offer.
   - Go back through the list of bugs and feature requests and fix as many
   as possible. This is an easy starting point for a new wxHaskell contributor.
   - Improve documentation. While wxHaskell is pretty good, it could
   definitely be improved. In particular, I think we should consider finding a
   way to generate better documentation for the wxC wrapper functions, which
   currently only include type information.

There's probably a lot more to do, and I welcome comments and suggestions. I
welcome offers of help even more, and estimate that getting into HP requires
a core team of 6-8 people who can commit to a few hours per week for at
least a year. This is a huge ask, but the outcome would be that wxHaskell
could become part of the Haskell Platform, and would likely be much more
widely used.

What do you think?

Best regards
Jeremy
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Haskell Platform

[Jeremy O'Donoghue]

[x-posting wxhaskell-devel]

On 12 June 2011 18:43, Guy  wrote:

> On 12/06/2011 20:07, Eric Y. Kow wrote:
> > On Sun, Jun 12, 2011 at 19:54:13 +0300, Guy wrote:
> >> I'm trying to get a GUI package included in the Haskell Platform. The
> >> platform's inclusion policy requires that (one
> >> of?) the package's official maintainers supports the proposal.
>

The sad reality (and I suspect it may apply equally to Gtk2HS) is that there
isn't a large enough core team maintaining wxHaskell to commit to Haskell
Platform. I am nowhere near being able to give the time needed to support
such an effort.

As a guess, it would require a fairly committed(*) core team of about 6
people, including at least one on each of the major platforms (Windows,
Linux, Mac).

(*) for the avoidance of doubt, "able to commit a few hours per week on a
reasonably long-term basis".


> > We may need to think strategically about this.
>

The main areas where we have problems are:

   - Robust support for GHCi, working on all platforms (currently works on
   none!)
   - Straightforward to install on all platforms (currently probably easiest
   on Windows, and not reliably functioning on 'built-in' versions of
   wxWidgets)
   - Documented mechanism/approach to wrapping new parts of wxWidgets APIs
   (this probably isn't a show-stopper for HP inclusion)

>
> > gtk2hs is much more popular than wxHaskell, and by and large coders
> > seem not to be particularly concerned about getting as close to native
> > UI as possible (and they'll just point out that you can't anyway).
>

True, but the reality is that whatever gets included in HP will become the
de-facto Haskell GUI, and will edge the alternatives out fairly quickly. I'd
love this to be wxHaskell, but I really don't have the bandwidth to make it
happen.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Haskell Platform

[Guy]

On 12/06/2011 20:07, Eric Y. Kow wrote:
> On Sun, Jun 12, 2011 at 19:54:13 +0300, Guy wrote:
>> I'm trying to get a GUI package included in the Haskell Platform. The
>> platform's inclusion policy requires that (one
>> of?) the package's official maintainers supports the proposal.
>
> We may need to think strategically about this.
>
> gtk2hs is much more popular than wxHaskell, and by and large coders
> seem not to be particularly concerned about getting as close to native
> UI as possible (and they'll just point out that you can't anyway).

I made the same post to the gtk2hs list. However, gtk2hs doesn't install on the 
current version of cabal, and 
development there seems to have stalled (the fix has been known for several 
months), so I'm not too positive on that front.


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Haskell Platform

[Eric Y. Kow]

On Sun, Jun 12, 2011 at 19:54:13 +0300, Guy wrote:
> I'm trying to get a GUI package included in the Haskell Platform. The
> platform's inclusion policy requires that (one 
> of?) the package's official maintainers supports the proposal.

We may need to think strategically about this.

gtk2hs is much more popular than wxHaskell, and by and large coders
seem not to be particularly concerned about getting as close to native
UI as possible (and they'll just point out that you can't anyway).

I wonder if to make this happen, we would perhaps need to wait for
wxHaskell to mature a little more, wait for the installation procedure
to be a bit nicer, maybe get some way for gtk2hs code to "just work"
on wx

-- 
Eric Kow 


pgposG8uINRLH.pgp
Description: PGP signature
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] Haskell Platform

[Guy]

I'm trying to get a GUI package included in the Haskell Platform. The 
platform's inclusion policy requires that (one 
of?) the package's official maintainers supports the proposal.

Are any WxHaskell maintainers interested?


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] haskell-platform-2010.1.0.0, MacPorts & wxHaskell works w/ work

[Eric Y. Kow]

Hi everyone,

Here's a user report with some good and bad news.  If somebody from
the wxHaskell Team could bless or comment on this, I might forward it
along to Haskell-Café.

I'm Bcc'ing Gregory Wright from the MacPorts team as I think he may
be interested.

First the good: with MacOS X 10.6 (but 32 bit), the new wxHaskell
packages by Daniel Fischer seem to work fine with GHC 6.12 and the
latest Haskell Platform.

And now the bad news: you have to work a little to get there if
you're using MacPorts.

Summary
===
1. No more MacPorts wxWidgets; build one yourself
2. Don't forget to --enable-unicode
3. Don't forget grab your wxWidgets and not the system one
4. Or maybe wait for haskell-platform-2010.x to arrive in MacPorts

1. no more macports wxwidgets
=
you may see this error message (see Conor McBride's suffering on
http://www.haskell.org/pipermail/haskell-cafe/2009-December/071117.html ).

Undefined symbols:
 "_iconv_close", referenced from:
 _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o)
 "_iconv", referenced from:
 _hs_iconv in libHSbase-4.2.0.0.a(iconv.o)
 "_iconv_open", referenced from:
 _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

As I vaguely understand the issue, the problem is that
 (a) new libHSbase gets built using iconv.h and the like from -I/usr/include,
 but
 (b) having *any* package that introduces a -L/opt/local/lib in there (eg. a
 MacPorts-friendly Haskeline) 
and that some sort of difference between the two versions of iconv make (a) and
(b) an unhappy combination.

Having your wxHaskell be linked against your MacPorts wxWidgets causes similar
trouble if you have MacPorts iconv as well.

I didn't want to think about this any harder, so I just took MacPorts out of
the equation altogether by building my own wxWidgets 2.8.10 from source
http://www.wxwidgets.org/downloads/#latest_stable (Hooray for stow)

2. Don't forget to --enable-unicode when configuring wxWidgets
==
After untarring the wxWidgets source, I did this, the main point being the
Unicode stuff; the stow related business being extra details to make life
easier:

  port install stow
  ./configure --prefix=/usr/local/stow/wxMac-2.8.10 --enable-unicode
  make && sudo make install
  cd /usr/local/stow
  sudo stow wxMac-2.8.10

If you forget to enable Unicode, everything will build fine, but you'll get
widgets with only one letter on them.

3. Don't forget to build wxHaskell against YOUR wxWidgets
=
I did this:

  PATH=/usr/local/bin:$PATH cabal install wx

If you do not temporarily re-order the path, the Setup.lhs file in wxcore
will pick up the system wxWidgets which does not have the wxThread symbols
wxHaskell wants (so says the wiki for OS X 10.4), and when you launch your
application you'll be greeted by lots of annoying dialogue boxes that you
have to chase away.  Other things may break.

  http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X

I wish there was some way we could just use the system wxWidgets with maybe
some sort of way of filling in the missing bits :-(

4. Maybe just wait for MacPorts haskell-platform to catch up

Perhaps that would be the path of least resistance.

-- 
Eric Kow 
PGP Key ID: 08AC04F9


pgpWsXpdLAq9y.pgp
Description: PGP signature
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users