On 20 January 2010 19:30, Gour <email@example.com>
On Wed, 20 Jan 2010 18:35:08 +0000
>>>>>> "Jeremy" == <jeremy.odonoghue-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Please, for the sake of wxhaskell, remove/explain/resolve this issue.
I have just updated the wiki text here. Thanks for the information.
Jeremy> > Another concern is question of memory management touched upon
Jeremy> > in the following article:
Jeremy> > http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/
What about this issue?
I need to look into this a bit further.
The wxHaskell documentation (Graphics.UI.WXCore.WxcOjbect) says "Objects are not automatically deleted. Normally you can use a delete function like windowDelete to delete an object. However, almost all objects in the wxWindows library are automatically deleted by the library. The only objects that should be treated with acre are resources [such] as bitmaps, fonts and brushes" (the latter are reference counted objects in wxWidgets).
I expect that this investigation will turn into a blog article, as it really involves tracing the lifecycle of a control.
How much (in %) of wxwidgets is bound in wxhaskell?
Almost all of the core widgets are wrapped, although some of the more complex ones are not. Much of the non-essential and non-GUI related functionality does not get much attention because Haskell generally already has very satisfactory (and idiomatic) libraries for these..
Jeremy> We have put a lot of effort into making wxHaskell
Jeremy> installation 'just work' on all platforms using Cabal
Jeremy> recently. You can generally cabal install wx on any
Jeremy> platform with a working (recent) wxWidgets
Jeremy> installation and it works perfectly.
What is the plan for 6.12.1 support?
To be honest, it will probably happen (almost immediately) when Haskell Platform is released with 6.12.x - I really don't have the time to compile GHC and the minimum set of libraries myself. It may even work out of the box (at most with minimal library dependency changes).
Is wx-3.0 part of wxTNG or the latter is quite different concept not
coming into existance soon?
From what I can see of wxWidgets 2.9.x, it's pretty evolutionary without radical changes. We already use the Unicode build of wxWidgets, and pervasive Unicode is one of the headline features for 2.9.x/3.0
May I just ask, if it is relevant for you, do you use some GUI
I'm thinking about DialogBlocks (looks as better option for wxhaskell
considering one needs only XRC support) vs. free wxFormBuilder,
i.e. is DialogBlock justifies to be supported over free tool to be
used for wxhaskell?
I believe any tools should generate the same XRC. I found wxFormBuilder to be fine, but DialogBlocks is probably a good alternative.
One issue for me is that XRC really violates type-safety in wxHaskell. I think a better way forward in the long run will be to have a tool which generates code from XRC, rather than loading the resources using the resource subsystem.