From: Joel S. <jo...@me...> - 2011-05-25 20:05:39
|
What would it take to get full support for OpenGL in wxHaskell? My understanding is that wxWidgets supports it, we just need the Haskell binding for it, right? And I think it used to be there in a previous version of wxHaskell. |
From: Jeremy O'D. <jer...@gm...> - 2011-05-26 10:29:05
|
Hi Joel, On 25 May 2011 21:04, Joel Shellman <jo...@me...> wrote: > What would it take to get full support for OpenGL in wxHaskell? My > understanding is that wxWidgets supports it, we just need the Haskell > binding for it, right? And I think it used to be there in a previous > version of wxHaskell. > Putting support for OpenGL canvas into wxHaskell is very straightforward. I could do the code in about an hour. The problem is to make wxHaskell compile and link successfully on all supported platforms with as little user intervention as possible (basically, I want anyone with wxWidgets to be able to 'cabal install wx' and everything will work). The first problem is that wxWidgets may or may not be built with OpenGL support on any given platform, and wxDirect, which does much of the code generation, doesn't support conditional compilation. *Question for the general user community of wxHaskell - is the addition of an OpenGL target dependency OK with you?* (apologies for shouting, but I don't want this to be missed by speed readers!) The impact is mostly to Windows users, since Windows wxWidgets builds don't support OpenGL by default (it's only a case of adding wxUSE_GLCANVAS in setup.h and adding USE_OPENGL=1 on the build command line), but there may be Linux distros which don't build their wx packages with OpenGL - I don't know). The second problem is that wxWidgets only gives you a canvas, so we would need to make sure that wxHaskell plays nicely with a Haskell OpenGL binding. I don't have time to do this. Joel, I have a proposal for you: if I put support for wxGLCanvas and wxGLContext into a branch in the wxHaskell repo (when it gets restored), I need evidence that it is usable on all of the supported wxHaskell targets (i.e. Linux/Gtk, Windows, Mac) - that means working out the dependencies, how to build and ensuring that there is a working sample application. Are you able to co-ordinate this activity? If you (or anyone else) can do this, my side of the bargain is that I'll mainline OpenGL support in wxHaskell and ensure that all of the documentation is updated to reflect whatever is needed, blog on how to use it and generally make sure that there is information out there on which everyone can rely. Regards Jeremy |
From: Henk-Jan v. T. <hj...@ch...> - 2011-05-26 22:44:56
|
On Thu, 26 May 2011 12:28:58 +0200, Jeremy O'Donoghue <jer...@gm...> wrote: > *Question for the general user community of wxHaskell - is the addition > of > an OpenGL target dependency OK with you?* I hope OpenGL is re-introduced in wxHaskell; I am currently not using OpenGL, I but I will need it in the future. I am on Windows. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- |
From: Eric K. <eri...@gm...> - 2011-05-26 10:58:19
|
Hi, On Thu, May 26, 2011 at 11:28:58 +0100, Jeremy O'Donoghue wrote: > *Question for the general user community of wxHaskell - is the addition of > an OpenGL target dependency OK with you?* (apologies for shouting, but I > don't want this to be missed by speed readers!) What are the implications (all three platforms)? My general priority is just-workingness. Right now, installing wxHaskell on Mac is still a bit of pain. I think we've got it boiled down to 1. install homebrew 2. brew install haskell-platform 3. brew install wxmac 4. [when next release is out] cabal install wx And I would be nervous about anything that deviates significantly from that > Joel, I have a proposal for you: if I put support for wxGLCanvas and > wxGLContext into a branch in the wxHaskell repo (when it gets restored) It might be a good idea to adopt the strike-whilst-iron-hot and reduce-friction mentality here. In other words, rather than waiting indefinitely for our good but overloaded cho admins to get to it, just stick the branch up at darcsden in the interim so that people who are already keen to get hacking can get hacking (before they lose interest and wander off) :-) Not sure if this sort of mentality is right; it does add a bit of mess! But I suspect that these sorts of trivial delays can be costly. Thanks for keeping this alive! We can do it! Rah! :-) -- Eric Kow <http://erickow.com> |
From: Jeremy O'D. <jer...@gm...> - 2011-05-26 11:53:05
|
On 26 May 2011 11:38, Eric Kow <eri...@gm...> wrote: > What are the implications (all three platforms)? > > My general priority is just-workingness. Right now, installing > wxHaskell on Mac is still a bit of pain. I think we've got it boiled > down to > > 1. install homebrew > 2. brew install haskell-platform > 3. brew install wxmac > 4. [when next release is out] cabal install wx > > And I would be nervous about anything that deviates significantly > from that > I know the build implications for Windows (wxUSE_GLCANVAS in setup.h and USE_OPENGL=1 when compiling). A quick read up on the subject implied that HOPENGL recommends using a different (Open Source) GLUT wrapper on Windows, but I don't know what that means in practice. Don't know for Mac (ISTR Mac has about the best OpenGL story of all common platforms) I fear that Linux will be distro-dependent, which is the worst of all possible worlds! That's why I need someone to convince me that it doesn't make the install process too complicated. > It might be a good idea to adopt the strike-whilst-iron-hot and > reduce-friction mentality here. In other words, rather than waiting > indefinitely for our good but overloaded cho admins to get to it, > just stick the branch up at darcsden in the interim so that people > who are already keen to get hacking can get hacking (before they > lose interest and wander off) :-) > I'm thinking seriously of hosting wxHaskell at darcsden anyway, since branch/fork support is a very nice thing to have. Currently sorting out event handling so that it works for both wxWidgets 2.9.x and 2.8.x. We support too many events which no longer exist and not enough of those which have been added since 2.4.x :-( Will post an updated repo once I have this working, followed by a fork which supports GLCanvas Jeremy |
From: Henning T. <sch...@he...> - 2011-05-26 11:29:13
|
Jeremy O'Donoghue schrieb: > On 25 May 2011 21:04, Joel Shellman <jo...@me... > <mailto:jo...@me...>> wrote: > > What would it take to get full support for OpenGL in wxHaskell? My > understanding is that wxWidgets supports it, we just need the Haskell > binding for it, right? And I think it used to be there in a previous > version of wxHaskell. > > > Putting support for OpenGL canvas into wxHaskell is very > straightforward. I could do the code in about an hour. Would it be possible to implement this in a separate package? wx-opengl or so? I didn't need OpenGL support so far. |
From: Jeremy O'D. <jer...@gm...> - 2011-05-26 11:57:44
|
On 26 May 2011 12:31, Henning Thielemann <sch...@he...>wrote: > Jeremy O'Donoghue schrieb: > > > On 25 May 2011 21:04, Joel Shellman <jo...@me... > > <mailto:jo...@me...>> wrote: > > > > What would it take to get full support for OpenGL in wxHaskell? My > > understanding is that wxWidgets supports it, we just need the Haskell > > binding for it, right? And I think it used to be there in a previous > > version of wxHaskell. > > > > > > Putting support for OpenGL canvas into wxHaskell is very > > straightforward. I could do the code in about an hour. > > Would it be possible to implement this in a separate package? wx-opengl > or so? I didn't need OpenGL support so far. > This would need major changes to wxdirect, as it currently isn't really set up to wrap individual packages. A good thing to do, but I fear I may not have time to do it in the near future. We'll develop OpenGL support in a branch for now, while I get consensus from the community on the best way to do the packaging. Jeremy |