On Thu, 21 Jan 2010 12:32:16 +0000 >>>>>> "Jeremy" == "Jeremy O'Donoghue" wrote:
Jeremy> I have just updated the wiki text here. Thanks for the Jeremy> information. Thanks a lot. Now it's much more encouraging for someone considering to use wxhaskell. Jeremy> I need to look into this a bit further. OK. Jeremy> I expect that this investigation will turn into a blog article, Jeremy> as it really involves tracing the lifecycle of a control. That would be very good since the referenced article makes some strong statements as: "...wxHaskell in that sense is worse than any Java Swing/AWT application since even there you don’t have to worry about freeing objects." Jeremy> Almost all of the core widgets are wrapped, although some of Jeremy> the more complex ones are not. Much of the non-essential and Jeremy> non-GUI related functionality does not get much attention Jeremy> because Haskell generally already has very satisfactory (and Jeremy> idiomatic) libraries for these.. Nice to hear...Maybe it would be good to have some kind of 'status' page generated showing what is remaining to be bound and what is covered to help potential contributors to know where/how to help? Jeremy> To be honest, it will probably happen (almost immediately) Jeremy> when Haskell Platform is released with 6.12.x - I really Jeremy> don't have the time Jeremy> to compile GHC and the minimum Jeremy> set of libraries myself. It may even work out of the box Jeremy> (at most with minimal library dependency changes). Thank you. Now it's clear that wxhaskell is following HP. Jeremy> From what I can see of wxWidgets 2.9.x, it's pretty Jeremy> evolutionary without radical changes. We already use the Jeremy> Unicode build of wxWidgets, and pervasive Unicode is one Jeremy> of the headline features for 2.9.x/3.0 OK. I saw one thread in wx mailing list (http://tinyurl.com/yandrh3) from where I've concluded that VZ has on mind something more drastic than what 3.0 brings up. Jeremy> I believe any tools should generate the same XRC. I found Jeremy> wxFormBuilder to be fine, but DialogBlocks is probably a Jeremy> good alternative. Thanks for the tips. Jeremy> One issue for me is that XRC really violates type-safety in Jeremy> wxHaskell. Hmm...afaics, looking at gtk2hs glade-example, I've feeling that type-safety works there: ************* code-here********************* -- load up the glade file dialogXmlM <- xmlNew "simple.glade" let dialogXml = case dialogXmlM of (Just dialogXml) -> dialogXml Nothing -> error "can't find the glade file \"simple.glade\" \ \in the current directory" -- get a handle on a couple widgets from the glade file window <- xmlGetWidget dialogXml castToWindow "window1" button <- xmlGetWidget dialogXml castToButton "button1" [...] ************* code-here **************************************** Is it possible to achieve it with XRC? Jeremy> I think a better way forward in the long run will be Jeremy> to have a tool which generates code from XRC, rather than Jeremy> loading the resources using the resource subsystem. Huh, that would be terrific, but it should (probably) come from the wxhaskell team adding support to some GUI tool, do you agree? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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 companies. http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
