wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] Announce: wxHaskell 0.8

[Daan L. <da...@cs...>]

Announcement: wxHaskell version 0.8
----------------------------------------------------------------------

<http://wxhaskell.sourceforge.net>

I am pleased to announce a new release of wxHaskell. The library is
now 1 year old, and more than 4000 downloads further.

This new release has support for the powerful wxGrid control, managed
resources, and system colors. Futhermore, all object references are
now checked, raising a Haskell exception if they are not valid. The
MacOS X version is much more stable now than the previous release.

Binary installers are provided for MacOS X, Linux (RPM), and Windows.

The webpage has a screenshot of a heap profile viewer for GHC written
in wxHaskell by Wei Tan. There is also a *draft* version of an article
about the design of wxHaskell. I have to submit a final version this
Friday and any comments are very welcome.

All the best,
  Daan Leijen.


----------------------------------------------------------------------
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.

wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.

And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.


----------------------------------------------------------------------
Version 0.8
-----------
Non backward compatible changes:
- Added wildcards argument to the "fileSaveDialog" function.
- Removed the call to "buttonSetDefault" in the "defaultButton"
   property since GTK seems to enlarge the button in that case.
- Removed alignment argument for text controls
- Removed sorted and labels argument for choice and combo boxes.
- Removed sorted argument for listboxes.
- Added default "stretch" to every toplevel layout, assuring that
   such layout gets at least all available space assigned.
- (un)set "maximize box" when "resizeable" is set.
- Removed default "wxTAB_TRAVERSAL" style on frames (to make the grid
   work correctly).
- Renamed "WXCore.WxcClassTypes" to "WXCore.WxcClassInfo".

Backward compatible additions:
- Added pure "bitmap" and "sound"
- Added "variable" objects (mutable variables)
- Added custom control demo.
- Made "refresh" erase the background too.
- Added "children" attribute for windows.
- Added "border" attribute for windows.
- Added "tabTraversal" attribute for windows.
- Added wxGrid events and demo (samples/wx/Grid.hs).
- Improved signatures for wxGrid.
- Added "changes.txt" file :-)
- Added "HAS_RADIO_MENU_ITEMS" to "isDefined".
- Added support for radio menu items.
- New wxHaskell+HOpenGL sample added to the contributions. Thanks
   to Shelarcy and Sean Seefried.
- Added "Align" and "Wrapped" classes to set alignment
   and wrap mode for text controls.
- Added "Sorted" class to set the sort mode of choice, combo box,
   and listbox controls.
- Added "creation time" attributes that use reflective attributes
   not compositional (and thus not so nice), but very convenient!
- Added "entry" as shorthand for "textEntry"
- Added "SystemColor" and "colorSystem" to get standard system colors.
- Defaulted background color of "Frame"s to Color3DFace (as a Panel).
- Made the definition of "Closure" in "wrappers.h" more liberal to
   support wxOCaml better.
- Added "frameCentre" method
- Huge internal changes: split up wxcClasses in three files and added
   support for managed objects like bitmaps. Also added checks for NULL
   pointers.


Bug fixes:
- HtmlLinkClicked events are now properly generated.
- Fixed bug that crashed wxHaskell when a tree control had the focus
   and a key was pressed. Thanks to Olivier Spier for sending a fix.
- The "item" attribute of a list control always returned the first
   item and disregarded the parameter. Thanks to Olivier Spier for
   sending a fix.

Re: [wxhaskell-users] HPView

[William T. <wi...@dr...>]

Hi Daan,

> Thanks for sharing this with us. It looks quite good (and useful too!).
> I have put a news item on the wxHaskell site, together with one of
> the highly desired places among the applications hall of fame :-)
>
Good stuff!

> I think I will include this among the samples.
> Would it be ok if I put a link to your presentation too from the
> wxHaskell site?
>
Sure thing!

> And thank you for trying out this rather complicated Haskell library!
> If you have any remarks or suggestions, I would love to hear about
> them (offline).
>
In general, I've found it very intuitive and stable. I did run into some 
problems with printing, which I will send privately.


wil.

Re: [wxhaskell-users] HPView

[Daan L. <da...@cs...>]

William Tan wrote:

> As part of my project in the FP course I was doing, I developed a heap 
> profile viewer dubbed "HPView" using wxHaskell. The screen shot is 
> available here:
> 
> http://dready.org/projects/HPView/

Hi Wei,

Thanks for sharing this with us. It looks quite good (and useful too!).
I have put a news item on the wxHaskell site, together with one of
the highly desired places among the applications hall of fame :-)

-- Daan.

> Also, as part of my presentation, there is a small piece of code for a 
> timer that might be useful as sample code in the wxHaskell distro:
> 
> http://dready.org/papers/wxHaskell/Watch.hs

I think I will include this among the samples.
Would it be ok if I put a link to your presentation too from the
wxHaskell site?


> Last but not least, I would like to thank Daan and the community for 
> creating such a wonderful project. I am also very grateful to my 
> lecturer, Manuel Chakravarty, for his guidance and excellent delivery of 
> the course.

And thank you for trying out this rather complicated Haskell library!
If you have any remarks or suggestions, I would love to hear about
them (offline).

> 
> -- 
> wil.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] HPView

[William T. <wi...@dr...>]

Hi,

As part of my project in the FP course I was doing, I developed a heap 
profile viewer dubbed "HPView" using wxHaskell. The screen shot is 
available here:

http://dready.org/projects/HPView/

Please feel free to include it on the wxHaskell site. The code is 
available from the same location, and is released under the same terms 
as GHC's license. If anybody is interested in adopting the project, 
please contact me.

Also, as part of my presentation, there is a small piece of code for a 
timer that might be useful as sample code in the wxHaskell distro:

http://dready.org/papers/wxHaskell/Watch.hs

Last but not least, I would like to thank Daan and the community for 
creating such a wonderful project. I am also very grateful to my 
lecturer, Manuel Chakravarty, for his guidance and excellent delivery of 
the course.

--
wil.

Re: [wxhaskell-users] Can't get HtmlLinkClicked event in WxcHtmlWindow

[Daan L. <da...@cs...>]

Piotr Wieczorek wrote:
> In the following example:
 > [snip]
> ---
> when I click on the "Link" link, I get printed on the console:
> Html Cell "" clicked: Left down at (23, 10)
> or something like this instead of "Link clicked" message, which I expected.
> Can you tell me what's wrong with it?

Hi Piotr,

You have discovered a bug!  I have fixed it already in the
"head" version of CVS which is available by anonymous CVS
after about 24 hours. Unfortunately, there is no workaround
for older wxHaskell versions :-(

All the best,
  Daan.

ps. If you are unable to build wxHaskell, I can provide you with
a binary if you tell me what system you are using (although
I am planning to do a 0.8 release by the end of july).


> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] Can't get HtmlLinkClicked event in WxcHtmlWindow

[Piotr W. <p.w...@pf...>]

In the following example:
---
main = do run example
example = do
    f  <- frameCreateTopFrame "example"
    hw <- wxcHtmlWindowCreate f idAny rectNull wxHW_SCROLLBAR_AUTO ""
    htmlWindowSetPage hw "<html><head></head><body><a
href=\"link.htm\">Link</a></body></html>"
    htmlWindowOnHtmlEvent hw False onClick
    windowShow f
    windowRaise f
    where
        onClick event =
            case event of
                HtmlLinkClicked link _ _ _ -> do
                    putStrLn "Link clicked"
                _ -> do
                    putStrLn (show event)
---
when I click on the "Link" link, I get printed on the console:
Html Cell "" clicked: Left down at (23, 10)
or something like this instead of "Link clicked" message, which I expected.
Can you tell me what's wrong with it?
Piotr Wieczorek

Re: [wxhaskell-users] Window flash on open

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

On Sat, 26 Jun 2004 22:17:33 +0200, Vincenzo aka Nick Name <vincenzo_mlRE=
.MO...@ya...> wrote:

> On Friday 25 June 2004 11:40, Daan Leijen wrote:
>> downside of "creation" attributes is that it creates a distinction
>> between:
>>
>> =A0 =A0 w <- widget [...]
>>
>> and
>>
>> =A0 =A0 w <- widget []
>> =A0 =A0 set w [...]
>
> Why is it a problem? It should be obvious to an user that a property
> could have an initialization value with a default setting. If you are
> in the IO monad it should be clear enough that the second form first
> creates the widget using default settings and then sets the properties;

Thanks Vincenzo and Claus for your feedback,

I guess that I was trying to satisfy too many laws, and
maybe creation attributes are indeed a natural thing.
I was already (planning on) supporting creation attributes, as I
failed to come up with a nicer solution. Now that it seems that
this is even a "natural" extension, it makes me feel much more
confident about it.

I like the model of "defaultAttrs ++ creationAttrs" of Claus,
this explains it nicely.

Thanks,
  Daan.


> the only alternative I see would be an (infamous) GUI monad which
> people seem to dislike: even if you could hide the widget and show it
> on demand, there might be other things unrelated to graphics that
> behave differently if done during initialization or after, do you
> agree?

Yes, let's stay away from a GUI monad :-)


>
> Vincenzo
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

Re: [wxhaskell-users] Window flash on open

[Vincenzo a. N. N. <vin...@ya...>]

On Friday 25 June 2004 11:40, Daan Leijen wrote:
> 1) I added "creation" attributes: that are attributes that are
> treated specially when given in the initial property list. This way,
> the window can immediately be created with the correct size. The
> downside of "creation" attributes is that it creates a distinction
> between:
>
> =A0 =A0 w <- widget [...]
>
> and
>
> =A0 =A0 w <- widget []
> =A0 =A0 set w [...]

Why is it a problem? It should be obvious to an user that a property=20
could have an initialization value with a default setting. If you are=20
in the IO monad it should be clear enough that the second form first=20
creates the widget using default settings and then sets the properties;=20
the only alternative I see would be an (infamous) GUI monad which=20
people seem to dislike: even if you could hide the widget and show it=20
on demand, there might be other things unrelated to graphics that=20
behave differently if done during initialization or after, do you=20
agree?

Vincenzo

Re: [wxhaskell-users] Window flash on open

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

> I still notice one quirk - when I run a program, the window seems to appear briefly at a larger size, then quickly resizes to a smaller size.  This produces an annoying "flash".

Yes, this is known "bug". It occurs because the initial window size is zero.
Then, you set the size using the "clientSize" attribute and the window is
resized to a proper size. There are two ways to solve this.

1) I added "creation" attributes: that are attributes that are treated specially
when given in the initial property list. This way, the window can immediately
be created with the correct size. The downside of "creation" attributes is that
it creates a distinction between:

    w <- widget [...]

and

    w <- widget []
    set w [...]


2) I let the start function take an IO action that returns a "Frame", and
I keep frames hidden by default -- ie. you need to show them explicitly.
This way, the showing of a frame can be delayed until all size and layout constraints
are known.


Both solutions are not too nice however -- but I think I will implement solution
(1) anyways despite its disadvantages. It seems terribly useful in general even
though it is also terribly against the spirit of Haskell :-)

Bottom line: next version (0.8) will fix this one way or the other.\
If anyone knows a better solution, please tell me, so we can prevent
the introduction of "creation" attributes in wxHaskell.

All the best,
  Daan.




>
> Does anyone know why this occurs, and how it can be avoided?
>
> Thanks,
> Lyle
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] Window flash on open

[Lyle K. <li...@qs...>]

Hi, I just installed v 0.7 on Windows XP with GHC 6.2.1 and I have to 
say the programs seem to start a lot faster than with 0.4.  It may be I 
was just low on memory before.

I still notice one quirk - when I run a program, the window seems to 
appear briefly at a larger size, then quickly resizes to a smaller 
size.  This produces an annoying "flash".

Does anyone know why this occurs, and how it can be avoided?

Thanks,
Lyle

Re: [wxhaskell-users] text attribute on checkbox

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

On Thu, 24 Jun 2004 14:46:35 +0200, Sander Evers <sa...@cs...> wrote:

> I've noticed that a checkBox only shows its label (text attribute, which I directly set using the checkBox creation function) if you apply "dynamic" to its layout. This is probably a bug, or not?
>
> --Sander

Funny, I was just discussing this with Arjan. I don't know yet if this is
a bug or just not well documented behaviour. I'll have to think about it a bit more.

However, you need dynamic as you change the "text" later on, which means that
the layout needs to change... In wxWidgets, you normally give the text at
creation time, and there the "dynamic" is not needed. I guess I could default
to dynamic for checkboxes (and radioboxes), or I could make the text attribute
reflective and set it at creation time when possible.

(but the latest solution means that:
   c <- checkBox [text := "hi"]
does no longer equal:
   c <- checkBox []; set c [text := "hi"]
)

All the best,
  Daan.


>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] text attribute on checkbox

[Sander E. <sa...@cs...>]

I've noticed that a checkBox only shows its label (text attribute, which 
I directly set using the checkBox creation function) if you apply 
"dynamic" to its layout. This is probably a bug, or not?

--Sander

Re: [wxhaskell-users] Whence wxGrid?

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

On Fri, 18 Jun 2004 10:35:27 -0700, Lyle Kopnicky <li...@qs...> wrote:

> Hi, I'm new to this list.  I briefly checked the archive, but didn't find an answer to my question.  I would like to know if the wxGrid window is available, and if so, where that fits in the library hierarchy.


Hi Lyle,

Welcome to the wxHaskell list. Sorry to tell you though that we
haven't added wxGrid yet. However, it is on the top of the
priority list -- especially since NetEdit needs the in-place
editing facility offered by wxGrid.

I think that we will add the basic event functionality of
wxGrid soon (1 month?), and hopefully, useful abstractions follow
soon thereafter.

All the best,
  Daan.


>
> Thanks,
> Lyle
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

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.

Re: [wxhaskell-users] wxhaskell 0.7 arrowhead line styles, graph editing and misc questions

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

On Wed, 9 Jun 2004 22:18:30 +0200, klaus <has...@ya...> wrote:

> please have a look at wxart2d, http://wiki.wxwidgets.org/wiki.pl?WxArt2d
> the first release is coming soon. IMO a very big gift for the wxWidget-World,
> and perhaps for the wxHaskell users too?
> Note: not only for 2D-graphics, although it contents a very good document/view module,
> which overcomes the standard (very limited) wxdocview classes.

Sorry for the late reply.
The library looks very advanced. I don't think I will spend time on
adding this to wxHaskell though (see my next mail..) -- however,
I might just write a document that will help others to add interfaces
like this one to wxHaskell and contribute in this way.

> BTW i have to questions:
> Did you managed "the more then once start main problem" in ghci?
> Why are the wxHaskell executables are so big?

As said already, one reason is that Haskell executables are big.
The other reason is that I don't "split" the Haskell object files
which leads to inclusion of  a lot of redundant code. I can probably
solve this rather easily but it is not high on the priority list
right now -- but it just moved up due to your complaint :-)
(I use a lazy, demand driven, development strategy for wxHaskell)

All the best,
  Daan.

[wxhaskell-users] Whence wxGrid?

[Lyle K. <li...@qs...>]

Hi, I'm new to this list.  I briefly checked the archive, but didn't 
find an answer to my question.  I would like to know if the wxGrid 
window is available, and if so, where that fits in the library hierarchy.

Thanks,
Lyle

Re: [wxhaskell-users] Updating Choice controls with new content

[<ch...@dt...>]

Daan Leijen wrote:

> Hi Anders,
>
> On Wed, 16 Jun 2004 15:06:21 +0200, Anders H=F6ckersten=20
> <ch...@dt...> wrote:
>
>> Hi! I've been toying around a bit with wxHaskell lately and have run=20
>> into a problem. My application needs to be able to add elements to a=20
>> Choice control. The elements are read from a HaskellDB-based database=20
>> as a list.
>>
>> My question is this: When clicking my "add" button, how do I tell the=20
>> Choice control to re-read
>>  its list from source? I'm assuming I need to send it some event, but=20
>> which one?
>
>
> I think you can just use the "items" attribute to set the form of the=20
> choice
> control. Something like:
>
>    c <- choice ...
>    ...
>    set c [items :=3D ["hi", "there"]]
>
>
> Furthermore, I think you need to use the "dynamic" attribute on the
> layout of the choice control.
>
>    set f [layout :=3D .... dynamic (widget c) ... ]
>
>
> I hope this helps,
> All the best,
>  Daan.

That worked great! Thank you. Now, on to my next question, which is more=20
generally design oriented, but still touches the previous one. I have a=20
parent window, where you can open a child window to add some new data (a=20
customer in this case). When the new data has been saved, the Choice=20
control in the parent window has to be updated.

However, the child window has no specific knowledge of the Choice=20
control in the parent window, it only knows about the parent window, and=20
giving knowledge of the Choice control to the child window would break=20
encapsulation.

Is there any "recommended" way of solving these kinds of problems? Would=20
creating a new custom event, "updateParent" or similar be a good solution=
?

Actually, after having toyed with wxHaskell for a few days now how to=20
structure my code is my main problem. wxWidgets seems to force sort of=20
an object-oriented approach onto my Haskell program, which I am having=20
trouble adapting to. :) Still, I like wxHaskell. It works well and=20
produces nice results.

Regards,
Anders

[wxhaskell-users] some small items..

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

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

Re: [wxhaskell-users] Updating Choice controls with new content

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

Hi Anders,

On Wed, 16 Jun 2004 15:06:21 +0200, Anders H=F6ckersten <ch...@dt...al=
mers.se> wrote:

> Hi! I've been toying around a bit with wxHaskell lately and have run in=
to a problem. My application needs to be able to add elements to a Choice=
 control. The elements are read from a HaskellDB-based database as a list.
>
> My question is this: When clicking my "add" button, how do I tell the C=
hoice control to re-read
>  its list from source? I'm assuming I need to send it some event, but w=
hich one?

I think you can just use the "items" attribute to set the form of the cho=
ice
control. Something like:

    c <- choice ...
    ...
    set c [items :=3D ["hi", "there"]]


Furthermore, I think you need to use the "dynamic" attribute on the
layout of the choice control.

    set f [layout :=3D .... dynamic (widget c) ... ]


I hope this helps,
All the best,
  Daan.


>
> Anders
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] Updating Choice controls with new content

[<ch...@dt...>]

Hi! I've been toying around a bit with wxHaskell lately and have run 
into a problem. My application needs to be able to add elements to a 
Choice control. The elements are read from a HaskellDB-based database as 
a list.

My question is this: When clicking my "add" button, how do I tell the 
Choice control to re-read its list from source? I'm assuming I need to 
send it some event, but which one?

Anders

Re: [wxhaskell-users] big executables

[<wxh...@al...>]

> Why are the wxHaskell executables are so big?

All Haskell executables are big. :)  Those produced by GHC are anyways. 
I usually reduce mine to 1/10 size by running strip and upx.

$ ls -l a.out
-rwx------  1 user user 6681158 May 22 01:51 a.out
$ ldd a.out
        libwxc-gtk2.4.2-0.7.so => /usr/lib/libwxc-gtk2.4.2-0.7.so
        (0x00ab9000)
        libdl.so.2 => /lib/libdl.so.2 (0x44d69000)
        libreadline.so.4 => /usr/lib/libreadline.so.4 (0x45af5000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x45ab3000)
        libm.so.6 => /lib/tls/libm.so.6 (0x44d45000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x44d6e000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x44e71000)
        libc.so.6 => /lib/tls/libc.so.6 (0x44c0a000)
        libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x44efe000)
        libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x4bb68000)
        libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x45133000)
        libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x4bb2d000)
        libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4510c000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4bba2000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x44e4e000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00111000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x45b23000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4524b000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x001ef000)
        libz.so.1 => /usr/lib/libz.so.1 (0x44e5e000)
        libGL.so.1 => /usr/X11R6/lib/tls/libGL.so.1 (0x4528d000)
        libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x00230000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x453d1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x45385000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x44bf2000)
        libgpm.so.1 => /usr/lib/libgpm.so.1 (0x450b3000)
$ strip a.out
$ ls -l a.out
-rwx------  1 user user 2860808 Jun  9 15:20 a.out
$ upx a.out
                     Ultimate Packer for eXecutables
         Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002
UPX 1.24         Markus F.X.J. Oberhumer & Laszlo Molnar         Nov 7th
2002
 
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
   2860808 ->    620806   21.70%    linux/386    a.out
 
Packed 1 file.
$ ls -l a.out
-rwx------  1 user user 620806 Jun  9 15:20 a.out

Re: [wxhaskell-users] wxhaskell 0.7 arrowhead line styles, graph editing and misc questions

[klaus <has...@ya...>]

Hi all,

Daan, thanks for the really good wxHaskell binding.

I'm using wxwindows/widgets for over 3 years. 
IMO the best choice for multiplatform developing.
But i'm a newbie in Haskell. ;)

> > I've just started playing around with wxhaskell a little bit
> > more seriously, and keep having problems finding my way
> > through the docs.
> 
> Yes, the documentation is still problematic -- allthough I have worked
> very hard to document everything *somewhere* :-) Many times, I give
> all classes a specific widget belongs too in the description of the
> creation function.
For a complete rewrite, very good!


> > "Objects Graphic Library (OGL)" but I can't find any further
> > info on this.
> Never heard of it either? Maybe it is in the contributions. I'll
> look into it -- maybe it is a good addition to include.
please have a look at wxart2d, http://wiki.wxwidgets.org/wiki.pl?WxArt2d
the first release is coming soon. IMO a very big gift for the wxWidget-World, 
and perhaps for the wxHaskell users too?
Note: not only for 2D-graphics, although it contents a very good document/view module,
which overcomes the standard (very limited) wxdocview classes.

BTW i have to questions:
Did you managed "the more then once start main problem" in ghci?
Why are the wxHaskell executables are so big?

Regards
Klaus

Re: [wxhaskell-users] wxhaskell 0.7 arrowhead line styles, graph editing and misc questions

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

Hi Daan,

> Yes, the documentation is still problematic -- allthough I have worked
> very hard to document everything *somewhere* :-) 

I guess part of the problem is that Haddock doesn't know about modelling
OO hierarchies in Haskell, and another that alphabetical indices are defeated
by generic prefixes. Well, I'll have to rely on this list, then!-)
 
> Regarding arrowheads, see the "WX.Draw" module documentation.
> There is no arrowhead primitive, I see, so you need to draw a little
> triangle yourself :-(  -- but don't forget to look at the "penCap"
> attribute of a DC.

penCap/CapStyle was indeed where I'd expected to find this. 

"draw it yourself"? So much for the "industrial strength library with 
11 years of evolution behind it"..

or are such standard goodies in the missing 25% ?-) but at least 
that explains my difficulties in finding docs about this :-|

> > ..window resizing at creation time..
> Yes, annoying. I know how to solve this now, so it will be in
> version 0.8. (-- which is a big update btw, with automatic
> memory management of bitmaps etc.)

ok, thanks.

> Never heard of it either? Maybe it is in the contributions. I'll
> look into it -- maybe it is a good addition to include.

Here's what I found:

    Object Graphics Library 
    OGL defines an API for applications that need to display objects 
    connected by lines. The objects can be moved around and interacted 
    with. You can find this in contrib/src/ogl, contrib/include/wx/ogl, and 
    contrib/samples/ogl. 

sounds like just the ticket, but given the scarcity of www-references, 
it might have been abandoned, or renamed..
 
Cheers,
Claus

Re: [wxhaskell-users] wxhaskell 0.7 arrowhead line styles, graph editing and misc questions

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

Hello Arjan,

> >  For instance, how do I get arrowheads at the end of my lines?
> I do not know what this means.

arrow, as in "bow and arrow" - no categories involved;-)
useful to indicate directional links in directed graphs, e.g., 
you use them in your NetEdit screenshot.
 
> I develop the NetEdit tool. It is an editor for probabilistic networks 
> (summary: nodes and arcs and probability tables at each node). You can 
> get the source from me if you want. It is growing larger and larger and 
> does much more than just editing networks, but maybe you can partially 
> evaluate it to your needs :-)

Only if you don't mind me borrowing some ideas/code from it
(such as dealing gracefully with arrows;-). I've got a rudimentary 
graph editor working, but working code for a more complete app 
would help me to find my way into the documentation, not to mention 
saving time on more "advanced" user interface features. So, if 
reuse is ok with you, I'd like to have a look.
 
> It is of course possible to write SOEGraphics on top 
> of wxHaskell. A nice student project I would think...

Yes, but I'm not so much worried about Paul's book. More about
something nice, small and working to give to beginners (as in: download
over a slow modem and get going with fun stuff quickly). The standard
package was Hugs+SOEGraphics, but the latter is -once again- out of 
sync with the Hugs releases.. But if Daan seems to think that wxhaskell
for Hugs wouldn't fall into the "small" category, that's probably not 
the right replacement. There's still the question of the "standard" 
Haskell GUI being available for all Haskell systems (Hugs is still 
popular in academic teaching, I think).

Cheers,
Claus

Re: [wxhaskell-users] wxhaskell 0.7 arrowhead line styles, graph editing and misc questions

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

Hi Claus,

On Wed, 9 Jun 2004 19:26:25 +0100, Claus Reinke <cla...@ta...> wrote:

> I've just started playing around with wxhaskell a little bit
> more seriously, and keep having problems finding my way
> through the docs.

Yes, the documentation is still problematic -- allthough I have worked
very hard to document everything *somewhere* :-) Many times, I give
all classes a specific widget belongs too in the description of the
creation function.

Regarding arrowheads, see the "WX.Draw" module documentation.
There is no arrowhead primitive, I see, so you need to draw a little
triangle yourself :-(  -- but don't forget to look at the "penCap"
attribute of a DC.

> How do I avoid my wxhaskell window
> to flick to an interim size before settling on the intended size
> (happens, e.g., with the bouncing ball demo)?

Yes, annoying. I know how to solve this now, so it will be in
version 0.8. (-- which is a big update btw, with automatic
memory management of bitmaps etc.)

> I'd like to hack on a little Petri net editor, and while that
> hasn't been too difficult so far, it sounds like a standard
> problem, so: is there a graph editor component for wxhaskell
> that I could build on? The wxwidgets pages mention an
> "Objects Graphic Library (OGL)" but I can't find any further
> info on this.

Never heard of it either? Maybe it is in the contributions. I'll
look into it -- maybe it is a good addition to include.

> Also, there seem to be a few oddities with the demos on
> a windows98 box (in addition to the window size problem):
>
>     - TimeFlows: only "Time" follows the mouse, the other
>         words hang in the upper left corner
>     - Process: responds only with error pings, whatever the
>         input

Hmm, I never tested it myself on windows98 -- I can imagine that
Process doesn't work as it uses multi threading, but the "Time"
behaviour is strange indeed -- probably the "idle" events don't come
through correctly (or getCPUTime is broken?)

> As for installation, I'd prefer to put the library in the ghc dirs
> instead of the system dirs. And, after registering wx and wxcore
> with ghc, I still have to give the -package wx flag when starting
> ghci. Can't ghc/ghci deduce that from the imports [ghc docs,
> 4.8.1. Using a package: Some packages are automatically
> available: you don't need to specify any extra flags to use
> them (except in certain circumstances; see below). All the
> packages which contain hierarchical libraries fall into this
> category.]?

I never looked into "automatic" loading. If I can find out how it
works, I'll try to include it in version 0.8. Maybe you can instruct
ghc yourself to include it by default? (using ghc-pkg)

> Oh, and does wxhaskell work with hugs? If yes, easily installable
> packages to replace the aging HGL/SOEGraphics would be nice:-)

Never tried it, but I think that the library might be a bit heavy
weight for Hugs. However, I never particularly rely on GHC features
so it might just work.

All the best,
  Daan.


>
> Cheers,
> Claus
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>