Re: [wxhaskell-users] Haskell Platform roadmap?

2011-06-20 Thread 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?

2011-06-16 Thread 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?

2011-06-14 Thread 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