wxhaskell-users — General mailing list for wxhaskell users

RE: [wxhaskell-users] wxhaskell vs. HToolkit

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

Hi Per,

> I have lately experimented with both wxhaskell and HToolkit. 
> I'm a bit  confused, they seems very similiar in style and have common

> implementors (Daan Leijen).  

History:

At the beginning of 2003, I was disappointed with the current state
of affairs regarding GUI's for Haskell. A most promising project
was the HToolkit library by Krasimir Angelov. He started this project
to make a portable successor of the objectIO library.

He created a low-level C interface for programming GUI's. He 
implemented this interface for both Windows and GTK -- getting
a somewhat portable way to program GUI's. HToolkit was a bit
monolithic at that time and I separated out the low-level interface
(Port) and designed a higher level interface (GIO).

Although I was very enthousiastic to begin with, I slowly became
aware of the drawbacks of this approach. In my opinion, it will
be too hard to maintain such a library for multiple platforms -- 
slowly the task will grow bigger and bigger, and bugs just kept
creeping up. Furthermore, I realized that it is probably also
too much work to support the amount of features necessary 
for "real" applications. I got more and more confirmed in my
doubts when I studied other portable GUI libraries -- almost all
have died a slow and lingering death due to unsupported features,
platforms, and bugs -- even rather nicely designed and technologically
advanced libraries.  

So, in the end I concluded that designing, implementing, and
*maintaining*
such library will be too hard for a small community like that of
Haskell,
and I abandoned the project (although I still believe it is a nice
and cleanly designed library)

The right way of doing a portable library for Haskell, is to build on 
the work of others! So I used the wxWindows library as the basis to
build a portable GUI library for Haskell. wxWindows is free, portable
across many platforms (windows,macOSX,GTK,X11,...) and has a large
and active user community (top 25 of sourceforge, over 1 million
downloads). 
Furthermore, rather serious applications have been written in it, 
including the latest AOL communicator and Mojoworld. 

The good part is now that we don't have to do anything (well, almost:-)
to run on different platforms -- that is all done by the wxWindows
community.
Furthermore, the interface is generated automatically, so it is easy
to follow new versions and to maintain the library. And we are not the
only ones to see these advantages, wxPython is higly popular and many
other bindings are there: wxEiffel, wx.NET, wxJScript, wxLUA, etc.

wxWindows is also fairly comprehensive -- this makes it easy to support
new features: just over the weekend there is support for portable ODBC 
and the OpenGL canvas (will be included in the next release).
It saves a *lot* of work when all the hard parts have already been done
by others :-)

There are also drawbacks: wxWindows is not as "clean" as I would have 
liked it to be, it written in C++, the library is rather large etc. But
I don't think these drawbacks are serious enough in the light of the
advantages.


> I have also read that the haskell community  has decided that 
> the "common GUI" project, which I suppose HToolkit is an 
> implementation of, is no longer officially supported as a project for
obtaining 
> a standard GUI library for haskell, but that wxhaskell instead is the 
> preferred library.

Opinion:

This is a "sensitive" subject :-).  I would say that the
"common GUI" interface is not abandoned. It still makes sense to define
a kind of standard medium level interface that is somewhat 
standardized. However, I believe that it is too hard at this moment
to define such a thing -- besides technical challenges with regard to 
types, it is also unclear how the interfaces should look like. There is
no
well defined goal and I think that is because there are just not many
real GUI programs written in Haskell (except maybe for Programmatica?)

> What will be the practical implications of that wxhaskell is 
> officially supported by the haskell community and that HToolkit is
not? 

Current:

It is a rather unfortunate situation that in this small community
there are now two libraries that try to do the same thing :-( 
I don't know what to do about this, and maybe we should just leave
it as it is (although I would love to have Krasimir as a co-developer,
he is an excellent programmer :-).

I hope this answers some of your questions,
and that it puts things into perspective,

All the best,
 Daan Leijen.

 
> Regards
> Per
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
> 

[wxhaskell-users] wxhaskell vs. HToolkit

[Per L. <pe...@L4...>]

Hi,

I have lately experimented with both wxhaskell and HToolkit. I'm a bit=20
confused, they seems very similiar in style and have common implementors=20
(Daan Leijen).  I have also read that the haskell community has decided t=
hat=20
the "common GUI" project, which I suppose HToolkit is an implementation o=
f,=20
is no longer officially supported as a project for obtaining a standard G=
UI=20
library for haskell, but that wxhaskell instead is the preferred library.

Could someone in the knowing say a few words about what this will mean fo=
r=20
these libraries. Are these completely distinct libraries or is the meanin=
g=20
that they will contain more or less the same functionality and similar=20
interface, if not what are the advantages for choosing one or another? Wh=
at=20
will be the practical implications of that wxhaskell is officially suppor=
ted=20
by the haskell community and that HToolkit is not?=20

Regards
Per

RE: [wxhaskell-users] Documentation

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

Hi Per,

> Thanks for all the work!

Thank you!

> maybe someone can 
> give me a hint for usable tutorials written for the original 
> wxwindows library or for some of the ports of it? 

- On the wxHaskell website is a short tutorial
- I would advise to download the wxWindows documentation as
 it contains many good overviews op specific aspects.
- The wxWindows site itself also points to some tutorials

> I would also be very interested to 
> see an example of how to install a user-defined GUI object in 
> wxhaskell, i.e.  how to write a 'megawidget' in haskell giving 
> it a similar interface as the builtin objects.

You would create an (abstract) data type that holds your
widgets, and than create instances for common attributes.
When you are more comfortable with the library, you could
look into the source code for the WX layer to see some 
examples.

Hope this helps,
  -- Daan Leijen



> 
> Best Regards 
> Per
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See 
> the people who have HELPED US provide better services: Click 
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] Documentation

[Per L. <pe...@L4...>]

Hello haskell companions on this mailing list!

I downloaded wxhaskell a couple of days ago and is very enthusiastic, it =
looks=20
good on the screen and the programming interface seems, at a first glance=
, to=20
be comprehensive and well-designed. Thanks for all the work!

Because I am new to wxwindows I have problems getting an overview of the=20
library though, the haddock documentation is reference material and is no=
t=20
suitable for learning the basic idioms and the examples in the source=20
distribution are too few and too sparsely commented These are not complai=
ns,=20
I appreciate that the library is new and that it will take some time befo=
re=20
there will be more documentation available, but until then, maybe someone=
 can=20
give me a hint for usable tutorials written for the original wxwindows=20
library or for some of the ports of it? I would also be very interested t=
o=20
see an example of how to install a user-defined GUI object in wxhaskell, =
i.e.=20
how to write a 'megawidget' in haskell giving it a similar interface as t=
he=20
builtin objects.

Best Regards=20
Per

RE: [wxhaskell-users] setting callbacks in callbacks

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

> -----Original Message-----
> by David Roundy
>
> The following code gives me "interesting" results:
> 
> module Main where
> import Graphics.UI.WX
> 
> main = start $ do f <- frame [text := "layout demo"]
>                   h <- staticText f []
>                   hello h
>                   q <- button f [text := "quit", on command 
> := close f]
>                   set f [layout := column 5 [widget h,
>                                              widget q]] 
> 
> hello st = set st [text := "Hello world!",
>                    on click := \_ -> goodbye st]
> goodbye st = set st [text := "Goodbye world!",
>                      on click := \_ -> hello st]
> 
> [snip]
> 
> So my question is, am I supposed to be allowed to modify a 
> callback function within that callback function? 


I have found the bug. It is in my implementation of "event filters". 
There is just one primitive event, "mouse" that
gets all mouse events. For convenience there is a host of "event
filters"
on top of "mouse". Somehow, I made a mistake in their implementation
and I will try to fix it in the next release. Note that your problem
goes away when you use the basic "mouse" events.

-- Daan.



> Obviously I 
> could get the same functionality either using an IORef or by 
> checking the current contents of the text, but I don't see 
> why you shouldn't be able to modify a callback within the 
> callback.  Or perhaps there is some other more subtle problem 
> going on here...
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See 
> the people who have HELPED US provide better services: Click 
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

Re: [wxhaskell-users] informing parent of a size change

[David R. <dr...@jd...>]

On Mon, Oct 13, 2003 at 07:08:48PM +0200, Daan Leijen wrote:
> > I have yet another difficulty I've run into.  When a widget's size
> > changes, I can't figure out how to inform its parent that it needs to
> > recalculate its layout.
> 
> Yeah, this is the problem I pointed at a few mails ago. We/I should
> really revise the sizing model in wxHaskell. The problem is that this
> model is not really well specified in wxWindows (as they tend to not use
> resizeable dialogs etc) and it takes some experimentation to get it
> working well.

I agree.  Sizing is probably the trickiest thing to get right in
cross-platform gui code.  Because of the need for backwards-compatability,
wxwin has an awful lot of confusing cruft in this area, so rethinking
things for wxhaskell sounds like a great idea.

> In this case, I have found the problem :-)  I had forgotten to
> set the "wxADJUST_MINSIZE" flag in the code for sizers... talking
> about obscure behaviour :-)

Thanks for the quick response (and good luck on getting your thesis done)!

> ...
>
> The fix is in the latest cvs HEAD. (note that anonymous checkouts
> might be 24 hours late? you can check by searching for the
> wxADJUST_MINSIZE word). If you can't compile wxHaskell by yourself
> and really need this fix, drop me a mail and I'll try to provide an
> interim release later this week.

Anonymous CVS doesn't seem to have the fix yet... I'll wait patiently.  :)
-- 
David Roundy
http://www.abridgegame.org/darcs

RE: [wxhaskell-users] informing parent of a size change

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

Hi David,

> I have yet another difficulty I've run into.  When a widget's 
> size changes, I can't figure out how to inform its parent 
> that it needs to recalculate its layout.  

Yeah, this is the problem I pointed at a few mails ago. We/I should
really revise the sizing model in wxHaskell. The problem is that
this model is not really well specified in wxWindows (as they
tend to not use resizeable dialogs etc) and it takes some
experimentation to get it working well.

In this case, I have found the problem :-)  I had forgotten to
set the "wxADJUST_MINSIZE" flag in the code for sizers... talking
about obscure behaviour :-)

For your particular example, this also solves our previous problem
of setting the client size again when label changed. Just one
tiny inconvenience left: you just have to call "windowFit" again 
on the parent frame or otherwise the frame itself is not resized.
Maybe we can automate this too, but I'll have to think about it ..

For example, the "windowFit" is not completely satisfying, as it 
will also shrink a window when it is resized by the user. You can 
use the following code to just ensure that the window is at least large 
enough, but it won't shrink to the minimal possible size (where
"f" is the frame):

       sz   <- get f clientSize
       best <- get f bestSize
       set f [clientSize := sizeMax best sz]


The fix is in the latest cvs HEAD. (note that anonymous checkouts
might be 24 hours late? you can check by searching for the
wxADJUST_MINSIZE word). If you can't compile wxHaskell by yourself
and really need this fix, drop me a mail and I'll try to provide an
interim release later this week.

All the best,
 Daan.


In the following 
> example, when the text changes to have two lines, I'd like 
> the window to rearrange itself (resizing if necesary) to fit 
> the new size of the text.
> 
> In wxwin itself I think one would call wxWindow::Layout on 
> the parent to do this, but I can't see how to do this in wxhaskell.
> 
> module Main where
> import Graphics.UI.WX
> 
> main = start $ do f <- frame [text := "layout demo"]
>                   h <- staticText f [text := "Hello world!"]
>                   set h [on click := \_ -> goodbye h]
>                   q <- button f [text := "quit", on command 
> := close f]
>                   set f [layout := column 5 [widget h,
>                                              widget q]] 
> 
> goodbye st = do set st [text := "Goodbye world!\nAlas, I knew 
> it well..."]
>                 bs <- get st bestSize
>                 set st [clientSize := bs]
> 
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See 
> the people who have HELPED US provide better services: Click 
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

RE: [wxhaskell-users] setting callbacks in callbacks

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

Hi David,

> The following code gives me "interesting" results:
> 
> module Main where
> import Graphics.UI.WX
> 
> main = start $ do f <- frame [text := "layout demo"]
>                   h <- staticText f []
>                   hello h
>                   q <- button f [text := "quit", on command 
> := close f]
>                   set f [layout := column 5 [widget h,
>                                              widget q]] 
> 
> hello st = set st [text := "Hello world!",
>                    on click := \_ -> goodbye st]
> goodbye st = set st [text := "Goodbye world!",
>                      on click := \_ -> hello st]
> 
> The code is intended to alternate between displaying "Hello 
> world!" and "Goodbye world!" each time you click on the text. 
>  Instead, sometimes it crashes, and it never ends up getting 
> back to displaying "Hello world!" after you've clicked it.  
> It seems to occasionally go into a frenzy of alternating 
> between "Hello world!" and "Goodbye world!" for quite a 
> while--presumably stopping when some sort of a race condition 
> has been satisfied.
> 
> So my question is, am I supposed to be allowed to modify a 
> callback function within that callback function? 

Yes, you should definitely be able to set callbacks within
callbacks -- and it happens all the time too, so the general
mechanism works. (for example, the initialization code given
as an argument to "start" is a callback itself..)

Regarding your example, it is either a bug in my code or in
the wxWindows code and I'll have to debug it myself in more
detail (but I am extremely busy getting my phd-thesis to the
presses so it can take a few more days).

It might have something to do with chain of "click" events
that keep occurring. Maybe you should call "propegateEvent" at
the end of each event handler.

I'll investigate this further,
Thanks for the report,
 Daan.



> Obviously I 
> could get the same functionality either using an IORef or by 
> checking the current contents of the text, but I don't see 
> why you shouldn't be able to modify a callback within the 
> callback.  Or perhaps there is some other more subtle problem 
> going on here...
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See 
> the people who have HELPED US provide better services: Click 
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] informing parent of a size change

[David R. <dr...@jd...>]

I have yet another difficulty I've run into.  When a widget's size changes,
I can't figure out how to inform its parent that it needs to recalculate
its layout.  In the following example, when the text changes to have two
lines, I'd like the window to rearrange itself (resizing if necesary) to
fit the new size of the text.

In wxwin itself I think one would call wxWindow::Layout on the parent to do
this, but I can't see how to do this in wxhaskell.

module Main where
import Graphics.UI.WX

main = start $ do f <- frame [text := "layout demo"]
                  h <- staticText f [text := "Hello world!"]
                  set h [on click := \_ -> goodbye h]
                  q <- button f [text := "quit", on command := close f]
                  set f [layout := column 5 [widget h,
                                             widget q]] 

goodbye st = do set st [text := "Goodbye world!\nAlas, I knew it well..."]
                bs <- get st bestSize
                set st [clientSize := bs]

-- 
David Roundy
http://www.abridgegame.org

[wxhaskell-users] setting callbacks in callbacks

[David R. <dr...@jd...>]

The following code gives me "interesting" results:

module Main where
import Graphics.UI.WX

main = start $ do f <- frame [text := "layout demo"]
                  h <- staticText f []
                  hello h
                  q <- button f [text := "quit", on command := close f]
                  set f [layout := column 5 [widget h,
                                             widget q]] 

hello st = set st [text := "Hello world!",
                   on click := \_ -> goodbye st]
goodbye st = set st [text := "Goodbye world!",
                     on click := \_ -> hello st]

The code is intended to alternate between displaying "Hello world!" and
"Goodbye world!" each time you click on the text.  Instead, sometimes it
crashes, and it never ends up getting back to displaying "Hello world!"
after you've clicked it.  It seems to occasionally go into a frenzy of
alternating between "Hello world!" and "Goodbye world!" for quite a
while--presumably stopping when some sort of a race condition has been
satisfied.

So my question is, am I supposed to be allowed to modify a callback
function within that callback function? Obviously I could get the same
functionality either using an IORef or by checking the current contents of
the text, but I don't see why you shouldn't be able to modify a callback
within the callback.  Or perhaps there is some other more subtle problem
going on here...
-- 
David Roundy
http://www.abridgegame.org

RE: [wxhaskell-users] control sizes not set properly

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

Hi David,

> > It seems to me that wxWindows should handle this automatically, not 
> > that the user of a library should be concerned about it.
> 
> Well, wxwin handles it automatically if the label is set in 
> the control constructor, which is what is almost always done 
> in C++.  When changing the label later, you don't necesarily 
> want to resize the control, since that probably will involve 
> redrawing the entire window, which could be visually unappealing...

Hmm, well, I will study the whole sizing issue in more detail
in the future. For now, it is easy to work around it.

Thanks for your help,
 Daan.


> 
> > Anyhow, we can add these calls easily to the WX layer.
> 
> ...
> 
> > ps. I am fairly busy with other stuff at the moment.  If 
> you feel like 
> > it, maybe you can change the WX layer yourself to include your size 
> > fixes (and maybe with a little sample).  I can than integrate them 
> > into the CVS sources (or give you write access)
> 
> I don't have time (or the wxhaskell source...) at the moment 
> either, but if I get around to it, I'll let you know.
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See 
> the people who have HELPED US provide better services: Click 
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

Re: [wxhaskell-users] control sizes not set properly

[David R. <dr...@jd...>]

On Thu, Oct 09, 2003 at 02:16:32PM +0200, Daan Leijen wrote:
> Ha, great that you found out how to solve these bugs!  I think I once
> thinkered with spaces etc. on the check boxes because of this.
> 
> > A fix is after creating a control q (or modifying its label) 
> > is to call:
> > 
> > > bs <- get q bestSize
> > > set q [clientSize := bs]
> 
> It seems to me that wxWindows should handle this automatically, not that
> the user of a library should be concerned about it.

Well, wxwin handles it automatically if the label is set in the control
constructor, which is what is almost always done in C++.  When changing the
label later, you don't necesarily want to resize the control, since that
probably will involve redrawing the entire window, which could be visually
unappealing...

> Anyhow, we can add these calls easily to the WX layer.

...

> ps. I am fairly busy with other stuff at the moment.  If you feel like
> it, maybe you can change the WX layer yourself to include your size fixes
> (and maybe with a little sample).  I can than integrate them into the CVS
> sources (or give you write access)

I don't have time (or the wxhaskell source...) at the moment either, but if
I get around to it, I'll let you know.
-- 
David Roundy
http://www.abridgegame.org

[wxhaskell-users] Haskell on the cover of a magazine!

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

wxHaskell gets a two-page article in the october edition=20
of the popular French PC magazine, L'Informaticien.=20

The article is written by Fr=E9d=E9ric Mazu=E9, and gives an
overview of wxWindows, wxHaskell, and compares the library=20
against F# (the OCaml integration to .NET).

For screenshots of the relevant pages, see:

 http://wxhaskell.sourceforge.net/screenshots.html#linformaticien

Just think of all those thousands of French O'Caml programmers=20
that will suddenly start to use Haskell ;-)

All the best,
 Daan Leijen.


"wxHaskell est un outil d'ores et d=E9j=E0 remarquable et d'une=20
grande fiabilit=E9. Examinons de plus pr=E8s ce dont il s'agit."

"En raison de toutes ses qualit=E9s, la popularit=E9 de Haskell
va donc croissant"

Re: [wxhaskell-users] control sizes not set properly

[Nick N. <nic...@in...>]

Alle 14:16, gioved=EC 9 ottobre 2003, Daan Leijen ha scritto:
> That is, if I set
> the clientSize, the window can't be resized to a smaller
> size. I would like to give a good size hint, but allow
> smaller sizes too.

Maybe you can create it with 0 or 1 size, then resize, and then show it?=20
This is a ugly workaround but might work.

V.

RE: [wxhaskell-users] control sizes not set properly

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

Ha, great that you found out how to solve these bugs!
I think I once thinkered with spaces etc. on the check
boxes because of this. 

> A fix is after creating a control q (or modifying its label) 
> is to call:
> 
> > bs <- get q bestSize
> > set q [clientSize := bs]

It seems to me that wxWindows should handle this automatically,
not that the user of a library should be concerned about it.
Anyhow, we can add these calls easily to the WX layer.

Another problem that I haven't tackled yet is how to
set a good "initial" size of  window. That is, if I set
the clientSize, the window can't be resized to a smaller
size. I would like to give a good size hint, but allow
smaller sizes too.

Thanks for the help,
 Daan.


ps. I am fairly busy with other stuff at the moment.
If you feel like it, maybe you can change the WX layer yourself
to include your size fixes (and maybe with a little sample).
I can than integrate them into the CVS sources (or give 
you write access)


> -----Original Message-----
> From: wxh...@li... 
> [mailto:wxh...@li...] On 
> Behalf Of David Roundy
> Sent: donderdag 9 oktober 2003 13:49
> To: wxh...@li...
> Subject: [wxhaskell-users] control sizes not set properly
> 
> 
> It seems that the sizes of basic controls--I've tried buttons 
> and checkboxes aren't getting set properly based on their 
> text.  A simple example that shows a problem is if you take 
> the example from the Graphics.UI.WX.Layout documentation, and 
> replace the "quit" with "quit this application now", using 
> wxhaskell 0.3 on macos X I get a button which is too small, 
> so that only "s applicat" is visible.
> 
> It seems that wxhaskell changes the text after creating a 
> control, but doesn't bother to update the size of the control 
> based on that text.
> 
> A fix is after creating a control q (or modifying its label) 
> is to call:
> 
> > bs <- get q bestSize
> > set q [clientSize := bs]
> 
> However, I think this really should be done automatically 
> whenever the text is modified.  If a user wants to change the 
> text without changing the control's size, the user can do 
> that by hand.
> 
> Oh yes, and the bug applies to checkboxes as well, which 
> require a whole slew of extra space because they don't set 
> their size according to their text.
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See 
> the people who have HELPED US provide better services: Click 
> here: http://sourceforge.net/supporters.php
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] control sizes not set properly

[David R. <dr...@jd...>]

It seems that the sizes of basic controls--I've tried buttons and
checkboxes aren't getting set properly based on their text.  A simple
example that shows a problem is if you take the example from the
Graphics.UI.WX.Layout documentation, and replace the "quit" with "quit this
application now", using wxhaskell 0.3 on macos X I get a button which is
too small, so that only "s applicat" is visible.

It seems that wxhaskell changes the text after creating a control, but
doesn't bother to update the size of the control based on that text.

A fix is after creating a control q (or modifying its label) is to call:

> bs <- get q bestSize
> set q [clientSize := bs]

However, I think this really should be done automatically whenever the text
is modified.  If a user wants to change the text without changing the
control's size, the user can do that by hand.

Oh yes, and the bug applies to checkboxes as well, which require a whole
slew of extra space because they don't set their size according to their
text.
-- 
David Roundy
http://www.abridgegame.org

Re: [wxhaskell-users] make fails on FreeBSD 5.1

[Wolfgang T. <wol...@gm...>]

Daan Leijen wrote:

> Maybe this is a Gnu make extension and you are not using
> Gnu make? (Does someone on this list know about this problem?)
> Have you tried using Gnu make (gmake) directly?

Looks like it; if I use "bsdmake" on Mac OS X (rather than "make", 
which is a symlink to gnumake here), I get exactly the same error 
messages.

Cheers,

Wolfgang

RE: [wxhaskell-users] make fails on FreeBSD 5.1

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

Hi Silas,

I just tested on freeBSD 4.7 stable, and had no errors.
(and neither on windows and mac)

The line "286" consists of:

ifeq ($(TOOLKIT),mac)
...

So it seems, that "ifeq" is not correctly interpreted.
All the other errors are also related "if" statements.

Maybe this is a Gnu make extension and you are not using
Gnu make? (Does someone on this list know about this problem?)
Have you tried using Gnu make (gmake) directly?

Hope this helps,
 Daan.

> -----Original Message-----
> From: wxh...@li... 
> [mailto:wxh...@li...] On 
> Behalf Of Silas
> Sent: woensdag 8 oktober 2003 4:13
> To: wxh...@li...
> Subject: [wxhaskell-users] make fails on FreeBSD 5.1
> 
> 
> Hi--I'm running FreeBSD 5.1 stable, and whereas the configure 
> script completes without error, running make gives this error 
> (abridged):
> 
> "makefile", line 286: Missing dependency operator
> "makefile", line 288: Need an operator
> "makefile", line 290: Need an operator
> "makefile", line 358: Missing dependency operator
> 
> ...and so on, down to:
> 
> "makefile", line 556: Missing dependency operator
> Error expanding embedded variable
> 
> Any suggestions would be appreciated;-) Any chance of getting 
> wxHaskell in the FreeBSD ports sometime?
> 
> Obliged, Silas
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> wxhaskell-users mailing list wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] make fails on FreeBSD 5.1

[Silas <si...@nc...>]

Hi--I'm running FreeBSD 5.1 stable, and whereas the configure script
completes without error, running make gives this error (abridged):

"makefile", line 286: Missing dependency operator
"makefile", line 288: Need an operator
"makefile", line 290: Need an operator
"makefile", line 358: Missing dependency operator

...and so on, down to:

"makefile", line 556: Missing dependency operator
Error expanding embedded variable

Any suggestions would be appreciated;-) Any chance of getting wxHaskell
in the FreeBSD ports sometime?

Obliged, Silas

Re: [wxhaskell-users] scrolledWindow

[David R. <dr...@jd...>]

On Tue, Oct 07, 2003 at 11:22:47AM +0200, Daan Leijen wrote:
> Hi David,
> 
> > Hello.  I'm unclear as to how to get a scrolledWindow to work properly
> > with sizers.  In the following example, I don't get a scrollbar,
> 
> Well, I am not a wxWindows expert either. However, I think that you
> always have to set the "virtualSize" of a scrolled window to get the
> sizer working. In your example, you set the "scrollRate", but forget to
> set the "virtualSize". Maybe that is the cause of the problems?

According to the wxwin docs, it seems that if you use a sizer with the
wxScrolledWindow, it can determine the virtualSize from the sizer data.  My
problem is in making the actual size of the window smaller than the virtual
size.

I've figured out a rather ugly solution.  The following code works:

\begin{code}
module Main where
import Graphics.UI.WX
import Graphics.UI.WXCore.WxcClasses ( windowSetSizeHints )

main = start $ hello

hello = do f <- frame [text := "Hello Scrollbars!"]
           scrolled <- scrolledWindow f [layout := rigid $ column 0 $ take 47 labels,
                                         scrollRate := size 10 10]
           windowSetSizeHints scrolled (-1) (-1) (-1) (-1) (-1) (-1)
           set f [clientSize := size 100 100]
           quit <- button f [text := "Quit", on command := close f]
           set f [layout := column 0 [fill $ widget scrolled,
                                      centre $ hstretch $ margin 5 $ widget quit]]
    where labels = map (floatLeft . label . ("Label Number "++) . show) [1..]
\end{code}

Interestingly, if you move the set f clientSize either after the "quit <-"
line or before the windowSetSizeHints line, the code no longer works.  In
either case, "scrolled" is set to be the size of its contents, and cannot
be resized to be smaller.

The windowSetSizeHints call is interesting, as it just sets the size hints
to their default values (that's what all the -1s are about), so it suggests
that someone is setting them to non-default values... (since without that
call, the code won't work).
-- 
David Roundy
http://www.abridgegame.org

RE: [wxhaskell-users] announce: wxhaskell 0.3

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

Hi Luc,

> i installed wx 2.4.2 + dev from rpm on mdk9.1/vmware
> and recompile 0.3 from the src.
> 
> most sample went fine, but:
> - time flows... : all writing are garbled on the top left corner
> - notebookright:  : right note are ok on gtk, bitmap ok, but 
> no action on righclick
> - camels : no action on click

Thanks for the feedback. I don't think I had these problems
on my freeBSD test system, but I'll check it again. However:

- time flows: you need to drag with the mouse to get the text flowing.
- camels: you need to click on a camel


All the best,
 Daan.

> 
> all these effects were already present on 0.2
> 
> should i have hacked anything beforehand ?
> otherwise, can somebody confirm it works on gtk ? (not gtk 2, 
> or should i ?)
> 
> ----- Original Message -----
> From: "Daan Leijen" <daa...@xs...>
> To: <wxh...@li...>
> Sent: Wednesday, October 01, 2003 1:01 PM
> Subject: [wxhaskell-users] announce: wxhaskell 0.3
> 
> 
> > Announcement: wxHaskell version 0.3
> > 
> ----------------------------------------------------------------------
> >
> > <http://wxhaskell.sourceforge.net>
> >
> > This basically a patch level release against the new wxWindows 2.4.2
> > library. The new library is especially improved for MacOS 
> X, handling
> > redraw events correctly now. Furthermore, there is a new directory
> > with "contributed" samples and there is support for direct image
> > manipulation for fast customized drawing.
> >
> >
> > 
> ----------------------------------------------------------------------
> > 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 wxWindows -- 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 -- 2776 methods in 505
> > classes with 1279 constant definitions.
> >
> > wxHaskell has been build with GHC 6.01 on Windows, MacOS X and Unix
> > systems with GTK. A binary distribution is available for Windows
> > 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>.
> >
> > All the best,
> >   Daan Leijen.
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > wxhaskell-users mailing list
> > wxh...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

RE: [wxhaskell-users] scrolledWindow

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

Hi David,

> Hello.  I'm unclear as to how to get a scrolledWindow to work 
> properly with sizers.  In the following example, I don't get a
scrollbar, 

Well, I am not a wxWindows expert either. However, I think that
you always have to set the "virtualSize" of a scrolled window to get 
the sizer working. In your example, you set the "scrollRate", but
forget to set the "virtualSize". Maybe that is the cause of the
problems?

Hope this helps,
 Daan.

> and can't seem
> to figure out how to make the size of the ScrolledWindow be 
> smaller than
> the size of its contents:
> 
> main = start $ do f<- frame [text := "Test"]
>                   scrolled <- scrolledWindow f
>                               [layout := column 0 $ take 47 labels,
>                                scrollRate := size 10 10]
>                   quit <- button f [text := "Quit", on 
> command := close f]
>                   set f [layout := column 5 [fill $ widget scrolled,
>                                              centre $ widget quit]
> 
> labels = map (floatLeft . label . ("Label "++) . show) [1..]
> 
> I've essentially been trying things at random, but have no 
> real idea as to
> how to make this work right.
> -- 
> David Roundy
> http://www.abridgegame.org/darcs
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] scrolledWindow

[David R. <dr...@jd...>]

Hello.  I'm unclear as to how to get a scrolledWindow to work properly with
sizers.  In the following example, I don't get a scrollbar, and can't seem
to figure out how to make the size of the ScrolledWindow be smaller than
the size of its contents:

main = start $ do f<- frame [text := "Test"]
                  scrolled <- scrolledWindow f
                              [layout := column 0 $ take 47 labels,
                               scrollRate := size 10 10]
                  quit <- button f [text := "Quit", on command := close f]
                  set f [layout := column 5 [fill $ widget scrolled,
                                             centre $ widget quit]

labels = map (floatLeft . label . ("Label "++) . show) [1..]

I've essentially been trying things at random, but have no real idea as to
how to make this work right.
-- 
David Roundy
http://www.abridgegame.org/darcs

Re: [wxhaskell-users] announce: wxhaskell 0.3

[Luc T. <li...@ta...>]

congrats, dan.

feedback from linux:

i installed wx 2.4.2 + dev from rpm on mdk9.1/vmware
and recompile 0.3 from the src.

went fine

most sample went fine, but:
- time flows... : all writing are garbled on the top left corner
- notebookright:  : right note are ok on gtk, bitmap ok, but no action on
righclick
. camels : no action on click

all these effects were already present on 0.2

should i have hacked anything beforehand ?
otherwise, can somebody confirm it works on gtk ? (not gtk 2, or should i ?)

----- Original Message -----
From: "Daan Leijen" <daa...@xs...>
To: <wxh...@li...>
Sent: Wednesday, October 01, 2003 1:01 PM
Subject: [wxhaskell-users] announce: wxhaskell 0.3


> Announcement: wxHaskell version 0.3
> ----------------------------------------------------------------------
>
> <http://wxhaskell.sourceforge.net>
>
> This basically a patch level release against the new wxWindows 2.4.2
> library. The new library is especially improved for MacOS X, handling
> redraw events correctly now. Furthermore, there is a new directory
> with "contributed" samples and there is support for direct image
> manipulation for fast customized drawing.
>
>
> ----------------------------------------------------------------------
> 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 wxWindows -- 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 -- 2776 methods in 505
> classes with 1279 constant definitions.
>
> wxHaskell has been build with GHC 6.01 on Windows, MacOS X and Unix
> systems with GTK. A binary distribution is available for Windows
> 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>.
>
> All the best,
>   Daan Leijen.
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] announce: wxhaskell 0.3

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

Announcement: wxHaskell version 0.3
----------------------------------------------------------------------

<http://wxhaskell.sourceforge.net>

This basically a patch level release against the new wxWindows 2.4.2
library. The new library is especially improved for MacOS X, handling
redraw events correctly now. Furthermore, there is a new directory 
with "contributed" samples and there is support for direct image
manipulation for fast customized drawing.


----------------------------------------------------------------------
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 wxWindows -- 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 -- 2776 methods in 505
classes with 1279 constant definitions.

wxHaskell has been build with GHC 6.01 on Windows, MacOS X and Unix 
systems with GTK. A binary distribution is available for Windows 
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>.

All the best,
  Daan Leijen.