From: Claus R. <cla...@ta...> - 2004-07-30 21:45:01
|
not yet ready for release (hopefully by September, for IFL;-), but for the curious, in the spirit of sharing wxHaskell apps on this list, and by the way of a thank you to Daan: there are (and have been for a while) frequently updated snapshots of my Haskell-Coloured Petri net tools (editor/simulator) as well as a couple of screenshots at http://www.cs.kent.ac.uk/~cr3/HCPN/ If you try them, please let me know whether they work on your platform (and whether you can figure out how:-). There are links to more Petri net info, if you haven't come across them, also a link to an older IFL paper of mine outlining the embedding of HCPN in Haskell (yes, the nets are implemented as an embedded DSL). Apart from the tools being permanently under (re-)construction, and functionality being incomplete, please mind the warning about the quality of the source code (think "hello world" grown into an application while learning the library) - until further notice, the focus continues to be on functional modifications/extensions rather than structural consolidation, so the code isn't a useful learning aid (unless you're looking for bad examples?-). That's also the reason why I'm not yet ready to say which parts, if any, might be useful for polishing and inclusion in wx, but I can mention a few trouble-spots: - I still haven't figured out how to start a frame without having it flicker through more than one size - annoying (I thought that was meant to be fixed be the magical creation attributes, so perhaps I'm just using things wrongly?). - every now and then (especially under ghci?), my frames start at the bottom of the window stack - very annoying. - Graphics.UI.WXCore.Process is useful, at least until System.Process becomes more widely available, but dealing with buffering is a bit cumbersome (I use it to call ghci, to compile, load, and run the code I generate from the nets, and I have to interpret ghci's output..). Could someone please confirm that this works on other platforms? - 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. - since wxWidgets is more than just portable GUI: is there some way to get platform-specific filepath separators and line endings, or even better to work with such things in a portable way? Cheers, Claus PS (thanks to Arjan, who let me look at his belief network editor when I started with wxHaskell; in his defense, I should hasten to add that I ended up not copying any of his code, but it was helpful to see that I wasn't entirely on the wrong track, and that one does have to code lots of elementary stuff when using wxHaskell for drawing tools) |
From: Daan L. <daa...@xs...> - 2004-07-31 10:10:22
|
Dear Claus, Claus Reinke wrote: >not yet ready for release (hopefully by September, for IFL;-), but for the >curious, in the spirit of sharing wxHaskell apps on this list, and by the >way of a thank you to Daan: there are (and have been for a while) >frequently updated snapshots of my Haskell-Coloured Petri net tools >(editor/simulator) as well as a couple of screenshots at > > http://www.cs.kent.ac.uk/~cr3/HCPN/ > > Thanks, I'll add you to the applications list :-) >If you try them, please let me know whether they work on your platform > > What platform do you use? windows? > <>- I still haven't figured out how to start a frame without having it > flicker > through more than one size - annoying (I thought that was meant to > be fixed be the magical creation attributes, so perhaps I'm just using > things wrongly?). You should initialize the frame with [visible := False] and set it to True when all the layout and parameters are set. > <>- every now and then (especially under ghci?), my frames start at the > bottom of the window stack - very annoying. I think you can call "windowRaise" to raise a frame to the top of the hierarchy. (hmm, maybe I should do this by default..) > <>- Graphics.UI.WXCore.Process is useful, at least until System.Process > becomes more widely available, but dealing with buffering is a bit > cumbersome (I use it to call ghci, to compile, load, and run the code > I generate from the nets, and I have to interpret ghci's output..). > Could someone please confirm that this works on other platforms? I'll try it out on unix and macosx. It works for sure on windows. (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)) > <>- 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. > <>PS > (thanks to Arjan, who let me look at his belief network editor when I > started with wxHaskell; in his defense, I should hasten to add that I > ended up not copying any of his code, but it was helpful to see that > I wasn't entirely on the wrong track, and that one does have to code > lots of elementary stuff when using wxHaskell for drawing tools) Maybe Arjan can make the code publicly available on the web? 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. Thanks for sharing your experiences, All the best, Daan. |
From: Claus R. <cla...@ta...> - 2004-07-31 13:10:46
|
>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 |
From: Daan L. <da...@cs...> - 2004-08-03 09:12:21
|
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 on windowsXP/2000) > 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. -- Daan 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 > > > > > ------------------------------------------------------- > 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. www.ostg.com > _______________________________________________ > wxhaskell-users mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > > |
From: Arie M. <ami...@cs...> - 2004-08-03 10:12:00
|
> >>(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)) I also noticed this in the wxHaskell application i'm building. It seams to be related to the input buffering as I use very small buffers and never lose more output than a single buffer. Arie |
From: Daan L. <da...@cs...> - 2004-08-03 15:45:40
|
Claus Reinke wrote: > 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?). Ha, we had the same problem. However, it seems that you can just create a text control and position it yourself (using "position") on a canvas -- et voila, inline editing. However, you probably need to smart with visibility and focus... for details, read the c++ source files in "generic/grid.cpp" of wxWidgets :-) -- Daan. |