From: Daan L. <daa...@xs...> - 2004-03-25 10:32:32
|
Hi Ian, > I've written a simple application using wxHaskell, mainly to see how the > library works. It's at http://urchin.earth.li/~ian/mamot/ Ha, I have another screenshot :-) > I'm not sure how to get it to both display correctly and not flicker. > I've tried various combinations of dcBuffer, windowFreeze/windowThaw, > fullRepaintOnResize := False, but don't seem to have hit upon the magic > combination yet? I want to document this soon, as it is rather obscurely done in wxWidgets. I'll look into this issue in some more detail, maybe I can come up with a nice abstraction. For now, you need to set "fullRepaintOnResize" indeed to "False", but you need to do that for both the frame and panel (and drawing areas?). Furthermore, it could help to set the "wxCLIP_CHILDREN" flag. Try: f <- frame [fullRepaintOnResize := False, style :~ \st -> st .+. wxCLIP_CHILDREN] Look also to the "imageviewer" sample. > I haven't worked out yet what "set p [defaultButton := ok]" does other > than set focus. To actually make a default button I need to do > "buttonSetDefault ok". Strange -- I'll try to fix this. (right now, the method "panelSetDefaultItem" is used instead of "buttonSetDefault") > m_metaDown seems to reflect whether numlock is on or not. As "on click" > checks that none of the modifiers are down this is quite annoying. Thanks for mentioning this, I'll check it on the Mac and if the behaviour is the same, I'll remove that check from "on click". > The scrolled window seems to like increasing its virtual size when > the window gets bigger unless I explicitly keep resetting it. Is there a > nice way to get the behaviour I want? You have to be more specific about the behaviour you want -- should the virtual size stay the same when the window is resized? > I have to give the "wx-config --gl-libs" options as well as the "--libs" > ones when linking. Otherwise I get things like This is bug is fixed now -- cvs head lets you give the "--with-opengl" flag to configure. > The program is 7M, or 3M after stripping. Perhaps this could be reduced > if -split-objs was used when compiling wxHaskell? Yes, I think so. It might even greatly reduce the program size but I haven't tried so yet. For now, I use "upx" on windows to pack the ".dll" (== ".so") file which reduces the 3M to about 600kb with microsoft visual c++. > Finally, when my program starts up it decides to be as small as > possible. Again I haven't found the right way of convincing it to start > off at some sensible size. A way around this is to give a minimal size (using "minsize" in the layout) However, the proper way to do this is of course to specify an "initial size", but I don't know yet how to do that -- but I'll look into it. Thanks for your comments, All the best, Daan. |