Re: [wxhaskell-users] preview: HCPN editing and simulation

[Claus R. <cla...@ta...>]

>Thanks, I'll add you to the applications list :-)

sure, no problem.
  
>What platform do you use? windows? 

currently, I can only test on windows, but I don't like platform-specific
apps and libs, especially in Haskell!-) so I'd like to avoid any traps (such
as specialist widgets not working consistently, or filepaths, or line 
separators, or..).

>You should initialize the frame with [visible := False]  and set it
>to True when all the layout and parameters are set.

ah, silly me, I should have thought of that myself. thanks, that works.
(do any of the samples use this? perhaps an example in the docs?)

>I think you can call "windowRaise" to raise a frame to the top of the hierarchy.
>(hmm, maybe I should do this by default..)

that doesn't always seem to work, though (and it would seem a good default,
unless it also grabs the input focus, as windows apps tend to do so annoyingly).

>>Graphics.UI.WXCore.Process is useful, at least until System.Process
>I'll try it out on unix and macosx. It works for sure on windows.

thanks.

>(beware, there seems to be a bug where output is lost when the
>process is terminated. (I haven't been able to reproduce this though))

hmm, I noticed that since I started using this, my app has become somewhat
unstable - very easy to crash if processes or input/output are terminated in
the wrong order (whatever the right order might be), not nice at all. is that
something I should take care of as an application programmer, or should
the library isolate the main app from failures in the sub-process? in a low-
level language like C, I'd have to do it, but in Haskell it might be difficult?

>>ghc is generally very forgiving wrt filepath conventions on windows
>>(unix-like paths are also accepted, which eases portability); 
>>unfortunately wxHaskell's file dialogs are not that flexible.
>Thanks for pointing this out. I was already considering some conversion
>functions -- maybe we should use wxWidgets' file classes but they seem
>a bit inconvenient.

could one borrow ghc's filepath converters?

>You are right about the "elementary" stuff. However, finding good
>abstractions that work for a wide range of applications is very hard
>I think -- not in the least because we (I?) have little experience with 
>such applications.

my experience is quite dated, so I'm more or less starting anew. so far,
it has at least been possible to define most of the things I need, which
is an advantage of a low-level lib (some high-level libs make your life
painful by offering the wrong abstractions and no access to the bottom
layer). Having complex text-entry widgets that can only be used 
separately but not in a drawing frame is one example (should I recode
the whole thing in terms of drawText and on key, and thus duplicate 
code?). The lack of antialiasing indicates that this whole area is very 
low priority in wxwidgets, as the various add-on libs demonstrate.

>Thanks for sharing your experiences,

thanks for trying to end the haskell gui lib up and down with 
something less artistic but more practical and long-term. overall,
it is fun to write haskell apps with graphics - wonder how long it
will take the haskell masses to realise that the same concise and
elegant programming style they are accustomed to from text apps
also helps with games, etc. (many still seem to be in the old rut
of "haskell doesn't need guis (because we can't have them)";-).

Cheers,
Claus