Claus Reinke wrote:
>>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..).
I know the desire :-) I think that when you work with wxHaskell, you
will come real close to being portable -- but in my experience it
normally still requires *some* work to get a decent version on another
platform. The amount of work does depend on the application of course,
simple ones tend to work immediately, larger ones (like netEdit) require
some "tuning", and/or makefile/configure changes. I have some hope that,
in time, useful portability abstractions will result. For example, the
layout of standard buttons like "ok/don't save/cancel" that tend to
be different on different platforms.
I guess that the only areas in wxHaskell that really need more work with
respect to portability are: file names, "application settings" and
resource management. (ie. icons vs. bitmaps vs. png)
>>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).
I'll add it. The input focus is only grabbed if "focusOn" is also called.
>>(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?
I hope that this is all a bug on my side -- In principle, I want the
interface to be fully robust. The programmer should not have to worry
about broken pipes and terminated processes.
>>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?
I never knew about this. How are these called? in which library?
> code?). The lack of antialiasing indicates that this whole area is very
> low priority in wxwidgets, as the various add-on libs demonstrate.
Hmm, that is not entirely true: the windows GDI does not support
anti-aliasing. On platforms like GTK and Mac, it is enabled by default.
Fortunately, GDI+ supports anti-aliasing so we will probably see
this enabled on windows in the future too. (GDI+ is only supported
> thanks for trying to end the haskell gui lib up and down with
> something less artistic but more practical and long-term.
Thanks. I think with WASH and HaskellDB/HsSql, Haskell becomes are
viable alternative to many other languages in terms of being useful
in practical situations. Hopefully, this also leads to people being
seduced into pure functional programming via some practical library,
after which they discover that programming *algorithms* in a pure
functional way is much nicer than in, say, php.
> 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)";-).
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. http://www.ostg.com
> wxhaskell-users mailing list