Re: [wxhaskell-users] Problems getting wxcore installed
I'll try compiling Windows from Hackage this weekend. Best regards Jeremy Sent from my Windows Phone From: Henk-Jan van Tuyl Sent: 06/07/2012 10:16 To: wxhaskell-users@lists.sourceforge.net Subject: [wxhaskell-users] Problems getting wxcore installed L.S., Did anyone get wxHaskell compiled on Windows? I am having several problems getting it compiled; - The wxcore setup calls wxdirect without quotes around the filepaths, these filepaths contain spaces and therefore wxdirect uses only the first part of the filepath. I patched wxcore to solve this. - The header files are not parsed correctly, I get, amongst others, the following messages (still trying to install wxcore): parsing: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/stc.h parsing: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/stc_gen.h ignore: parse error : C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/wxc.h (line 1, column 1): unexpected '/' expecting function declaration or end of input, on : //int expEVT_DIALUP_CONNECTED(); ignore: parse error : C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/wxc.h (line 1, column 1): unexpected '/' expecting function declaration or end of input, on : //int expEVT_DIALUP_DISCONNECTED(); generating: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1/WxcClassesAL.hs The parser seems unable to handle lines that are commented out with two slashes. Note, that these lines are not in wxc.h and do not have line number 1, in file stc_gen.h, line numbers 78 and 79. - I have deleted the contents of these lines and tried again to install wxcore; the message now generated is: src\haskell\Graphics\UI\WXCore\WxcClassTypes.hs:1:1: File name does not match module name: Saw: `Main' Expected: `Graphics.UI.WXCore.WxcClassTypes' The text is a bit cryptic, as file WxcClassTypes.hs is empty. Does anybody know how to solve this? Some version info: Windows XP Haskell Platform 2012.2.0.0 wxdirect-0.90.0.1 wxcore-0.90.0.3 wxc-0.90.0.4 wxWidgets-2.9.3 Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Can't link my app with wxHaskell-0.90.0.1 on Lion
Hi Hiratara, On 22 May 2012 04:22, Honma Masahiro hira.t...@gmail.com wrote: I'm a Japanese programer and apologize for my poor broken English :( Much better than my non-existant Japanese :-) I want to compile a sample program which uses wxHaskell on Mac OS X Lion, but I couldn't build it. I compiled HelloWorld.hs and I got following linker errors. % ghc -package wx -o helloworld HelloWorld.hs Linking helloworld ... ld: warning: ignoring file /System/Library/Frameworks//QuickTime.framework/QuickTime, file was built for unsupported file format which is not the architecture being linked (x86_64) ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame This is a link issue with multimedia on Lion. It seems that Quicktime is a 32 bit library only. You can ignore this. Undefined symbols for architecture x86_64: _wxListItemAttr_CreateEx, referenced from: _sUn6_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _sUng_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_Create, referenced from: _wxcorezm0zi90zi0zi1_GraphicsziUIziWXCoreziWxcClassesAL_listItemAttrCreate1_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrlVirtual_CreateWithCb, referenced from: _sW0i_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _sW0E_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrlVirtual_Create, referenced from: _sWbY_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _sWcg_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_SetTextColour, referenced from: _s15xV_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_SetFont, referenced from: _s15BK_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s15BO_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_SetBackgroundColour, referenced from: _s15Gu_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_HasTextColour, referenced from: _s1BbT_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2Jq5_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_HasFont, referenced from: _s1Bdd_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2JnT_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_HasBackgroundColour, referenced from: _s1Bex_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2JlH_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_GetTextColor, referenced from: _s1BfQ_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2JjR_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_GetFont, referenced from: _s1Bh9_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2Ji1_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListItemAttr_GetBackgroundColor, referenced from: _s1Bis_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2Jgb_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrlVirtual_SetOnGetItemTextCallback, referenced from: _s1BB6_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2IKc_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrlVirtual_SetOnGetItemImageCallback, referenced from: _s1BCC_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2IIo_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrlVirtual_SetOnGetItemColumnImageCallback, referenced from: _s1BE8_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2IGA_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrlVirtual_SetOnGetItemAttrCallback, referenced from: _s1BFE_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2IEM_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrl_RefreshItem, referenced from: _s1C5g_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2HVB_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrl_IsVirtual, referenced from: _s1C6N_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2HTp_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _wxListCtrl_GetItemFont, referenced from: _s1Cz0_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) _s2H2z_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status I need to check, but this looks as though you have a version of wxc which is incompatible with the wxcore you have. This is almost probably my fault (incorrect dependencies), and nothing to do with you - the install steps you have taken look correct to me. I will check whether I see the same problem on a clean install of wxHaskell, and upload a new version if needed. What should I do to fix these errors? I built ghc and wxWidgets by following steps; % brew install haskell-platform (version: 2011.4.0.0) % cabal update % cabal install llvm (version: 3.0.1.0) % brew install wxmac --use-llvm --devel (version: 2.9.3.1) % cabal install wx cabal-macosx (version: 0.90.0.1 and 0.2.2) %
Re: [wxhaskell-users] virtual list control
Hi Fabian, On 12 May 2012 16:12, Fabian Binz fabianb...@yahoo.de wrote: Hi Jeremy, I don't know if you continued working on this, but I forked wxHaskell on GitHub and tried to implement it myself: https://github.com/FabianBinz/wxHaskell I have been doing some work, but I don't have a lot of time right now, so it is going more slowly than I would like. For testing purposes, I only implemented the OnGetItemText and SetItemCount method and it seems to work. To implement the virtual list control, I defined a new class wxVirtualListCtrl in wxc: https://github.com/FabianBinz/wxHaskell/blob/master/wxc/src/include/virtuallistctrl_impl.h Since it needs to invoke a callback function, I created the typedef OnGetItemTextCallback. To make wxdirect accept this new type, I extended the parser (patomtype) in ParseC.hs. This solution is very ad-hoc and I think because wxc is supposed to be a language agnostic C wrapper, we should maybe add another macro to wcx_types.hs (something like TCallback), which is then recognized by wxdirect. So, while this all works pretty well, there is unfortunately a memory leak in Graphics.UI.WXCore.VirtualListCtrl, because of my use of newCString. At the moment I don't know how to fix it and would be glad if someone could give me some advice. You need to use a finalizer - this is what I am looking into. There is an overview at http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Calling_Haskell_from_C, but it could be clearer! Basic idea is that you free the CString when the GC has no more references to the closure in which it is used. I am using the event handler code as a model, since this already allows callbacks from C to Haskell, and handles reference counting. Just haven't finished yet. I will take a look at your fork and see if you are further along than me, and take code accordingly. Best regards Jeremy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxHaskell 0.90 on Windows 7?
Thanks Antton. I will update the wiki build instructions. Jeremy On 24 April 2012 13:08, Antton Tapani antton.tap...@gmail.com wrote: Hey, I got the same error at first too. Running set LANG=C in cmd before compiling fixed it for me. This is probably not common/default behavior since no one has considred it important to mention it in the guides. Only info I was able to find on this was from a japanese blog using google translate. On Tue, Apr 24, 2012 at 2:32 PM, carlos gomez carliro...@gmail.com wrote: Hello, I'm trying to build wxhaskell on windows 7 and HP.2011.4.0.0, but I've got this error when installing wxdirect: C:\cabal install wxdirect Resolving dependencies... Configuring strict-0.3.2... Preprocessing library strict-0.3.2... Building strict-0.3.2... interno:0:5: lexical error (UTF-8 decoding error) cabal: Error: some packages failed to install: strict-0.3.2 failed during the building phase. The exception was: ExitFailure 1 wxdirect-0.90.0.1 depends on strict-0.3.2 which failed to install. Any ideas of what to do? thanks, Carlos Gomez On 22 April 2012 09:48, Eric Kow eric@gmail.com wrote: Hi, After struggling a bit to get wxHaskell 0.90 working on a Windows VM, I thought a few links and tips could be useful http://www.haskell.org/haskellwiki/WxHaskell/Windows -- Eric Kow http://erickow.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Using wxHaskell on Mac OS x
On 24 April 2012 12:52, Eric Kow eric@gmail.com wrote: /me roots for Nix Which currently doesn't build :-( See https://github.com/jodonoghue/wxHaskell/issues/4 - I'm working on it, but will not be able to test the solution as life is too short to create Yet Another Test Environment - I already test on the following (the top 3 get the most love): - Mac OS X Lion (64bit GHC / 64 bit wxWidgets 2.9.3 / wxHaskell 0.90) - Windows 7 Enterprise (64bit OS / 32 bit GHC / 32 bit wxWidgets 2.9.3 / wxHaskell 0.90) in a VM - Debian 6 (32 bit OS / 32 bit GHC / 32 bit wxWidgets 2.9.3 / wxHaskell 0.90) in a VM - FreeBSD (32 bit OS / 32 bit GHC / 32 bit wxWidgets 2.8.12 / wxHaskell 0.13) in a VM That's enough for anyone with other things to do, I'm afraid. Jeremy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] virtual list control
Hi Fabian On 15 April 2012 21:40, Jeremy O'Donoghue jer...@o-donoghue.com wrote: They could be added easily. I'll take a look. On 15/04/2012 12:16, Fabian Binz fabianb...@yahoo.de wrote: Hello, ** ** I need to display a quite large number of data in a list control and use the ‘items’ attribute for that purpose. However, I’m not content with the speed of this solution andwould like to use a ‘virtual’ list control instead, as it is described here: [1] ** ** The problem is, that the necessary constants and functions (i.e. wxLC_VIRTUAL) are not defined by wxHaskell. Is there a technical reason for this or could they be added easily? I have just pushed experimental support for virtual list controls to the GitHub experimental repo. You're welcome to give it a try. https://github.com/jodonoghue/wxHaskell/commit/b5d1029b272460d729950d751d90da76df56b5dc Added methods: listCtrlGetItemFont, listCtrlIsVirtual, listCtrlRefreshItem, listCtrlRefreshItems. Added constants: wxLC_VIRTUAL, wxLC_MASK_TYPE, wxLC_MASK_ALIGN, wxLC_MASK_SORT. Removed deprecated constant wxLC_USER_TEXT. I'll be pushing the work which I've pushed over the last week or so to the Darcs repo next week, and will make a release to Hackage once I have had a chance to test on all platforms (I've only verified on Mac for the moment. Best regards Jeremy -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] virtual list control
They could be added easily. I'll take a look. On 15/04/2012 12:16, Fabian Binz fabianb...@yahoo.de wrote: Hello, I need to display a quite large number of data in a list control and use the items¹ attribute for that purpose. However, I¹m not content with the speed of this solution and would like to use a virtual¹ list control instead, as it is described here: [1] The problem is, that the necessary constants and functions (i.e. wxLC_VIRTUAL) are not defined by wxHaskell. Is there a technical reason for this or could they be added easily? Regards, Fabian [1]: http://docs.wxwidgets.org/trunk/classwx_list_ctrl.html http://docs.wxwidgets.org/trunk/classwx_list_ctrl.html -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2_ __ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [Announce] wxHaskell 0.90
I'll try and take a look at it this week. Currently I don't have a convenient wxWidgets 2.8.x development environment, but I'll create one. Jeremy On 14/04/2012 22:40, Henk-Jan van Tuyl hjgt...@chello.nl wrote: L.S., I had some problems installing the branch for wxWidgets 2.8.x: The command cabal install 'wx 0.90' results in Resolving dependencies... Downloading wxdirect-0.90... : . The dependency on wxcore in wx.cabal (version 0.13.2.1) must have an upper limit ' 0.90' and the dependency in wxdirect in wxcore.cabal (version 0.13.2.1) must have an upper limit ' 0.90' Another bug: Cabal-install tried to install wxc-0.90; I saw the following error message: setup.exe: This version of wxcore requires wx 2.9 to be available wx should be wxWidgets, of course. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Issues with GHCi support and TextCtrl
Hi On 17 April 2012 12:47, Heinrich Apfelmus apfel...@quantentunnel.de wrote: GHCi support is currently a mixed blessing on MacOS X. It works the first time but tends to crash when trying to call the start function again. Of course, this is not unexpected, but maybe it's possible to fix it to some extend. I had similar problems when dealing with the OpenAL or the GLFW frameworks, the solution was often to simply skip the termination routines. Not pretty, but it works. Thanks for looking at this. I'll look into your workaround suggestion. On that note, the EnableGUI trick is very cumbersome, it would be nicer if this could simply be integrated into wxHaskell, i.e. calling the start function will immediately enable the GUI thing. I can try to look into this. Thanks again. The more important issue is that TextCtrl widgets have changed their behavior: the entry function will now create a multiline widget! To create a single-line text entry widgets, I have to use the textCtrlEx function with flag 0 . This is extremely weird. Also, the latter widget sometimes crashes on me when trying to set the text, but the former doesn't. This is so weird that I can't even tell whether the problem is likely with wxWidgets or with the Haskell bindings. This is a strange one - I don't think we have changed any code in this area. I'll check it out though. Jeremy -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [Announce] wxHaskell 0.90
I think I have already worked out the patch - so don't worry too much. Jeremy On 14 April 2012 15:08, Eric Kow eric@gmail.com wrote: Nice catches! On 14 Apr 2012, at 14:31, Heinrich Apfelmus wrote: Apologies for the long description, I just don't know how to send a patch. Can you do the following? darcs record darcs send -O and then email the patch to wxhaskell-de...@lists.sourceforge.net If you have an MTA like postfix or msmtp set up, darcs can automate the emailing http://wiki.darcs.net/Using/Send -- Eric Kow http://erickow.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [Announce] wxHaskell 0.90
Patch for wxc added, built, tested and pushed to Hackage and code.haskell.org (as wxc 0.90.0.2) The Hackage version also now includes Eric's GHC 7.1.x fix. Jeremy On 14 April 2012 15:09, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: I think I have already worked out the patch - so don't worry too much. Jeremy On 14 April 2012 15:08, Eric Kow eric@gmail.com wrote: Nice catches! On 14 Apr 2012, at 14:31, Heinrich Apfelmus wrote: Apologies for the long description, I just don't know how to send a patch. Can you do the following? darcs record darcs send -O and then email the patch to wxhaskell-de...@lists.sourceforge.net If you have an MTA like postfix or msmtp set up, darcs can automate the emailing http://wiki.darcs.net/Using/Send -- Eric Kow http://erickow.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] [Announce] wxHaskell 0.90
Hi Haskellers, I am delighted to announce the release of wxHaskell 0.90. This release represents a significant milestone for us as it includes support for wxWidgets 2.9.x. The release is avalable from Hackage and as a darcs repo from http://code.haskell.org/wxhaskell. Build and installation instructions have been updated on the Haskell wiki at http://www.haskell.org/haskellwiki/Wxhaskell. Highlights of the new release: - Builds and runs cleanly on 64 bit platforms (particularly MacOS X Lion). - The wxWidgets C wrapper is now built as a DLL on all platforms. - This is reported to enable meaningful use of wxHaskell in GHCi, at least on OS X and Windows. - It also theoretically allows wxc to be used independently of wxHaskell as the basis of a wxWidgets wrapper for other programming languages. Some D language hackers have expressed an interest in this. - New controls: - Styled Text Control (actually, this is reinstated as it was 'lost' a while back during cabalization) - OpenGL support - PropertyGrid control - Many events added in anticipation of wrapping more controls in the near future. There were many contributors to this release, the most notable being Dave Tapley (with the generous support of Mentics Inc.). Dave was responsible for the refactoring of wxc and PropertyGrid support. Eric Kow put in quite a bit of work with Kenny Frodo, Doaitse Swierstra and Alessandro Vermeulen on MacOS support. There were a couple of contributions from long-time wxHaskell contributor shelarcy, and bug reports, fixes and support from a larger community than I ever realised we had. Support for wxWidgets 2.8.x will continue in a 'maintenance mode' continuing from the wxHaskell 0.13 codeline. If you continue to use the old codeline, please take note of the changes to the procedure to get the correct version for your needs. This is also documented at http://www.haskell.org/haskellwiki/Wxhaskell. Thanks to everyone involved. Best regards Jeremy -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Major changes to repo at code.haskell.org
Hi wxHaskellers, I am about to apply a fairly significant set of changes to the wxHaskell master repository at code.haskell.org. This is in order that I can apply the changes needed to support wxWidgets versions from 2.9 onwards, and the major architectural changes this entails. The changes will be as follows: - The current mainline tip will be branched into a wxhaskell-0.13 codeline, which will receive only minor updates going forward. This codeline will be appropriate for users of wxWidgets 2.8.x. In practice, this means that users who pull the darcs repo will see the following new directories: - wxdirect-0.13: The branch of wxDirect supporting wxWidgets 2.8.x - wxcore-0.13: The branch of wxcore supporting wxWidgets 2.8.x - wx-0.13: The branch of wx supporting wxWidgets 2.8.x - The mainline tip will be tagged WXHASKELL-0-13-BRANCH to show the historical relationship between the two branches. - The mainline will have the patches needed to update to support wxWidgets 2.9.x, based on the work by Dave Tapley and others, and sourced from the development repositories on Darcsden, Readers of the wxhaskell-devel list will be familiar with these. - Because Dave's codebase was branched late last summer, it has not been possible to simply push his patches to the wxHaskell mainline, since darcs never manages to resolve the differences. For this reason, I have developed a smaller, equivalent set of patches on whcih I have tried to maintain as much history as possible. This is regrettable, but I don't see an easy way around the problem. - There are a number of changes, but the most significant is that there is a new module, wxc, which contains the wxWidgets C language wrapper. Wxcore is now a pure Haskell module. In addition, we have removed the vestiges of Eiffel support from wxc. - The new codeline starts as version 0.15. Users will find that this is contained in the directories: - wxdirect: wxDirect version supporting wxWidgets 2.9.x and later. Because Eiffel support is removed, this version cannot be used with wxhaskell 0.13. - wxc: The C language wrapper for wxWidgets. On our supported platforms (Windows, Linux, OS X), this always generates a shared library. As such it is theoretically possible for wxc to be used as the basis for a wxWidgets binding for another language. There are members of the D community playing with this idea. - wxcore: A pure Haskell wrapper over wxc. - wx: This is basically unchanged from wx in revision 0.13. When the new versions are committed, they will be accompanied by uploads to Haskage from both branches, along with build instructions for both versions. Shortly after the formal release of 0.15, I will be producing a cabal wrapper for wx-config on Windows. This will simplify the Windows build significantly, as it currently depends on my privately updated version of wx-config-win on Google code. Please shout loudly and soon if you have any problem with what I am planning to do, as I am planning to make these changes within the next week. The wxWidgets 2.9 support has been waiting in limbo for too long now (my fault, I accept). Best regards Jeremy -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] ListCtrl scroll state or Virtual ListCtrl, and I'd appreciate some mentoring
Hi Aur, On 24 March 2012 22:07, Aur Saraf sonofli...@gmail.com wrote: I need a ListCtrl that I can edit and not only append to. That means either a version of appendItem that takes an index that I've missed, a way to get and later set the scroll-state of a ListCtrl (and then I can just reset all items on every edit) or a way to use the wxLC_VIRTUAL style available in C++ wxWidgets. For your purposes, the wrapper of ListCtrl in Graphics.UI.WX.Controls is probably not going to do everything you will need it to. You will likely need to drop down to the lower level API in wxcore. If you look in Graphics.UI.WXCore.WxcClassesAL, you will find a pretty complete binding to all of the functions in the wxWidgets C++ API. These all start with listCtrl in their names, and are pretty much exact Haskell representations of the C++ API functions. As an example, wxListCtrl::InsertItem() becomes listCtrlInsertItem in Haskell. For functions which have overloads in C++ (as this example does), you will find that there are several variants of listCtrlInsertItem which have slightly different names - the choice of which should be reasonably obvious. Because the functions in the wxcore API are so closely related to the C++ API, the good news is that you can more or less just translate any sample code for C++ into Haskell. The bad news is that it feels a lot like programming in C++. Also, as I said in the title, I'd really appreciate if someone could take some time to be available for a few beginner questions on some chat or email platform. I find that wxHaskell has too much lore for me to learn without an experienced hand guiding me. I promise to research every question before I resort to asking my mentor. You will find that list contributors are usually pretty helpful. I would suggest that that you start with my blog: http://wewantarock.wordpress.comWhile it is far from complete, and is only updated rather sporadically, it has been written to answer some of the issues I came up against when taking on wxHaskell as a new maintainer. For your specific problem with ListCtrl, you may do well to look at the wxWidgets Programming book. This is (obviously) written for C++, but covers Virtual ListCtrl (on page 330). There seems to be a downloadable PDF at http://www.google.co.uk/url?sa=trct=jq=esrc=ssource=webcd=5ved=0CGQQFjAEurl=http%3A%2F%2Fptgmedia.pearsoncmg.com%2Fimages%2F0131473816%2Fdownloads%2F0131473816_book.pdfei=DDxwT8KDFMKeOrWwqeEFusg=AFQjCNG49vErXpJEtko5Xe1uROZP-Asp6w Best regards Jeremy -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Creating an new attribute
Hi,
On 28 February 2012 03:28, Alexander McPhail
haskell.vivian.mcph...@gmail.com wrote:
Hi,
Using GTK, the following works
code
-- | create a new 'Figure' plot
-- click on the window to save
plotNew :: FigureHandle - IO DrawingArea
plotNew f = do
canvas - drawingAreaNew
set canvas [maybeFigure := (Just f)]
return canvas
-
-- | the figure attribute
figure :: Attr DrawingArea FigureState
figure = newAttr getFigure setFigure
where getFigure o = do
Just f - get o maybeFigure
readMVar f
setFigure o f = set o [maybeFigure :~ (\(Just h) - do
modifyMVar_
h (\_ - return f)
return $
Just h)]
-
maybeFigure :: Attr DrawingArea (Maybe FigureHandle)
maybeFigure = unsafePerformIO $ objectCreateAttribute
{-# NOINLINE maybeFigure #-}
-
/code
I am attempting to port this code to WxHaskell but can not see how to
create a new attribute for the `FigureHandle`.
This is the code I have so far
type FigureHandle = MVar FigureState
-
-- | create a new 'Figure' plot
-- click on the window to save
plot :: Frame () - FigureHandle - IO (Panel ())
plot fr f = do
p - panel fr [figure := f]
set p [on paint := paintFigure p]
return p
paintFigure :: Panel () - DC a - Rect - IO ()
-- | the figure attribute
figure :: Attr (Panel a) FigureHandle
figure = newAttr figure getFigure setFigure
where getFigure o = do
readMVar figureHandle
setFigure o f = do
modifyMVar_ figureHandle (\_ - return f)
You may find this entry from my blog helpful:
http://wewantarock.wordpress.com/2010/01/11/custom-controls-in-wxhaskell-part-3/
I think you cannot create an attribute for FigureHandle. Attributes in
wxHaskell are typed on the control to which they apply, for example (taken
from the blog) if you have a DiffViewer control, then to create a diffFiles
attribute which sets the files to be compared has the type signature below
diffFiles :: Attr (DiffViewer a) (FilePath, FilePath)
diffFiles = newAttr diffFiles dvGetFiles dvSetFiles
where
dvGetFiles win = {- Code follows... -}
dvSetFiles win (txt1, txt2) = {- Code follows -}
You can just as easily create a new attribute for an existing control. In
this case, I think that what you need is much closer to the code you have
for GTK than what you have shown for wxHaskell.
Hope this helps - I don't have a Gtk2Hs install to let me check they types
of your working code, I'm afraid, so there is a bit of guesswork on my side.
Best regards
Jeremy
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] The future of wxC
Hi lists, There have been a number of discussions over the past week or so on the future of wxC. I'm not as good as Dave at cross-referencing everything, but at the very least we have: http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg01050.html http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00735.html http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00736.html http://wewantarock.wordpress.com/2012/01/12/who-is-my-community/ http://www.reddit.com/r/programming/comments/oek2t/any_interest_in_a_c_binding_to_wxwidgets_from/ What I have tried to do is to raise the option of making wxC a separate project to other groups (Dave and Eric have reached out to a couple of other comunities as well), and see whether there is much interest out there. The most concrete interest has come from the D community, which lacks a good GUI binding, and which (it seems to me, based entirely on blog noise) is growing pretty rapidly, with some more vague interest coming from the wxWidgets community more generally (and granted that I have not done much to reach out in that direction). I must say that I am at least somewhat convinced that there is demand for wxC 'out there', and it is therefore worth making an initial effort to make wxC a viable option for other language communities. With this in mind, I would like to suggest a staged approach - comments and opinions are very welcome. 1. The first stage is to simply get wxHaskell with 2.9.x support out of the door. I don't think we should change anything at this stage, other than that it definitely makes more sense to use wx-config-win on Windows platforms if we are going to work with others. 2. The second stage is to spin wxC off as a separate project. 1. Eric will probably kill me for saying this, but I think GitHub is probably the right place, possibly keeping Sourceforge as the project website and distribution point (I personally don't much like git, but it has mindshare, and probably makes more sense than Darcs for a non-Haskell project - plus my experience with patch-tag and darcsden has been that 'getting going' on a Windows machine is far from trivial). I could be persuaded to change my mind on this one, but probably only if one of the Darcs hosts can get the experience 'right' on Windows clients. 2. Keep the Cabal-based build system to start with, until there is clear evidence of non-Haskell contributions. 3. If wxC turns out to have legs, the main areas to attack should be: 1. Move to bakefile based build. 2. Automated generation of the binding. I must say that comments to the blog posting in particular were really quite encouraging, but I don't waht to put the cart before the horse. In particular, Gour (an ex-Haskeller) and Andrej seem keen to try out what we have already with D, which would make an excellent proof of concept. Once we've had some discussion (say around the middle of the week), I'd like to blog on what we propose to do, and start to reach out a bit further to other groups. Regards Jeremy -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [wxhaskell-devel] ANN: wxHaskell 0.13.2
On 9 January 2012 18:09, Dave Tapley dave.a.tap...@gmail.com wrote: On 9 January 2012 17:04, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: On 6 January 2012 16:02, Dave Tapley dave.a.tap...@gmail.com wrote: 2012/1/6 shelarcy shela...@gmail.com Needless to say, I have immediately hit the wx-config roadblock, since I have compiled a release build of wxWidgets 2.9.3, and wx-config-win only knows about debug builds. Welcome to the party :) Just for the sake of clarity, I feel obliged to question your use of the words release and debug; are you aware of the Debug Build Changes in wx3? Here's the news: http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html (seeing the date of the post made me realise just how far behind we are, and also how slow the wxWidgets release cycles are!) I wasn't aware of the blog posting, but I did realise that there were changes in this area - some of this is covered in the install instructions. Strictly I built with: BUILD=release DEBUG_INFO=default DEBUG_FLAG=1 This means I keep the asserts, which seemed like an appropriate configuration for wxHaskell development. That has manifested itself in this known issue with wx-config-win: http://code.google.com/p/wx-config-win/issues/detail?id=21 Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc? I dutifully downloaded the free version of Visual C++ 2010 express, loaded the wxWidgets 2.9.3 project, built, and ran some sample code. However when I tried to use wx-config-win I realised that it required a build.cfg file, which isn't generated when you build with VC++ (I suppose because VC++ manages all the build settings itself, and so doesn't need to export anything). Without this one is unable to install wxHaskell. I built with gcc. I have played with VC++ in the past, because the build 'just works' but it was really too painful to sort out the configuration. I turned to the wiki and discovered this: http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup) Using it as a guide (note that one can't use wxPack because there are no wxPack releases for the development (2.9.x) releases of wxWidgets) I was (almost) able to cabal install wxHaskell from my darcsden branch (it failed because I didn't --with-OpenGL the wxWidgets configure, and then I ran out of time). I am leaning towards doing something with Eric's wx-config. There are a couple of reasons for this: - It keeps us in control of our own destiny; - Haskell is a *much* more pleasant implementation language for a utility which mainly does text processing than C++. Does the group have an opinion on this? My feeling is that since the last commit to wx-config-win was in 2006, it may be a while before fixes come along, and even then, we will probably need to write the patches. Ah, well, yes.. Firstly the pro-(wx-config-win) items: * I contacted the owner of wx-config-win and he made me an owner of the Google code project, so we're 'in charge' now. * I got a small discussion going on its existence in #wxwidgets on freenode. The consensus is that, because /most/ people use Visual Studio (in some flavour) to develop with wxWidgets in Windows, there simply wasn't the need to maintain wx-config-win. As a result it was never stable enough to merit merging in to the wxWidgets code base. By comparison the wx-config we know and love on Linux systems (and, I presume, OS X?) is essential and so well maintained: http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in (I didn't realise until recently that it is just a shell script, copied in to your install dir and symlinked into your PATH). I did know that wx-config is just a shell script. I'm not so surprised that most wxWidgets developers on Windows use VS. It's a really nce development environment. I actually think they advertise support for too many build options when in reality only a few of them get any serious use. I was actually planning on looking carefully at wx-config while updating Eric's Haskell wx-config :-) And now the cons: * It is woefully out of date. There are 18 open issues ( http://code.google.com/p/wx-config-win/issues/list) and who knows how many undiscovered bugs. * As mentioned, the wxWidgets community doesn't seem desperately fussed about its existence, so long as Visual Studio is around * It's implementation is in need of an overhaul, as identified by the previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6) I tend to think that you've hit on the problem with this approach. The wxWidgets community doesn't really care. Therefore we would be left maintaining a piece of C++ to support what is basically our own need. So, in summary, I'm not sure. My optimist, open-source heart says we should resurrect the wx-win-config project. My do-it-the-right-way heart says we ditch the existing C++ source and replicate the shell script (Windows PowerShell anyone
Re: [wxhaskell-users] ANN: wxHaskell 0.13.2
On 5 January 2012 17:44, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote: The source repository at code.haskell.org has not yet been updated with the patches. This will happen in the next day or so. The source repository at code.haskell.org has now been updated with wxHaskell 0.13.2 plus the two patches (add IOExtra to wxdirect and remove old-time from wxcore) from Shelarcy. I suggest a period of one more week (i.e. until 15th Jan 2012) for any further issues or fixes on the 0.13.2 series. After that, Dave, Eric and others will start to upload the changes needed to support wxWidgets 2.9.x. These changes will not work against wxWidgets 2.8.x installations, and are pretty significant in places. Please expect the main repo to unstable for a while after next Sunday. Best regards Jeremy -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] ANN: wxHaskell 0.13.2
Hi Lists, I am please to announce that wxHaskell 0.13.2 has just been uploaded to Hackage. This is mainly a bugfix release, although it brings a few useful changes: - Changes to support build under Haskell Platform 2011.4.0.0 - OpenGL support if your wxWidgets build is configured with it (reinstated functionality) - StyledTextControl support if your wxWidgets build is configured with it (reinstated functionality) This is intended to be the final wxHaskell release supporting wxWidgets 2.8.x. Provided that you have a suitable Unicode wxWidgets 2.8 install configured on your machine, you should be able to install with. cabal install wx In the near future, we will be committing an updated wxHaskell release supporting wxWidgets 2.9, but this implies a number of breaking API changes, and the size of team supporting wxHaskell is not large enough to cover both. As such, this release is recommended to those who will not be able to move to wxWidgets 2.9 and later. The next release has more significant improvements planned, including wrapping several additional wxWIdgets libraries and restoring correct operation in GHCi. We do not have a formal timeline as yet, but the code is working in test repositories, and mainly needs work to make it cross-platform clean. This release has been tested on the following platforms: - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode, Release) - OpenGL is not enabled on the test platform, so OpenGL samples do not work. - StyledTextControl is not enabled on the test platform, so STC samples do not work. - All other sample code compiles, links and runs, but has only been tested for Unicode wxWidgets builds. - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10 - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev, libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa, libglu1-mesa-dev, mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6 - Cabal packages: strict, stm, OpenGL, cabal-install - OpenGL is enabled on the test platform, and the samples compile and run. - StyledTextControl is not enabled on the test platform, so STC samples do not work. - All other sample code compiles, links and runs, but has only been tested for Unicode wxWidgets. I do not have access to an OS X platform for test, so would appreciate feedback on any issues found by OS X users. There are known to be issues on 64 bit OS X builds, which will be addressed in the next release. The source repository at code.haskell.org has not yet been updated with the patches. This will happen in the next day or so. Best regards Jeremy -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Again StyledTextControl
Hi Paulo, On 21 October 2011 14:22, Paulo Pocinho poci...@gmail.com wrote: I have spent the last three days figuring how to build wxWidgets. After much frustration with GCC, digging information from patches and several websites, I can now build the 9,87 MB wxmsw28u_gcc.dll version 2.8.12 that works. Yet, I have a new barrier and have to ask for your help. STC was built from contrib. Then I took directions from this thread http://sourceforge.net/mailarchive/forum.php?thread_name=CDCEC7C4-4463-46FF-BA06-17CC842A05BD%40dc.uba.arforum_name=wxhaskell-devel Did everything like this http://haskell.org/haskellwiki/WxHaskell/Building_with_styledTextCtrl_support At the moment, STC support is disabled as it is difficult to get contrib components to build (or not) reliably under the Cabal build system we have. The error you have is because Cabal is not linking the library containing STC. The quickest way to get this to work (it is a bit of a dirty hack) is to edit wxcore/Setup.hs. In myConfHooks you will find extra_wx_libs. If you add the name of your stc library correctly in there (and assuming that the compiler can find the path to it), I believe it should build, compile and link for you. The clean way to do this is to come up with a proper solution for integrating contrib components in wxHaskell, which is mainly held up by the lack of a working wx-config for Windows which behaves identically to wx-config for Unix platforms. There has been some good work (not by me, I hasten to add!) in this direction, but we need to get it properly integrated and tested on all platforms Regards Jeremy -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Extending a functionality of wxDirDialog
Hi Rosario On 8 August 2011 03:25, Rosario Borda rosario.bo...@sinervis.com wrote: Hi all. I apologize for my imperfect english. I'm a begginner in gui development. I need to extend the wxDirDialog allowing multiples selections of folders. It is possible? Any suggestion? I'm afraid there is no way to do this - or at least no easy way. There are two ways that I think you could try. The first is to use wxFileDialog with wxFD_MULTIPLE style. This uses the normal file selection dialog, but allows you to select multiple items. The second, better way to do things would be to create a tree control. The FileBrowse.hs sample shows you how to create a tree control, but you will need to make some changes to allow multiple selections. Firstly you will need to call wxTreeCtrl_Create with wxTR_EXTENDED in the style field, instead of using treeCtrl. Secondly, you will need to modify the event handling for onTreeEvent to properly handle multiple selection and deselection but modifying the handling of TreeSelChanged. I hope this helps you to move forward. Regards Jeremy -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Haskell Platform
[x-posting wxhaskell-devel] On 12 June 2011 18:43, Guy guytsalmave...@yahoo.com 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] Change the range of a spin control
Probably too late to help, but try spinCtrlSetRange :: SpinCtrl a - Int - Int - IO () The API documentation hasn't kept up with wxHaskell itself :-( On 10 May 2011 10:15, Guy guytsalmave...@yahoo.com wrote: On 10/05/2011 11:28, Guy wrote: How can I change the range of a spin control after it's been created? Note: WxWidgets has a function wxSpinCtrl::SetRange, but I can't find the wxHaskell wrapper for it. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell repo restored to code.haskell.org
On 3 June 2011 12:44, e.y@brighton.ac.uk wrote: On Fri, Jun 03, 2011 at 12:14:58 +0100, Jeremy O'Donoghue wrote: - Bugfix for assert error in SearchDynamicEventTable which was found in debug builds. I believe that this is a proper fix for an issue Eric noted a couple of months back. It's not just debug builds (of what?), Of wxWidgets itself. I don't see the assertion for retail builds. I *do* see the assertion on debug builds for Windows, so I don't think it's a Mac issue. but basically the scenario where you naively type cabal install wx on MacOS after having installed the Haskell Platform and nothing else. Macs ship with wxWidgets, albeit with this crucial bit of missing functionality. I'm a bit concerned that this may result in silently-does-the-wrong-thing errors + if (evtHandler-GetDynamicEventTable() != NULL) +found = evtHandler-SearchDynamicEventTable( event ); As I'd discovered to my dismay, without this trawl through the non-existent dynamic event table, things like scrolled list boxes stop responding to events. http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00580.html This is a bit more worrying - it's likely to be seen on other platforms as well. I didn't see the problem on any of the (few) test cases I ran, but it sounds more like a failure of what might laughably be called my test regime than a Mac specific issue. If I understand the patch correctly, the result of this is that (A) users would be able to happily install wxHaskell on Mac without any prerequisites, but (B) if they were to use such a widget, it would just silently not-work. No - I think it would silently not work everywhere :-( The even better solution would be for somebody to go understand how the event handling code works and propose a solution that works without the missing dynamic event table That's probably a better bet. I have the impression that you're not really supposed to call wxEvent::SearchDynamicEventTable() from outside anyway. They seem to have gone to some lengths to not document it in wxWidgets. I will have a go at understanding the event handling code. Wish me luck, I'll probably need it... Jeremy -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] where should I ask user questions about wxHaskell
On 1 June 2011 05:09, 诺铁 noty...@gmail.com wrote: I should have subscribe to this list. I tried to subscribe again,and recieve An attempt was made to subscribe your address to the mailing list wxhaskell-users@lists.sourceforge.net. You are already subscribed to this mailing list. list manager,would please check my subscribe status,thank you. You are subscribed, and your 'moderate' flag has been cleared. On Wed, Jun 1, 2011 at 6:44 AM, Henk-Jan van Tuyl hjgt...@chello.nlwrote: On Tue, 31 May 2011 22:13:42 +0200, 诺铁 noty...@gmail.com wrote: Hi, it seems that this list require approval,which is quite slow. so I guess maybe it's not right place to ask user questions. so where is the right place? New subscribers to the list always have a 'moderate' flag set, so your first posting is held in a queue to make sure that it is relevant. After your first (relevant) post to the list, mails are no longer moderated, as you will have noticed - this mail thread has appeared on the list without delay. I accept that this is an inconvenience for new list users - I know that when I have a question I always want an immediate answer, and it can be frustrating when this doesn't happen. Unfortunately, over 95% of mail sent to wxHaskell lists is spam, so moderation is an essential part of keeping the list relevant and useful. I try to moderate reasonably frequently, but you need to know that: 1. I am located in the UK, so mail sent while I am asleep definitely won't get moderated until I wake up! I typically look to see if I should moderate once a day, so again, and depending on timing, you may be unlucky and get your question delayed. 2. I am by far the moderator on the list, so if I'm away or very busy, things happen more slowly than daily. Actually, Eric helps out as a courtesy when my response is slow, but it's only a courtesy (i.e. the responsibility for responsiveness is mine) 3. I am pretty busy outside of wxHaskell with a fairly heavy day job (I am the software lead on two significant, non-Haskell, projects with a major fabless semiconductor company) and a young family. Inevitably, these have to come first. The moderation flag only applies to new list members, so I don't believe you will see the problem again. If you subscribe to this list, your e-mails do not require approval; it is the right place for user questions. This is definitely the correct place for questions. I would also like to mention that the wxHaskell community is fairly small, although we try to follow the example of the wider Haskell community in being as helpful as possible. This means that there may not be so many people who can give a good answer to your question. Best regards Jeremy -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Property sheet
Hi Joel, On 1 June 2011 04:19, Joel Shellman j...@mentics.com wrote: Is there a property sheet/grid/panel type of widget available via wxHaskell? I saw a wxPropertyGrid and wxPropertySheetDialog in the wxWidgets docs, but couldn't find anything like that in the wxHaskell docs on hackage. At this time, wxPropertyGrid and wxPropertySheetDialog are not wrapped. wxPropertyGrid is new in wxWidgets 2.9 - at present, none of the 2.9 new features has been wrapped. wxPropertySheetDialog is present in 2.8, possibly earlier. I will try to get around to wrapping it shortly. Regards Jeremy -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] newbie question, why clientSize doesn't affect textEntry?
The full explanation is a bit tricky (tricky enough that I don't fully understand or I would have fixed it!), but results from the way in which Layout works. Layout is a neat idea, but has a number of quirks. The main thing to realize is that Layout creates an hierarchy of Sizer instances which contain your control instances. The interaction between the Sizers and control size constraints can be tricky to fathom, but basically the Sizer constraints seem to override clientsize directives. My best advice would be to use either Layout and nothing else (as Carlos suggests) or use Sizers manually and ignore Layout. I used this alternative approach in m Custom Control tutorial - see http://wewantarock.wordpress.com/2010/01/10/custom-controls-in-wxhaskell-part-2/ Regards Jeremy On 31 May 2011 23:05, carlos gomez carliro...@gmail.com wrote: I don't understand too. Looks like some misterious thing is happening. But you can use the 'mimsize' layout funcion from WXCore in order to get what you want. Here the code: module Main where import Graphics.UI.WX main::IO() main = start gui gui :: IO () gui = do f - frame [text := timer] panel - panel f [clientSize := sz 200 100] hr - textEntry panel [ text := hour , clientSize := sz 10 10 ] min - button panel [ text := min , clientSize := sz 10 10 ] sec - textEntry panel [ text := sec , clientSize := sz 10 10 ] -- layout set panel [layout := margin 10 $ row 1 [ minsize (sz 10 10) $ widget hr , widget min , minsize (sz 10 10) $ widget sec ] ] set f [layout := widget panel] On 30 May 2011 05:49, 诺铁 noty...@gmail.com wrote: Hi, I am learning wxHaskell,and trying to create a small timer app. I don't understand why in following code ,clientSize only affect button control module Main where import Graphics.UI.WX main::IO() main = start gui gui :: IO () gui = do f - frame [text := timer] panel - panel f [clientSize := sz 200 100] hr - textEntry panel [text := hour,clientSize := sz 10 10] min - button panel [text := min,clientSize := sz 10 10] sec - textEntry panel [text := sec,clientSize := sz 10 10] -- layout set panel [layout := margin 10 $ row 1 [widget hr,widget min,widget sec]] set f [layout := widget panel] -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] OpenGL support
Hi Joel, On 25 May 2011 21:04, Joel Shellman j...@mentics.com 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 -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] OpenGL support
On 26 May 2011 12:31, Henning Thielemann schlepp...@henning-thielemann.dewrote: Jeremy O'Donoghue schrieb: On 25 May 2011 21:04, Joel Shellman j...@mentics.com mailto:j...@mentics.com 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 -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wx-2.9 ?
Hi John, Apologies for taking a long time to moderate. I have cleared the moderate flag for you, so hopefully your messages won't be delayed in future. On 18 May 2011 12:56, John Lato jwl...@gmail.com wrote: Hello, Is anyone working on updating wxHaskell to work with wx-2.9, or does this already work (or mostly work)? My motivation is that I'd like to use wxHaskell on OS X 64-bit, which is only supported in the development version of wxWidgets. Provided that the changes needed are not too significant (and I do not think they will be), wx-2.9 will be supported shortly after the wxHaskell repo on code.haskell.org is restored (i..e I'm trying to get wxHaskell to build against wxWidgets 2.9.1 as I write) Jeremy -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxDisplay wrapping
Hi Eric, Brian,
I must admit that until this came up, it hadn't occurred to me that the
code.haskell.org attack and rebuild would have this impact (even though it's
blindingly obvious in retrospect).
I will get the repo back online in the next day or so. Eric, if you contact
me off-line and explain what I need to do to upgrade to hashed format, I'll
be very happy to do so).
There are two aspects to wrapping additional functionality. One is basically
easy and the other is hard.
Wrapping core wxWidgets functionality is pretty straightforward.
1. In wxcore/src/include/wxc_glue.h, for each class required
1. Add a class derivation using the TClassDefExtend macro
2. Add suitable C function declarations, following some of the
existing code as an example. I recommend following the naming convention:
wxClassName_MethodName(), although you will need to do something for
methods which overload by parameter types (usually constructors)
2. In wxcore/src/cpp, for each class required
1. Add a new file, named for the class it contains. In your case, the
most suitable name would probably be display.cpp. This contains the
implementation for the prototype declarations you wrote in (1.2)
above. The
format is very straightforward, and you should follow examples from other
files. In particular:
1. Each wrapper function needs a 'self' parameter, which is a
pointer to an instance of the class you are wrapping.
2. If you are performing an operation which will return a
structure, you will need to allocate something suitable, as
Haskell doesn't
do it for you.
3. The exported functions require C linkage (i.e. no C++ name
mangling). The simplest way to do this is to ensure that your
functions are
defined inside an
extern C { ... }.
3. If you have any new constants, add them in wxcore/src/eiffel
4. Modify wxcore/wxcore.cabal, in the extra-source-files stanza to
include your new cpp file. Please also add a minor version update in
wxcore.cabal.
5. (Optional) - if you can think of a way to provide a more idiomatic
Haskell interface to your wrapped class, add something in
wx/src/Graphics/UI/WX. It is probably better to do this after you have been
using the bare wrapped interface for a while, as you will have a good feel
for how you use the functionality in practice.
6. (Optional - only if you did 5) - Add your Haskell module to the
Exposed-Modules stanza in wx.cabal, and bump the minor version.
You can then build from source as per the instructions. You should find that
wxcore/src/haskell/Graphics/UI/WXCore/WxcClassesAL.hs (or WxcClassesMZ.hs)
has been updated with Haskell wrappers for your C++ wrapper functions.
It is far harder to write a wrapper for a significant optional functionality
like WxSTC. WHile Shelarcy succeeded, the way this was done is not very
scalable as it requires modifications in wxdirect (the wrapper generator),
which is something to be avoided if possible.
Happily, wxDisplay fits comfortably into the first category.
Regards
Jeremy
On 9 March 2011 09:59, Eric Y. Kow eric@gmail.com wrote:
On Wed, Mar 09, 2011 at 02:00:19 +, Brian Victor wrote:
1) What's the current source repo? The wiki points to
http://code.haskell.org/wxhaskell/ which is 404.
That's still the right place, but it's not been restored since
the recent attack on community.haskell.org.
Jeremy, have you had a chance to look into putting the repository
back online? Hopefully we can upgrade it to the hashed format
along the way.
2) Once I get the source, what do I need to do to wrap wxDisplay? Is
there a good model I can look at to copy? (I've only looked at
Haskell's FFI functionality briefly, so I expect a learning curve.)
3) How likely is it that a patch for this will be released relatively
quickly?
I can't comment on the above. I think shelarchy managed to wrap wxSTC
before
Thanks,
--
Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow
For a faster response, try +44 (0)1273 64 2905 or
xmpp:ko...@jabber.fr (Jabber or Google Talk only)
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
wxhaskell-users mailing list
Re: [wxhaskell-users] ListCtrl - Setting/Getting Associated Info?
Hi James,
On 29 October 2010 05:06, James d'Arcy james.da...@wraithbane.com wrote:
Conceptually what I want to do is create items in the ListCtrl and
associate a
unique identifier with each item. This identifier would not be displayed in
the
UI. An Int64 would be ideal but a String would be fine. When a user clicks
on
the item, I want to be able to retrieve this identifier and use it to find
the
associated data, in this case a database record.
The items are inserted into the ListCtrl ok with the following code:
showStudy :: ListCtrl l - (Int,DicomStudy) - IO ()
showStudy wgDbTable (idx,dcmStudy) = do
listCtrlInsertItemWithData wgDbTable idx $ studyUid dcmStudy
set wgDbTable [item idx := [(patientName . studyPatient) dcmStudy,
studyDescription dcmStudy,
studyDate dcmStudy]]
and the event handler looks like this:
onDbTableEvent :: HasturContext - EventList - IO ()
onDbTableEvent HasturCtx {guiDbTable=wgDbTable, guiSeriesList=wgSeriesList}
event =
case event of
ListItemSelected idx - do
studyUid - listCtrlGetItemData wgSeriesList idx
infoM Hastur $ DB Table event: ++ show studyUid
propagateEvent
otherwise -
propagateEvent
When the user clicks on the ListCtrl item I get an error dialog pop up
saying:
Couldn't retrieve information about list control item X
where X is idx. The infoM call produces:
DB Table event: 0
What am I missing? I've tried listCtrl{Get/Set}Data, listCtrl{Get/Set}Text
all
with the same result. listCtrlDeleteItem in the event handler doesn't
delete the
item but produces the result: False.
showStudy wgDbTable (idx,dcmStudy) = do
listCtrlInsertItemWithData wgDbTable idx $ studyUid dcmStudy
set wgDbTable [item idx := [(patientName . studyPatient) dcmStudy,
studyDescription dcmStudy,
studyDate dcmStudy]]
I suspect that the problem comes from mixing WXCore and WX functionality
(highlighted in red above if you are using an HTML mailer - otherwise look
at the . I doubt that it is safe to do this.
Below is an example I have tested. I've tried to make it as simple as
possible, so it has a fixed list of (displayed) items, each of which has an
Integer key (which is not displayed - it is stored as a data item). I'll
write it up more fully in my blog (http://wewantarock.wordpress.com)
shortly, but for the moment, just note that I am using the WXCore functions
to insert the item data and the displayed contents.
module Main () where
import Graphics.UI.WXCore
import Graphics.UI.WX
-- Int data and strings for each column
entries
= [ (100, [BouncingBalls.hs ,2402 ,Jul 19 16:50])
, (101, [ByeDemo.hs ,1414 ,Jul 13 23:18])
, (102, [Camels.hs ,7633 ,Aug 20 11:57])
, (103, [Controls.hs,3862 ,Aug 20 11:57])
, (104, [HelloWorld.hs ,1028 ,Aug 15 10:09])
, (105, [ImageViewer.hs ,3756 ,Aug 20 11:57])
, (106, [Layout.hs ,1075 ,Jul 13 23:18])
, (107, [ListCtrl.hs ,750 ,Sep 8 16:22])
, (108, [Minimal.hs ,147 ,Jul 13 23:18])
, (109, [Paint.hs ,1024 ,Aug 20 11:57])
, (110, [Process.hs ,2261 ,Aug 20 11:57])
, (111, [TimeFlows.hs ,4929 ,Aug 20 11:57])
, (112, [TimeFlowsEx.hs ,8648 ,Aug 20 11:57])
, (113, [desert.bmp,61302 ,Jul 13 23:31])
]
main :: IO ()
main
= start gui
gui :: IO ()
gui
= do -- main gui elements: frame, panel, text control, and the notebook
f - frame [text := List Sample]
-- panel: just for the nice grey color
p - panel f []
textlog - textCtrl p [enabled := False, wrap := WrapLine]
-- use text control as logger
textCtrlMakeLogActiveTarget textlog
logMessage logging enabled
-- list control
l - listCtrl p [columns := [(Name, AlignLeft, 120)
,(Size, AlignRight, -1)
,(Date, AlignRight, -1)]]
set l [on listEvent := onListEvent l]
mapM_ (setItem l) entries
-- specify layout
set f [layout := container p $ margin 10 $
column 5 [ fill $ widget l
, hfill $ widget textlog
]
,clientSize := sz 400 300
]
return ()
where
onListEvent lc eventList
= case eventList of
ListItemSelected idx- do
dat -listCtrlGetItemData lc idx
logMessage (item selected: ++ show
idx ++ Data: ++ show dat)
ListItemDeselected idx - logMessage (item de-selected: ++
show idx)
other -
Re: [wxhaskell-users] [Haskell] Latest Haskell Platform for Windows (2010.1.0.0) does not seem to include C++ support
Hi list(s), (Apologies for cross-posting, but likely to be of interest to both lists) As lack of C++ support on latest Haskell Platform prevents wxHaskell cabal install for Windows, and may well be causing issues for others, I present a vile hack which will get you some level of working C++ support. This has been verified to work on a Windows 7 machine. You will need a clean MinGW 3.4.5 installation (I used the current Windows MinGW installer to get this, but many of you probably have MinGW lying around anyway) as a source for the files below: Copy cc1plus.exe from a MinGW 3.4.5 install into c:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\libexec\gcc\mingw32\3.4.5 Copy libstdc++.a from a MinGW 3.4.5 install into c:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\lib Copy the entire contents of include\c++ directory from a MinGW 3.4.5 install into c:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\include\c++ At this point you have a sufficient C++ environment to cabal install wx and get a working wxHaskell installation. There are a number of files missing from a complete MinGW C++ installation, so I don't guarantee this as working for all C++ code. On Windows 7, you will need to do your 'cabal install wx' in a command window running as Administrator. 'cabal install wx --user' does not work in a normal shell. I'll look into this later. Regards Jeremy On Tue, 04 May 2010 22:18 +0100, Neil Mitchell ndmitch...@gmail.com wrote: Hi On checking, Haskell Platform\2010.1.0.0\mingw\libexec\gcc\mingw32\3.4.5 does not contain cc1plus.exe. Previous versions of the platform have done so. Is this an accidental change or a deliberate policy decision? ghc-6.12.1 on Windows did not include the mingw C++ compiler. This was a mistake. It is included once more in ghc-6.12.2. ghc-6.12.1 didn't include cc1plus.exe or libstdc++.a. The lack of libstdc++.a caused a failure in something I was building, so I raised a bug and it's now included in 6.12.2. I didn't explicitly compile any C++ code, so it's possible that still doesn't work. It wasn't a policy decision, merely an accident, and I'm sure if you alert people it will be rectified (since otherwise it's a regression). Thanks, Neil -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxcore error on ubuntu
Hi Sok, I'm afraid this is a known issue for which I do not yet have a fix. Currently wxHaskell is not usable from ghci, I'm afraid. Regards Jeremy On 3 May 2010, at 14:29, Sok H. Chang wrote: I install ghc 6.10.4 on Ubuntu Karmic I install wxHaskell through cabal I try to use wxHaskell, I got some problem. The error message is... shae...@shaegis-laptop:~$ ghci -package wx Hello.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package stm-2.1.1.2 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package time-1.1.2.4 ... linking ... done. Loading package wxdirect-0.12.1.3 ... linking ... done. ghc: /usr/local/lib/wxcore-0.12.1.4/ghc-6.10.4/HSwxcore-0.12.1.4.o: unknown symbol `__dso_handle' Loading package wxcore-0.12.1.4 ... linking ... ghc: unable to load package `wxcore-0.12.1.4' How can I fix this? Thanks a lot ! -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Building on Windows 7
Hi Dan, I have confirmed the problem exists, but it's really a Haskell Platform (rather than Windows 7)issue - the latest Haskell Platform doesn't include C++ support. Workaround is to use the previous Haskell Platform version. I'm posting to Haskell list to see if there's a work-around. Regards Jeremy On Mon, 03 May 2010 00:41 -0400, Dan Haraj devha...@gmail.com wrote: I have been trying to build the latest version on windows 7 for a few days now. I have not managed to get it. The furthest I have gotten has given me an error-dump from cabal about /include/wx/string.h after [22 of 22]... \WXCore.o I built wx in the way that was prescribed by the wiki page. I then set the environment variable WXWIN and WXCFG properly. When I tried to run cabal install wx, it failed telling me I didn't have a long list of C libraries. I then ran cabal install wx --extra-include-dirs = --extra-lib-dirs to point to the libraries in my mingw distribution. I am using my own instead of the one that comes with the haskell platform because the latter didn't seem to have the libraries. I don't know. I am very new to Haskell. Anyway, running with the extra flags worked except for the error I described in the first line of this message. I don't know what to do. I have noticed that wxhaskell's wiki page does not state that it has been successfully built on Win7. Is this the state of things? Thanks -Dan - - ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] embedding web control
Hi Konstantin,
To answer your first question, frame returns a Frame (), which,
under the hood is an Object - that's another way of saying that
I think your code is at least correctly typed.
I think you would need to use wxDirect to integrate properly with
wxHaskell. It's a bit tedious, but not especially hard. I'll
probably write a blog posting about this soon, but the basics of
what you need to do are as follows:
Create an Eiffel(!) file containing all of the constant
definitions exported by wxWebConnect (or at least the ones you
want...). The reason for the Eiffel is historical: wxHaskell was
originally built on top of a (long-obsolete) binding of wxWidgets
to Eiffel. This requires no real knowledge of Eiffel: it's simply
a file containing lines such as:
wxMY_CONTROL_SOME_VALUE : INTEGER is 23
Create a C header file describing the API you want to wrap - this
is somewhat stylized, using macros to describe inheritance.
Run wxDirect over the newly created files - this autogenerates C
wrappers over the C++ classes/functions with appropriate Haskell
to use them.
I realize that this is a bit 'handwaving', but a full description
really requires quite a lot more than I can manage in a single
e-mail.
As a little more help, if you download wxCore source code (cabal
fetch wxcore), you can look at the following files for
inspiration:
wxcore/src/include/wxc_glue.h and wxc.h - these show the
'wrapping' style needed.
wxcore/src/eiffel/stc.e - this shows how to define constants in
the Eiffel format
WxDirect accepts the following options:
-d : create constant definitions from .e files
-c : create class definitions from .h files
-t : create class type definitions from .h files
-i : create class info definitions
-o : set the output directory
I suspect that you will have a bit of trouble with getting all of
this to work, so if you can wait (it may be a couple of weeks),
there may be a blog posting to help you.
Regards
Jeremy
On Mon, 05 Apr 2010 18:47 +0400, Konstantin Chugalinskiy
kchugalins...@gmail.com wrote:
Hello, wxHaskell community!
I need to embed web control into my application under Windows 7.
I am trying to use wxWebconnect
( [1]http://www.kirix.com/labs/wxwebconnect/documentation/getting
-started.html ) library with Gecko engine for this.
Haskell code:
foreign import stdcall unsafe _browserFrame
c_browserFrame :: Ptr a - IO(Ptr ())
main :: IO ()
main
= start gui
gui :: IO ()
gui = do
f - frame [text := Hello world!, size := (sz 600 600) ]
withObjectPtr f c_browserFrame
return ()
where browser frame looks like
C++ code:
void* __stdcall browserFrame (wxFrame* ptrWxWindow)
{
wxString xulrunner_path = FindXulRunner(wxT(xr));
wxString dir(wxT(\\plugins));
wxWebControl::InitEngine(xulrunner_path);
wxWebControl::AddPluginPath(dir);
wxWebControl* ptrBrowser = new wxWebControl(ptrWxWindow,
wxID_WEB, wxPoint(0,0), wxSize(600,600)); //Here error comes from
return ptrWxWindow;
}
it is compiled as dll by MS Visual 2008 and linked to Haskell
program.
Also it looks like CreateControl execution fails.
It should be mentioned that ptrWxWindow can be operated with no
errors (I mean hiding, resizing etc) and no any other kind of
control can be created (wxButton, wxLabel).
If first parameter to c_browserFrame (parent window) is
objectNull then everything is ok with no changes to gui. I can't
understand what is wrong with ptrWxWindow param when passed from
Haskell.
typeid(ptrWxWindow).name() shows expected type of ptrWxWindow -
wxFrame.
What am I doing wrong? Please help me. Or maybe can you help me
using your wxdirect subsystem to add this control to wxHaskell?
with best regards,
Chugalinskiy Konstantin
[2]kchugalins...@gmail.com
Jabber: [3]koschugalins...@jabber.ru
-
-
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
References
1. http://www.kirix.com/labs/wxwebconnect/documentation/getting-started.html
2. mailto:kchugalins...@gmail.com
3. mailto:koschugalins...@jabber.ru
--
Jeremy O'Donoghue
jeremy.odonog...@gmail.com
--
Download Intel#174; 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
Re: [wxhaskell-users] problems with cabal-installed wxHaskell and ghci (WinXP)
Hi Guenther, [x-posting to wxhaskell-devel, in case any of the other committers has a clue...] On Wed, 27 Jan 2010 17:04 +0100, Günther Schmidt gue.schm...@web.de wrote: I managed to cabal-install wxWidgets on WinXP last night. Now something strange happens when I test via ghci or runghc: could not find stdc++ dll Now I did copy the wxmsu ... dll into the path ie. C:\windows\system32 and when I run the compiled program it works. This is a problem which has had me stumped for several weeks now. I'll explain as best I can. The root cause of the problem is related to the MinGW gcc installation which is part of GHC, and which does C/C++ compilation and *all* linking for both GHC and GHCi. The basic problem is this: for some reason, almost all libraries in MinGW are dynamically linked *except* libstdc++, which is *always* statically linked(*). When compiling for GHC, this is no problem. the linker notices that there is only a static version of libstdc++ available and uses it. However, GHCi assumes (I think) that any libraries given to it on the command line need to be loaded dynamically. The incantation for which libraries to load when a package is loaded comes from the package definition (in this case from the cabal installation of wxcore). The problem is that I'm not sure of the best way forward on this, and I've tried quite a few things. What I really need is a coherent explanation of exactly how linking, compilation and package loading is implemented by GHC and GHCi - I understand the underlying gcc and gnu ld implementations well enough. I'll eventually get around to a more complete description of the problem and post to one of the GHC lists - but haven't done so as yet. Regards Jeremy -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxHaskell documentation
Hi David, No-one else has answered, so I will do my best for you... On Thu, 14 Jan 2010 13:15 +1300, David Streader d...@cs.waikato.ac.nz wrote: So *Question one*: What is the best source of documentation? An example - I have successfully used grids to generate layout for a frame/ dialog. But I need to know the name of a grid so that I can later set some of its attributes (add rows cols, ). The only commands I have found (in example code) to do this are Documentation and its layout are not always as clear as they could be for wxHaskell. Despite the fact that it is not the most 'interesting' or 'fun' thing for me to work on, I plan to do quite a bit of work on this in the coming weeks. Some will reflect itself in updated documentation in the source code and other aspects will probably turn into blog (http://wewantarock.wordpress.com) articles. The first thing to realize is that there are really three parts to wxHaskell: 1) The wrappings over the wxWidgets library. These are essentially C versions of wxWidgets C++ APIs, and they are mainly auto-generated from C code. The wrappings are almost undocumented beyond their types, and are mainly in the Graphics.UI.WXCore.Wxc hierarchy. I recommend using the wxWidgets documentation to find out more about these - it is generally pretty straightforward to work out what wxWidgets class and function is involved, and it is often particularly useful to look up functions in WxcClassesAL and WxcClassesMZ, which covers most of the lowest level wrapping. 2) Low level bindings over the library wrapper (rest of WXCore) - these are sparsely, but generally adequately documented 3) Higher-level (i.e. more declarative) functionality in Graphics.UI.WX - again, sparsely but adequately documented. g - gridCreate parent id rect flags gridCreateGrid g 0 0 0 But I have failed to find and documentation for gridCreate or gridCreateGrid where should I look. For this specific example, look in the documentation for Graphics.UI.WXCore.WxcClassesAL for 'Grid'. This lists a considerable number (I didn't count, but it must be around 100) of functions, including gridCreate and gridCreateGrid. The documentation you will see is extremely brief. It says: gridCreate :: Window a - Id - Rect - Style - IO (Grid ()) usage: (gridCreate prt id lfttopwdthgt stl) gridCreateGrid :: Grid a - Int - Int - Int - IO () usage: (gridCreateGrid obj rows cols selmode) To understand what these *really* do, we need to go look at the wxWidgets documentation, which in this case is at http://docs.wxwidgets.org/stable/wx_wxgrid.html#wxgrid. To really interpret what the functions do, you need to find the appropriate method names. One rule you need to know is that widgetnameCreate is a wrapper for the C++ constructor - in other words, we should look at wxGrid() to find out what gridCreate does. Things get a bit more complicated for overloaded constructors and methods, but it's usually not too hard to work out. So, finally, for your examples above: gridCreate is a wrapper for wxGrid::wxGrid(wxWindow* parent, wxWindowID id, const wxPoint pos = wxDefaultPosition, const wxSize size = wxDefaultSize, long style = wxWANTS_CHARS, const wxString name = wxPanelNameStr) Constructor to create a grid object. Call either wxGrid::CreateGrid or wxGrid::SetTable directly after this to initialize the grid before using it. gridCreateGrid is a wrapper for wxGrid::CreateGrid(int numRows, int numCols, wxGrid::wxGridSelectionModes selmode = wxGrid::wxGridSelectCells) Creates a grid with the specified initial number of rows and columns. Call this directly after the grid constructor. When you use this function wxGrid will create and manage a simple table of string values for you. All of the grid data will be stored in memory. For applications with more complex data types or relationships, or for dealing with very large datasets, you should derive your own grid table class and pass a table object to the grid with wxGrid::SetTable. The bad (and not really satisfactory, from a Haskell perspective) aspect of this is that you really need to have at least a limited ability to read C++ to understand this. *Question two*: Would it be better to use the wxWidgets documentation? if so is there any documented way to translate wxWidgets method calls into Haskell? Hopefully the example above covers this sufficiently? I hope that documentation will be an aspect of wxHaskell which improves significantly in the near future. Best regards Jeremy -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established
Re: [wxhaskell-users] wxhaskell vs. gtk2hs
Hi Gour, 2010/1/19 Gour g...@gour-nitai.com Now, based on what I know so far wxhaskell may be better supported on Mac since GTK+ port is not finished. otoh, I'm a bit concerned about Since the core interface is generated automatically from the wxEiffel binding... and visiting the project show the status notice: The 0.7 release will probably be the last official release. The project lost its core developer following the 0.7 release in late June 2003 and it is unlikely that anyone will be able to take on this vital role. So, my question is if this dependency on wxEiffel will change soon, especially considering the upcoming wx-3.0 release? I'm not sure where you found this quote. A (small) team of developers took on maintenance of wxHaskell over three years ago, and we have been keeping it up to date ever since. While there are some vestiges of the Eiffel heritage in the wxHaskell source code, there is no dependency on the wxEiffel binding. The dependency on wxEiffel really disappeared before I became involved in the project. The latest wxHaskell release supports wxWidgets 2.8.10 (which I believe is the most recent stable version), and we will update to wxWidgets 3.0 shortly after this becomes available. Another concern is question of memory management touched upon in the following article: http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/ So, can someone share some thoughts about gtk2hs vs. wxhaskell with the reference to ease of use, learning curve etc. for a noob not being too familiar with none of the toolkits and considering suitability for multi-platform development in Haskell for (priority order) Linux, Mac and Windows? I suspect in practice that the learning curves are pretty similar. I haven't done enough gtk2hs programming to be certain, but the samples look really pretty similar, and the programing style is a bit more imperative than many Haskell programmers really like in both cases. This is somewhat unavoidable given that the underlying toolkits are stateful object-oriented in design. I originally became involved with wxHaskell after doing some GTK GUIs (in Ocaml) for Windows at home, and being disappointed with the results (and licensing issues - see below) - in fact, this is how I first came to look at Haskell... I understand that the GTK situation on Windows is much better now, and that the GTK theme for Windows looks pretty close to native unless you look very closely. Mac is another story. AFAIK, the native GTK for Mac is still considered to be pretty unstable, and the default theme, while functional, looks like... GTK on Linux. wxWidgets (and wxHaskell) works very well on Mac - we have support for creating application bundles, and UIs look completely native. The same is true for Windows (I work about 90% on Windows with wxHaskell) wxHaskell works fine on Linux, but since it depends on GTK to render widgets, you'll have better performance and a smaller app footprint if you just use gtk2hs, to be honest. I guess the scorecard is therefore: - Ease of use - wxhaskell and gtk2hs about equal - Linux development - both work well, but gtk2hs scores slightly for performance and app footprint - Mac development - I definitely prefer wxHaskell. Native look is *vital* for acceptability on Mac - Windows development - both work well, but wxhaskell scores for performance and app footprint This means you will really need to weigh up the importance of portability. You don't mention documentation. I think the truth here is that neither gtk2hs nor wxHaskell is as well documented as it should be. There are certainly bugs and strange behaviour in wxHaskell that are not really documented well. I'm trying to change this (in particular, the lack of 'intermediate level' on wxHaskell information) in a new blog: http://wewantarock.wordpress.com I've noticed that wxhaskell is improving ease of install (I'm arch user) - http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/ We have put a lot of effort into making wxHaskell installation 'just work' on all platforms using Cabal recently. You can generally cabal install wx on any platform with a working (recent) wxWidgets installation and it works perfectly. and it may be that more devs are actively working on it atm. The number is small for both, I suspect. Almost everyone interested in maintaining this stuff has a day job and very little time to spare. Otoh, wx toolkit is often not very much likened (upon mentioning it), at least, on Linux platform where people recommend Qt and GTK+ (in general, I prefer GTK+ look over Qt which I do not consider as option). Why is it so? I think you need to look at the toolkits in respect of their origins - to some extent, language bindings exist slightly outside of these issues. On Linux, Qt was the choice of the KDE devs and GTK was developed as a part of the Gnome project. Back in the day (more than 10 years
Re: [wxhaskell-users] scrolledWindow
Hi Carlos, I assume from the posted code that what you really want is a StaticText widget with a scroll bar, and that you wish to 'force' the scroll bar to be present at all times (default behaviour of all widgets is that scroll bars appear only when they are needed). The code I have just tested to do this is: module Main where import Data.Bits import Graphics.UI.WXCore import Graphics.UI.WX main :: IO () main = start gui gui :: IO () gui = do f - frame [text := Frame] tcl - textCtrl f [text := This is an example of using an scroll bar with wxhaskell, it looks like don't work, so it's true?, style := wxTE_READONLY .|. wxHSCROLL .|. wxVSCROLL] set f [layout := fill $ widget tcl, clientSize := sz 200 200] return () Compared to your code, there are a few differences: It is sufficient, for simple cases, to simply set the wxHSCROLL and/or wxVSCROLL style on most windows if you want them to have permanent scroll bars. The wxTE_READONLY style replicates a StaticText (i.e. it sets text control to be read only) but with multiple lines. If you just want a single line, StaticText can be used instead. You should set a clientSize on the parent frame - if you do not, all widgets will be fittedt to their minimum possible size. The use of the fill combinator in the layout indicates that I want the TextCtrl to fit the whole of the allocated space. Hope this helps. Best regards Jeremy On Tue, 22 Dec 2009 20:41 -0400, carlos gomez carliro...@gmail.com wrote: Hi all I am trying to use scrolled windows with wxhaskell, but it doesn't work, Am I doing rightly? here is the code: module Gui where import Graphics.UI.WXCore import Graphics.UI.WX main :: IO () main = start gui gui :: IO () gui = do f - frame [text := Frame] pnl - scrolledWindow f [scrollRate := sz 20 20] sal - staticText pnl [text := This is an example of using an scroll bar with wxhaskell, it looks like don't work, so it's true?] set pnl [layout := widget sal] set f [layout := column 5 [widget pnl]] return () --carlos -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Changing a label depending on real world data
This sounds as though it may be 'homework', so hints only - your professor may well be reading in any case. Please see http://www.haskell.org/haskellwiki/Homework_help for more information. - To make something happen when you press a button, you need to add an event handler to the button. - One way of doing this in wxHaskell is to reference the event handler in the button attributes when you create it. - Your event handler needs to be able to identify the text label so that it can update it with new contents. Almost all functions in wxHaskell run in the IO monad, as you have observed. While you cannot 'take away' the IO, you can use values which are embedded with an IO type, for example, suppose you have a function (these are deliberately not quite the same as the 'real' wxHaskell functions, but should give you an idea): button :: Window - [Attribute] - IO Button frame :: Maybe Window - [Attribute] - IO Frame You can create a button in a frame with code something like the following: main () = do f - frame Nothing [Title My Frame] b - button f [Text Press Me, Event evtHandler] Notice that 'f' and 'b' give access to the frame and button information. They can do this because everything inside the 'do' is already in the IO monad. Now, in wxHaskell, the functions you will need to use are a little different, but the principles are very similar. In particular, there is a function, 'set' which may be helpful to you for some of the task. It is described in more detail at: http://wxhaskell.sourceforge.net/doc/Graphics-UI-WX-Attributes.html#v%3Aget I'll be happy to help with more specific questions, but in such case I think you should post what you have, and please bear in mind that I'll try to help you to find the correct answer yourself. Regards Jeremy On Mon, 30 Nov 2009 16:35 +0100, Henk-Jan van Tuyl hjgt...@chello.nl wrote: The solution is described in the page: http://www.haskell.org/haskellwiki/How_to_get_rid_of_IO You can find answers to many questions on the haskell site by typing keywords in the search field in the upper left corner; however, words of three letters or less are not indexed, so you will need Google for this. Use a search string like: IO site:haskell.org/haskellwiki to find pages about IO On Fri, 27 Nov 2009 20:08:44 +0100, mindfield...@yahoo.com wrote: Hi! I am new to haskell and I would like to do a seemingly very simple task in it(using wxhaskell). I would like to change properties based on data acquired from the outside world(i.e real time, typed text etc.). Probably it sounds stupid but I simpy cannot do this for days. I am very confused and it is annoying how a simple task as this is so difficult. Here are what I tried to do: Given a text label and a button, Evry time I press the button I'd like to read a system dependent time data(for example getCPUTtime) and write it back on the label. Given a text label and a timer. Evry time the timer condition fires i'd like to read a system dependent time data...(like above) and write it back I couldn't do any of these. Mostly because if acquire any data it comes in the form of IO sometype and set doesn't accept IO type. So I cannot set the new value. I coouldn't find any function in the wxhaskell documentation or tutorials that sets anything based on IO types. I also found a function unsafePerformIO which could convert an IO to a non IO type but I couldn't do it anyway. I almost did the second task but the label didn't refresh by itself. It only refreshed itself when I moved the window along or continually resized it. Can anybody help me? Ther must be some way to do these things. They cannot be impossible because they are very basic tasks. -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://functor.bamikanarie.com http://members.chello.nl/hjgtuyl/tourdemonad.html -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net
Re: [wxhaskell-users] Congrats and update request
Hi Conal, It's next on the list. Not much progress as yet, but I do understand the importance of this. Jeremy On Sun, 15 Nov 2009 18:05 -0800, Conal Elliott co...@conal.net wrote: Congratulations on the cabal-friendly new wxHaskell release! I will be thrilled to switch from gtk2hs back to wxHaskell for all of my GUI-ful projects as soon as the ghci-killing problem (crash on second 'start') is solved. Any progress? - Conal -- Jeremy O'Donoghue jeremy.odonog...@gmail.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxHaskell recabalised
Eric Y. Kow wrote: For the moment, you need both git and darcs. Until we hear back from the wxHaskell team, work on wxcore is taking place on github. If the team respond, I think we should start submitting patches so that the wxHaskell darcs repository catches up. Eric, I'll try to get this fixed and turned into darcs patches over the next couple of weeks. I agree that it's a very good idea, and although I haven't looked in detail, a quick glance suggests that Brian has done a very thorough job. ... better go off and learn how to use git, I suppose... Regards Jeremy -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] wxHaskell windows binary missing dependencies
Hi all, Very busy with work, so this will need to be a short answer. I agree with Claus that there is a potential problem here, although it is perhaps overstated slightly. However, as someone who works at a company which is very careful about IP issues, I understand the point. There are a couple of approaches we could take. One is to build wxWidgets as a completely static library, and statically link with wxC. If we do this, we could continue to deliver binaries built using the Microsoft toolchain, although wxHaskell binaries would then be enormous (and I should note that Microsoft now goes to some trouble to make it tedious to statically link the run-time). I think, therefore, that the best approach is probably to deliver our Windows binary builds based on the MinGW toolset. I've never actually used this on Windows (I'm very familiar with the GNU toolset on Linux and other unices), and I suspect that this may be the case for the other developers. This means a transition for me, which I'm quite happy to make in theory, but which will probably take some time for to complete in practice. A handy benefit of using MinGW is that we would no longer suffer from 'Manifest hell' - the exciting new scenario Microsoft has produced to replace DLL hell... One thing to note is that I would like to be very certain that any change to the binary distribution model does not introduce a dependency on cygwin.dll for wxHaskell applications on Windows, since this would effectively require all apps based on our binaries to be GPL licensed, which I find unacceptable. Regards Jeremy Eric Kow wrote: Hi Shelarcy, Is this something you know what to do with? Perhaps the non-VS build should be the default? Thanks! On Mon, Jun 29, 2009 at 09:35:33 +0100, Claus Reinke wrote: Claus Reinke claus.rei...@talk21.com wrote in message news:h103ak$ae...@ger.gmane.org... I tried updating some old wxHaskell code to work with recent ghc/wxHaskell. On a windows xp system, I have installed the ghc-6.10.3 and wxhaskell-bin-msw2.8.10-ghc6.10.3-0.11.1.2-0 binary installers. After compiling my code, I can't run the executables, due to missing dependencies (copied from event viewer): Dependent Assembly Microsoft.VC90.CRT could not be found and Last Error was The referenced assembly is not installed on your system. ... This has come up before, and the advice has been to install extra bits of Visual Studio. However, the latest recommended version of these files clearly states that they may only be used with a valid Visual Studio license: http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2displaylang=en So that is a no-go. As I understand the VS deployment models, VS distinguishes between components that may be redistributed and those that may not. wxHaskell should only depend on the former, and should include them in the binary installer, because the kind person building wxHaskell via VS is the only one who can include those redistributable dependencies. -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Moderation
Hi all, Regrettably, we had to turn on moderation for all new subscribers about a year ago after list spamming started to happen frequently. Our policy is that as soon as it is clear that a mail is coming from someone with an issue appropriate to this list, we turn off moderation. I put my hands up and apologize for forgetting to do this in your case, Daniel. Regards Jeremy -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] General questions
2009/4/30 Daniel Carrera daniel.carr...@theingots.org: Oh, can one use wxGlade with wxHaskell? I'm thinking of the XRC files (XML description of the UI). Personally I'm a big fan of using XML to describe GUIs. You can use XRC files with wxHaskell, although I should note that they are not currently type-safe (so you will get a crash if you load a resource and treat it as the wrong type of object (e.g. load a button into a list box). Someone (Mads, I think) showed a proof of concept for type safety on XRC, but I haven't had the time to implement it fully so far. I use something called wxFormBuilder on Windows to create my XRC files, which seems a little more complete than wxGlade, although both will do the job. There's a sample provided with wxHaskell which shows how to use XRC files, should you decide to go this way. Jeremy -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] General questions
2009/4/30 Daniel Carrera daniel.carr...@theingots.org: Btw, can you compile and deploy a wxHaskell program using only FOSS? For example, can you use mingw an still get the one DLL? Is it hard to get the one DLL? I've never tried - I use Visual Studio to build wxWidgets and wxC - but it should work, as more users seem to use FOSS build chains than Microsoft, and all of the Unix platforms use exclusively FOSS tools to build. The wxWidgets build system is very configurable, and most build options seem to exist on all supported platforms. In general, I've found that if wxWidgets team claim something works, it works well (i.e. they do their QA!) There are people who use mingw to build the wxC component of wxHaskell. The single DLL aspect may require some minor fiddling with the wxC makefiles, but I suspect it should work once you've found the correct set of options. Oh, I just thought of a new question: WebKit. I know that there is a project to port WebKit to wxWidgets. Can wxHaskell use wxWebKit? That would be uber-cool? (I don't know if I can use it for anything, but I can say it would be cool). In principle, once it is in wxWidgets, it's pretty easy (trivial for a reasonably experienced C++ programmer) to wrap any new components - that's to say, once you have built wxWebKit, making it accessible from wxHaskell is easy (if tedious - for large/complex APIs). A quick glance at the wxWebKit website shows that there are a very large number of dependencies for building the component, so it might be tricky to incorporate into the standard wxHaskell distribution (I suspect many people would be put off by having to compile 9 significant Open Source libraries to get wxWidgets to build). Jeremy -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Dialog editor XRC - Files
Hi Günther, I used wxFormBuilder to create the sample code demonstrating XRC support, but you should be able to use anything which generates the XML representation of XRC. Some tools (e.g. wxFormBuilder), generate C++ by default, but can be configured to generate XML output, so you may need to change the default configuration. The DialogBlocks website feature list implies that it should work, but I doubt that anyone has tried it. You may want to try wxFormBuilder if you don't already have a copy of DialogBlocks - it's free and I found it to be pretty good. Regards Jeremy On 25 Dec 2008, at 18:22, Günther Schmidt wrote: Hi, can I use DialogBlocks to design the UI, safe it to XML, and then import it into Haskell? Günther -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users -- ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] ANN: wxHaskell 0.10.3
The wxHaskell development team is pleased to announce the release of wxHaskell 0.10.3, a Haskell binding for the wxWidgets GUI library. The Haskell support is built on a reasonably complete C language binding, which could be used as the basis for wxWidgets support on other languages/platforms which do not have easy mechanisms for linking with C++ code. The feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a number of additional bugfixes. This is the first full release since June 2005, and is the result of a great deal of work by a new team of contributors. Highlights of 0.10.3 include: - Support for Unicode builds of wxWidgets - Support for additional widgets including calendar, toolbar divider, styled text control (wxScintilla), media control - Support for clipboard, drag and drop - Support for 64bit (Linux) targets - Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if you compile from source). wxWidgets 2.8 is not yet supported - Support for building with GHC 6.6.x and 6.8.x - Parts of wxHaskell are now built with Cabal - New test cases - Removed support GHC version 6.4 - Profiling support - Smaller generated binary sizes (using --split-objs) Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Debian - Windows - OS X (Intel and PPC platforms) - Source code .tar.gz and .zip - Documentation (cross-platform) The wxHaskell libraries (wxcore and wx) are also available from Hackage (http://hackage.haskell.org). About wxHaskell --- wxHaskell is a Haskell binding to the wxWidgets GUI library for recent versions of the Glasgow Haskell Compiler. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer ([EMAIL PROTECTED] and user (wxhaskell-users@lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. wxHaskell was originally created by Daan Leijen. The contributors to this new release include: - Eric Kow - shelarcy - Arie Middelkoop - Mads Lindstroem - Jeremy O'Donoghue - Lennart Augustson The C language binding for wxHaskell was derived from an original C language binding created for the Eiffel programming language by the ELJ project (http://elj.sourceforge.net). -- Jeremy O'Donoghue [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] ANN: wxHaskell 0.10.3
The wxHaskell development team is pleased to announce the release of wxHaskell 0.10.3, a Haskell binding for the wxWidgets GUI library. The Haskell support is built on a reasonably complete C language binding, which could be used as the basis for wxWidgets support on other languages/platforms which do not have easy mechanisms for linking with C++ code. The feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a number of additional bugfixes. This is the first full release since June 2005, and is the result of a great deal of work by a new team of contributors. Highlights of 0.10.3 include: - Support for Unicode builds of wxWidgets - Support for additional widgets including calendar, toolbar divider, styled text control (wxScintilla), media control - Support for clipboard, drag and drop - Support for 64bit (Linux) targets - Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if you compile from source). wxWidgets 2.8 is not yet supported - Support for building with GHC 6.6.x and 6.8.x - Parts of wxHaskell are now built with Cabal - New test cases - Removed support GHC version 6.4 - Profiling support - Smaller generated binary sizes (using --split-objs) Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Debian - Windows - OS X (Intel and PPC platforms) - Source code .tar.gz and .zip - Documentation (cross-platform) The wxHaskell libraries (wxcore and wx) are also available from Hackage (http://hackage.haskell.org). About wxHaskell --- wxHaskell is a Haskell binding to the wxWidgets GUI library for recent versions of the Glasgow Haskell Compiler. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer ([EMAIL PROTECTED] and user (wxhaskell-users@lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. wxHaskell was originally created by Daan Leijen. The contributors to this new release include: - Eric Kow - shelarcy - Arie Middelkoop - Mads Lindstroem - Jeremy O'Donoghue - Lennart Augustson The C language binding for wxHaskell was derived from an original C language binding created for the Eiffel programming language by the ELJ project (http://elj.sourceforge.net). - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] ANNOUNCE: wxHaskell 0.10.3 rc1
We are pleased to announce the first release candidate of wxHaskell 0.10.3. This is the first update with binary packages available since June 2005, and is the result of a great deal of work by a new team of contributors. We are hoping to make a full release shortly, and issues and bug reports either through the wxHaskell user mailing list ([EMAIL PROTECTED]) or via the Sourceforge bug tracker (http://sourceforge.net/tracker/?group_id=73133atid=536845). Highlights of 0.10.3 rc1 include: - Support for Unicode builds of wxWidgets - Support for additional widgets including calendar, toolbar divider, styled text control (wxScintilla), media control - Support for clipboard, drag and drop - Support for 64bit (Linux) targets - Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 retained if you compile from source) - Support for building with GHC 6.6.x and 6.8.x - Parts of wxHaskell are now built with Cabal - New test cases - Removed support GHC version 6.4 - Profiling support - Smaller generated binary sizes (using --split-objs) Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Debian - Windows - OS X (Intel and PPC platforms) - Source code .tar.gz and .zip - Documentation (cross-platform) About wxHaskell wxHaskell is a Haskell binding to the wxWidgets GUI library. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer ([EMAIL PROTECTED] and user (wxhaskell-users@lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. wxHaskell was originally created by Daan Leijen. The contributors to this new release include: - Eric Kow - shelarcy - Arie Middelkoop - Mads Lindstroem - Jeremy O'Donoghue - Lennart Augustson -- Jeremy O'Donoghue [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Is with-* reasonable for supporting wxWidgets contrib libraries? (Was: pinging wxhaskell...
Hi Shelarcy, On 20/08/07, shelarcy [EMAIL PROTECTED] wrote: On Tue, 21 Aug 2007 00:42:26 +0900, Jeremy O'Donoghue [EMAIL PROTECTED] wrote: This really only works as an option if we decide that users must build wxWidgets from source *before* they can build wxHaskell. Really? I think that nowadays wxWidgets packager worried about wxPython. And wxPython depends on contribs. http://www.wxpython.org/builddoc.php [snip other examples of bindings depending on contrib] So I want to know about wxWidgets package's condition. It's likely to be irritating to Linux users who are used to apt-get install wxWidgets as their usual approach to installing libraries. Is this right? Any packages system's wxWidgets doesn't have contrib? Or any package system doesn't choose version that supports contrib? So far as I can tell, Debian supports contrib on wxWidgets 2.4 but not 2.6 (and doesn't yet have a wxWidgets 2.8 package), so I do think this is an issue, e.g.: http://packages.debian.org/unstable/libdevel/libwxgtk2.4-contrib-dev http://packages.debian.org/unstable/libdevel/libwxgtk2.6-dev However, I'm convinced by your argument that the contrib components are useful, and that we should depend on them - I think that all it means is that we need to provide binaries for wxWidgets for those who have neither the time nor inclination to build themselves. Therefore, I'll complete the updates to the build system on the basis that contrib components (and OpenGL support) have been compiled into wxWidgets. Regards Jeremy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] process crashes on second 'start'
Hi Conal, On 07/12/06, Conal Elliott [EMAIL PROTECTED] wrote: I submitted this bug report at the sourceforge project. Is this a known problem? Any work-arounds? Running two 'start'ed actions kills the process under ghc and ghci. Example: import Graphics.UI.WX main = io io where io = start (frame [] return ()) I'm not sure whether anyone has tried this before, but I would fully expect it not to work for several reasons: * I'm pretty sure that wxHaskell only expects to see a single instance of a wxWidgets wxApp (which is what start boils down to creating, among other things). * In fact, I think the whole point about wxApp is that it encapsulates a process with an event loop for handling GUI events, so the limitation is probably with wxWidgets itself (as it happens, I'm sceptical that what you are trying would work on any common GUI framework, for much the same reason) Work-around will depend on what you are trying to do. You can certainly have multiple top level frames, but they will share the same event loop. This is, by some margin, the easiest approach. If you genuinely want two communicating processes, you most likely need to create two separate executables - let's call them A and B. As part of start-up of A, it spawns B as a forked process, and A abd B communicate via pipes, IP sockets or some other appropriate mechanism. Another wrinkle to watch out for (again, common to most GUIs) is that only one thread should perform all event handling (in practice, this usually ends up being simplest by running all GUI activities in a single thread). Windows is expecially strict about this - X is slightly more permissive, but you are much better off following the 'one GUI thread' rule. Assuming that you have a multi-threaded application, typical design is for GUI to signal other 'worker' threads (which signal back). Again, details are likely to be very application dependent. One final, somewhat unrelated issue: if you are planning to use wxWidgets with GHCi, it is worth knowing that you can actually only issue one start command in a given GHCi session. This is an underlying wxWidgets issue (use of static destructors in C++ code, I believe) which means that wxWidgets can only be restarted by unloading and reloading the wxWidgets DLL. Since GHCi isn't capable of doing this, you basically need to quit and restart a new session. There *is* a workaround for this: use wxWidgets 2.4.2 or earlier, which have a different allocation/deallocation strategy. This is why we continue to support wxWidgets 2.4.2. Regards Jeremy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
