From: Jeremy O'D. <jer...@gm...> - 2011-06-14 22:36:47
|
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 |
From: Eric K. <eri...@gm...> - 2011-06-15 12:33:22
|
On Tue, Jun 14, 2011 at 23:36:37 +0100, Jeremy O'Donoghue wrote: > - 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. So it sounds like what could be handy is to partially automate our way out of this with something like buildbot. We would need somebody to manage the master, and also volunteers to provide always-on Mac, Linux and Windows machines to do the builds for us. You can get an idea of what buildbot would buy us at http://buildbot.darcs.net/waterfall I'm a big fan of replacing scarce humans with robots wherever possible. ... but we do need somebody to help with said robots! -- Eric Kow <http://erickow.com> |
From: <mac...@gm...> - 2011-08-07 20:41:03
|
I set up a BuildBot instance for wxHaskell darcs tip: http://build.bimbr.com/wxhaskell/waterfall. At the moment it is configured to run nightly, at 1 AM CET (numerous builds at other times are a result of me testing the setup). The only slave I configured so far is Windows with wxWidgets 2.8, but if anyone would like to contribute a differently configured slave to build on, that would be most welcome. Please let me know if you have a machine that is regularly online at this time or if you are willing to configure an EC2 AMI (I can host it). As you can see, the Windows build currently fails due to unsupported wx-config --version flag, which has been discussed on wxhaskell-devel before. A reasonable next step seems to be to to actually fix the Windows build, which I hope to have a stab at next weekend. Also, this is the first time I had anything to do with BuildBot, so any suggestions on how to improve the setup are welcome. Maciek On Wed, Jun 15, 2011 at 1:12 PM, Eric Kow <eri...@gm...> wrote: > On Tue, Jun 14, 2011 at 23:36:37 +0100, Jeremy O'Donoghue wrote: >> - 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. > > So it sounds like what could be handy is to partially automate our way > out of this with something like buildbot. We would need somebody to > manage the master, and also volunteers to provide always-on Mac, Linux > and Windows machines to do the builds for us. > > You can get an idea of what buildbot would buy us at > http://buildbot.darcs.net/waterfall > > I'm a big fan of replacing scarce humans with robots wherever possible. > ... but we do need somebody to help with said robots! > > -- > Eric Kow <http://erickow.com> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk34oZUACgkQBUrOwgisBPnl+wCeN4gLoWD9hlokzS/xugr7WpNS > exAAoL3bzR5V7qBqjDt20u051oMC1bST > =8jSq > -----END 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 > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > > |
From: Heinrich A. <apf...@qu...> - 2011-06-16 12:50:19
|
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 |
From: Henning T. <le...@he...> - 2011-06-20 19:33:52
|
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 |