From: Claus R. <cla...@ta...> - 2004-06-16 15:20:04
|
continuing my wxhaskell experience, I have to say the library (wxwidgets) is lower level than I had expected. Worse, the level is not consistent, so there are predefined high-level gadgets for some uses while even lower-level support for other uses is incomplete. And sometimes, there are helper functions which, when used, can lead into traps in which intended tasks seem impossible or tricky, while direct use of base-level functionality avoids these difficulties. Now, the obvious question is: is this just my impression?-) If not, it might be useful to try and hunt down some of these odd corners that most of us learn to program around, and instead let Daan know about them so that he can try to improve wxhaskell's design before the 1.0 release (to the extent permitted by wxwidget's design). Here are some small examples: - event filters like click, drag, etc. only propagate part of the even info. superficially, that makes simple uses look simple, but it means that one is soon forced to abandon all of this in favour of keyboard, mouse, etc., why not pass on the full event? it is trivial to extract just the position, if that's sufficient for the task at hand. - on click seems to react on MouseDown already. - on drag would be more useful if it supplied the Vector of movement relative to the last handler call, instead of (or in addition to) the current Point. as it stands, that functionality is bound to be reimplemented by every user. - instead of explaining the usage pattern for extending handlers, why not capture it in a set of functions, like this one: addHandler1 handler previous x = do {handler x; previous x} .. ,on drag := dragHandler vContext ,on mouse :~ addHandler1 (recordMouseDownPos vContext) ,on mouse :~ addHandler1 (selectionHandler vContext) .. - why, oh why, are there types with Show instances that have no Read instances (Point, Vector, ..)? makes it needlessly hard to save/restore GUI state. - why is Vector scaling limited to Int, while Vector length is reported in Double? that means I'm forced to de- and re-construct my Vectors and provide my own Double-scaling. - less small, but would be useful: support for polar coordinates is missing I'm sure there are more, and rumours have it that 1.0 is close, so it would be nice if you experienced wxhaskell users could help to improve the experience for future users, by collecting the little niggles you've come accross. We're all thankful to Daan for providing this binding, but he can't practice-test all parts of it himself, after all. Cheers, Claus |
From: Daan L. <daa...@xs...> - 2004-06-21 10:15:32
|
Hi Claus, Sorry for the late reply. On Wed, 16 Jun 2004 16:05:51 +0100, Claus Reinke <cla...@ta...> wrote: > continuing my wxhaskell experience, I have to say the library (wxwidgets) is lower > level than I had expected. Worse, the level is not consistent, so there are predefined > high-level gadgets for some uses while even lower-level support for other uses is > incomplete. And sometimes, there are helper functions which, when used, can > lead into traps in which intended tasks seem impossible or tricky, while direct use > of base-level functionality avoids these difficulties. > > Now, the obvious question is: is this just my impression?-) No. I think a lot of critique is correct, although not directly due to a failure of library design, but more due to lack of development effort. Here is the current situation: *WXCore: base-level functionality. I will maintain this, try to keep it free of bugs, and hopefully extend this to fully encompass wxWidgets. *WX: a possible abstraction layer for WXCore. I created this as a minimal abstraction over WXCore. However, I also see this as a framework where *other people* can add more abstractions or improve on my design. I don't think it will every be "finished", as there are always more features that someone wants. Furthermore, my main objective is to keep WXCore up-to-date and bugfree, not to create a new functional GUI library design (as that is a full time job and not my personal research area). It is thus my hope that others will create new abstractions when writing applications and contribute them back to WX. This is already happening with NetEdit (thanks Arjan!). > - event filters like click, drag, etc. only propagate part of the even info. > superficially, that makes simple uses look simple, but it means that one > is soon forced to abandon all of this in favour of keyboard, mouse, etc., Yes, for "real" applications, on probably wants to use "keyboard" anyway. The filters are more for, indeed, simple applications. > - on drag would be more useful if it supplied the Vector of movement > relative to the last handler call, instead of (or in addition to) the > current Point. as it stands, that functionality is bound to be > reimplemented by every user. No, I don't think so. It would be nice though to have another abstraction that does exactly this, for example "dragRelative" or something. > - instead of explaining the usage pattern for extending handlers, why not > capture it in a set of functions, like this one: > > addHandler1 handler previous x = do {handler x; previous x} > > .. > ,on drag := dragHandler vContext > ,on mouse :~ addHandler1 (recordMouseDownPos vContext) > ,on mouse :~ addHandler1 (selectionHandler vContext) > .. That is a good idea. One problem might be that we need addHandler1, addHandler2 etc. Maybe we should add another event transformer. Something like "add mouse := ..." > - why, oh why, are there types with Show instances that have no Read > instances (Point, Vector, ..)? makes it needlessly hard to save/restore > GUI state. I'll add this in the next release. > - why is Vector scaling limited to Int, while Vector length is reported in > Double? that means I'm forced to de- and re-construct my Vectors and > provide my own Double-scaling. I noticed this too, and I'll fix it in the next release. However, I guess that the Vector/Point/Rect library will never be really good for arbitrary manipulations, as they are defined on "Int" coordinates (as that is what wxWidgets uses). > I'm sure there are more, and rumours have it that 1.0 is close, so it would > be nice if you experienced wxhaskell users could help to improve the > experience for future users, by collecting the little niggles you've come > accross. We're all thankful to Daan for providing this binding, but he > can't practice-test all parts of it himself, after all. Yes! please send comments and, even better, improved/extended code. I am happy to include it and/or give people write access to improve the library directly. I am able to maintain it "as is", but there is not much time for me to improve it much. All the best, Daan. |