From: Eric Y. K. <eri...@gm...> - 2008-03-24 16:03:01
|
So, now that 0.10.3 is out, what is the fastest way for us to get wxWidgets 2.8 support so that MacOS X Leopard users can run it? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
From: Eric Y. K. <eri...@gm...> - 2008-04-23 19:37:16
|
Just a little heads up: I've pushed in set of patches from Jeremy O'Donoghue which should make it possible to use wxhaskell with wxWidgets 2.8. For MacOS X Leopard users, yes, this means that you can run the darcs version wxhaskell (it runs fine on my machine). Unfortunately, this means breaking support for prior versions of wxWidgets. We are working out what to do about this... -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
From: Mads L. <mad...@ya...> - 2008-04-24 21:37:29
|
Hi I have compiled & installed this on Debian Linux. And it worked with only a little trouble. I had to install WxHaskell 2.8 from http://wiki.wxpython.org/InstallingOnUbuntuOrDebian . That is, I installed a package not in the main Debian achieve, which some Debian users may not be so happy about. But hopefully Debian has WxHaskell 2.8 when we are ready to release the next version of WxHaskell. However, I had to turn profiling off or installation of wx gave me: .... [ 6 of 16] Compiling Graphics.UI.WX.Events ( src/Graphics/UI/WX/Events.hs, dist/build/Graphics/UI/WX/Events.p_o ) [ 7 of 16] Compiling Graphics.UI.WX.Window ( src/Graphics/UI/WX/Window.hs, dist/build/Graphics/UI/WX/Window.p_o ) src/Graphics/UI/WX/Window.hs:165:26: Not in scope: `windowGetEffectiveMinSize' Installing: /home/ghctest/lib/wx-0.10.3/ghc-6.8.2 Setup: Error: Could not find module: Graphics.UI.WX.Draw with any suffix: ["p_hi"] and finally compiling the samples programs using "make all" gave linker problems. But compiling manually using "ghc --make ..." solved the issue. I will investigate the two issues further tomorrow, when I am not tired. /Mads > Just a little heads up: I've pushed in set of patches from Jeremy > O'Donoghue which should make it possible to use wxhaskell with > wxWidgets 2.8. > > For MacOS X Leopard users, yes, this means that you can run the darcs > version wxhaskell (it runs fine on my machine). > > Unfortunately, this means breaking support for prior versions of > wxWidgets. We are working out what to do about this... > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ wxhaskell-devel mailing list wxh...@li... https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel |
From: Jeremy O'D. <je...@o-...> - 2008-03-25 11:53:55
|
On Mon, 24 Mar 2008 16:02:43 +0000, "Eric Y. Kow" <eri...@gm...> said: > So, now that 0.10.3 is out, what is the fastest way for us to get > wxWidgets 2.8 support so that MacOS X Leopard users can run it? I need to port my wxWidgets 2.8 changes on top of 0.10.3. I started this last week, and it won't take too long. There are a few caveats, however, and (at least as I've implemented) these break compatibility. Note that it seems like the 2.4 compatibility mode which we have been using with wxWidgets 2.6 seems to be broken (not unreasonably) in a few places in 2.8 (it's officially unsupported now). What I have is based on 'raw' wxWidgets 2.8 (I couldn't make 2.4 compatibility work, and it's cleaner to just work to the latest base). Bottom line is that the update will not compile against wxWidgets 2.4 or 2.6. Don't think the loss of 2.6 compatibility is too much of an issue. Loss of 2.4 compatibility means that we no longer play nicely with GHCi, however. I have some ideas on how to fix this, but it's far from trivial (do 'true' dynamic loading and unloading of wxWidgets DLL/.so/.dylib, which will be very platform specific, but will ensure that C++ static constructors and destructors work correctly, and can be called programmatically). Main (possibly compatibility breaking) differences from 0.10.3: * In WX o Instances of 'framed' (currently in WX.Frame) move to TopLevelWindow o Changed behaviour of bestSize attribute (in WX.Window) - this is very minor, I think, and probably doesn't break existing code. * In WXCore o topLevelWindowSetIconFromFile replaces frameSetIconFromFile * In wxc o wxGenericDragImage methods now require a wxPoint o static wxBrush instances have changed to const type o static wxColour instances have changed to const type o static wxCursor instances have changed to const type o static wxFont instances have changed to const type o static wxPen instances have changed to const type o wxTreeItemId_CreateFromValue() should be deprecated The good news is that it looks as though much of what is needed in wxc has been implemented (although I'll have to merge my changes as they are, in some cases, different to what I had done (in unimportant ways). In general, I'll keep what is already there if it works. I can try to get this merge done in a week or so, if that's OK. I'll have time to verify on one platform only (probably Windows), but better to get the changes in. I think we need to have a general discussion on whether it's acceptable to break wxWidgets 2.4 compatibility. I think it is, and that we should just direct those needing this feature to the 0.10.3 release. Regards Jeremy |
From: Eric K. <eri...@gm...> - 2008-03-25 12:00:22
|
> I think we need to have a general discussion on whether it's acceptable > to break wxWidgets 2.4 compatibility. I think it is, and that we should > just direct those needing this feature to the 0.10.3 release. I think Conal might be a bit unhappy about ghci not working (if I understand correctly, Windows users can only really use ghci with wxWidgets 2.4?), but I don't see how we have a choice otherwise. Let's go ahead and break it, I'd say. We've got to keep moving forward because trying to distribute wxWidgets on our own would probably be more trouble than it's worth. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
From: Mads L. <mad...@ya...> - 2008-03-25 16:37:59
|
Hi, Jeremy O'Donoghue wrote: > Bottom line is that the update will not compile against wxWidgets 2.4 or > 2.6. Don't think the loss of 2.6 compatibility is too much of an issue. > Loss of 2.4 compatibility means that we no longer play nicely with GHCi, > however. Debian (and thus properly Ubuntu) stable version supports 2.6 but not 2.8. I could not find 2.8 support for testing/unstable in the main Debian archive either. Therefore I do think that ditching 2.6 is big issue. Granted there are third party packages for Debian (http://www.wxwidgets.org/downloads/), but a lot of people likes to keep third party packages to a minimum - including myself. Greetings, Mads Lindstrøm |
From: shelarcy <she...@gm...> - 2008-03-25 17:27:08
|
Hi, On Tue, 25 Mar 2008 20:53:51 +0900, Jeremy O'Donoghue <je...@o-...> wrote: > Bottom line is that the update will not compile against wxWidgets 2.4 or > 2.6. Don't think the loss of 2.6 compatibility is too much of an issue. > Loss of 2.4 compatibility means that we no longer play nicely with GHCi, > however. > > (snip) > > I think we need to have a general discussion on whether it's acceptable > to break wxWidgets 2.4 compatibility. I think it is, and that we should > just direct those needing this feature to the 0.10.3 release. I want to see your patch before discussion about this problem. Because we don't know that we can solve this problem or not, without your code. > I can try to get this merge done in a week or so, if that's OK. I'll > have time to verify on one platform only (probably Windows), but better > to get the changes in. So, please do it and send us your changes, first. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |