Re: [wxhaskell-users] some small items..

[Daan L. <daa...@xs...>]

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.