wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] RE: [GUI] Announce: wxHaskell 0.2

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

> Thanks for the release.  0.2 seems to build much better on Linux. :)
> I built an rpm package with ghc-6.0.1 for wxGTK2 and put it at

Thanks! I'll try it out and put it on sourceforge (if that 
is ok with you). I also like your naming scheme, I guess I should
also include the ghc version and processor in the name of binary
releases.  (btw. what does the extra "-2" mean in the version?
(like wxhaskell-ghc6.0.1-0.2-2.i386.rpm)

-- Daan




> 
	http://juhp.dyndns.org/jens/haskell/

for now.  They should be available from later

	http://haskell.org/~petersen/rpms/wxhaskell/

(current public_html seems to be disabled on haskell.org).

Jens
_______________________________________________
GUI mailing list
GU...@ha...
http://www.haskell.org/mailman/listinfo/gui

RE: [wxhaskell-users] wxHaskell + GHCi + Mac OS X

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

Wow Wolfgang -- how do you know about these devil-ish things!! :-)

Thanks for the contribution. I think I'll put it on the 
webpage with the macosx notes.

-- Daan.

> -----Original Message-----
> From: wxh...@li... 
> [mailto:wxh...@li...] On 
> Behalf Of Wolfgang Thaller
> Sent: woensdag 17 september 2003 22:11
> To: wxh...@li...
> Subject: [wxhaskell-users] wxHaskell + GHCi + Mac OS X
> 
> 
> The wxHaskell website says:
> > Furthermore, most wxHaskell applications do not work correctly when 
> > started from GHCi (and it is unclear what exactly causes this 
> > problem).
> 
> Mac OS X distinguishes between GUI processes and "background only" 
> processes. A program that does not have the right extra 
> information (a 
> Mac OS resource fork or an Info.plist in a .app wrapper), is a 
> background only process by default. For reasons of tradition (it's 
> almost theoretically impossible in Mac OS 9), there's no 
> documented way 
> to change the status of a process from "background only" to "GUI app".
> ... but there's an undocumented way to do it!
> 
> The attached module contains enableGUI :: IO (), which makes the 
> current process a GUI process and brings it to the front.
> 
> Notes:
> It uses undocumented functions (four of them, actually); therefore I 
> don't recommend including this in wxHaskell's start function. 
> Programs 
> that use or even just link to this  function might not run on future 
> versions of Mac OS X.
> It is OK to invoke enableGUI as often as you want, even when it's not 
> necessary.
> The menu bar sometimes stays blank when the application is not in the 
> foreground when it is initialized. Therefore, don't issue 
> enableGUI and 
> main as separate commands in GHCi, use enableGUI >> main instead.
> 
> 

[wxhaskell-users] wxHaskell + GHCi + Mac OS X

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

The wxHaskell website says:
> Furthermore, most wxHaskell applications do not work correctly when 
> started from GHCi (and it is unclear what exactly causes this 
> problem).

Mac OS X distinguishes between GUI processes and "background only" 
processes. A program that does not have the right extra information (a 
Mac OS resource fork or an Info.plist in a .app wrapper), is a 
background only process by default. For reasons of tradition (it's 
almost theoretically impossible in Mac OS 9), there's no documented way 
to change the status of a process from "background only" to "GUI app".
... but there's an undocumented way to do it!

The attached module contains enableGUI :: IO (), which makes the 
current process a GUI process and brings it to the front.

Notes:
It uses undocumented functions (four of them, actually); therefore I 
don't recommend including this in wxHaskell's start function. Programs 
that use or even just link to this  function might not run on future 
versions of Mac OS X.
It is OK to invoke enableGUI as often as you want, even when it's not 
necessary.
The menu bar sometimes stays blank when the application is not in the 
foreground when it is initialized. Therefore, don't issue enableGUI and 
main as separate commands in GHCi, use enableGUI >> main instead.

Re: [wxhaskell-users] Re: [GUI] RE: Announce: wxHaskell 0.2

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

Let me provide a few comments about the C++ linking story....

Sven Panne wrote:

> No, it is not: A library has no "runtime system", it's usually the 
> startup
> code [...]. And you get the
> correct startup code for the language you are using (C vs. C++) "under 
> the
> hood" when linking your application together.

On Mac OS X, Windows/Mingw32 and RedHat Linux 8, you get the same 
startup code no matter whether you use gcc or g++. The only difference 
between the gcc and g++ linker drivers is that g++ adds -lstdc++.
On Mac OS X, every dynamic library gets it's own startup code (haven't 
checked on Linux or Windows, but I guess it's the same).

Daan Leijen:

> Yes! otherwise we *do* get all those C vs. C++ linking problems that
> you describe. Actually, on most platforms you can't even link in C++
> code
> due to all kinds of linking errors with the standard C libraries (stdc
> vs. stdc++)
>
> Maybe GHC can be convinced to use the C++ compiler to compile all its
> stuff?? That would surely solve our problems.

A small mixed C++ & Haskell test program, runs fine on Mac OS X, 
Windows and RedHat 8 when I add -lstdc++ to the command line.
On Windows, there's of course the problem that GHC includes it's own 
copy of GCC, but no C++ includes, but I happen to have another copy of 
them :-).
While being short, my test program uses static constructors and 
destructors, and it calls the C++ standard library (iostream and 
string, to be exact), and everything works perfectly. What kinds of 
problems did you experience?

GHCi, on the other hand, cannot currenlty load C++ object files (nor 
can it currently load the C++ standard library on systems where it's a 
static library), so using dynamic libraries is definitely necessary at 
least during development. Of course, it would be nice if I could just 
statically link my wxHaskell application when I'm done, but GHCi is 
more important.

Cheers,

Wolfgang

[wxhaskell-users] inheritance using type classes

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

Hi all,

(Sorry for the long mail and pollution of the mailing list, but
I would like to say a bit more about the trade-offs when modelling=20
inheritance using type classes versus phantom types.)

Alle 22:18, marted=EC 16 settembre 2003, Daan Leijen ha scritto:
> This is a devious thing to do, but totally unavoidable given the way
> I model inheritance with phantom types. I have considered using=20
> type classes to model the inheritance but that leads to a) other=20
> dependencies on extensions, b) hard to understand error messages,=20
> and c) a much more complex model. (See Andre Pang's master thesis=20
> for a ingenious way to model full inheritance)

Inheritance can be modelled fully with type classes but leads to a=20
complicated system that depends on many extensions to work in practice=20
(like MPTC and functional dependencies). That is why I used phantom=20
types to model inheritance in wxHaskell -- simplicity!=20

However, I just realized that with the proper restrictions, there also=20
exists a reasonably simple inheritance model using just haskell98 type=20
classes. (There is a catch of course, but more on that later). Most=20
complications normally arise as we also want to model object methods=20
that are overloaded on their type signatures (like java and c++=20
allow). For wxHaskell though, we don't need to do this, as no such=20
overloading occurs.

This allows us to "lift" the object methods out of a haskell class=20
declaration and to model only the inheritance relationship with type=20
classes.

Here is how it works concretely: In the Haskell world, each object is=20
in the end represented by a pointer, say "Addr". So, we can make a=20
class that returns this pointer for each haskell object.

> class Object object where
>   self :: object -> Addr

Now, suppose we have a "Window" class with a creation method and show=20
method. First, we create a type that represents this class in Haskell,=20
and we'll call "WindowObject".

> newtype WindowObject  =3D WindowObject Addr
>
> windowCreate :: IO WindowObject
> windowCreate =3D do{ addr <- primWindowCreate;
                     return (WindowObject addr) }

Next, we model the inheritance using a (phantom) type class and=20
instance.

> class Object window =3D> Window window
>
> instance Object WindowObject where
>   self (WindowObject addr) =3D addr
>
> instance Window WindowObject

The "show" method is written as:

> windowShow :: Window window =3D> window -> IO ()
> windowShow window
>    =3D primWindowShow (self window)

Note that the inferred type is "Object w =3D> w -> IO ()", but we want=20
to constrain it by hand to windows only. Furthermore, we don't use a=20
"WindowObject" as the argument, as we want to be able to pass *any*=20
kind of Window to this function.

For example, a Button object derives from a Control, that in turn=20
derives from the Window class:

> newtype ButtonObject  =3D ButtonObject Addr
>
> class Control button =3D> Button button
>
> instance Object ButtonObject where
>   self (ButtonObject addr) =3D addr
>
> instance Window ButtonObject
> instance Control ButtonObject
> instance Button ButtonObject
>
> buttonCreate :: IO ButtonObject
> ...
> buttonSetLabel :: Button button =3D> button -> String -> IO ()
> ...

Clearly, we can now use the "windowShow" method on "ButtonObjects" too=20
-- exactly what we want. Furthermore, we can also downcast objects:

> downcastWindow :: Window window =3D> window -> WindowObject
> downcastWindow window  =3D WindowObject (self window)

Up till now, there is not much advantage with regard to using phantom=20
types: the effect is the same and the types with overloading are bit=20
more complicated. However, there may be some other advantages.

Suppose I want to create more abstraction and use a type class=20
"Textual" that retrieves some text from an object.=20

> class Textual w where
>   text :: w -> IO String

We use a type class here since we want to use "text" on both the=20
objects imported from the library, but also on user defined data=20
types. Suppose that every window has "windowGetLabel" method. This=20
means that we define "Textual" for any kind of window in one go:

> instance Window w =3D> Textual w where
>   text =3D windowGetLabel

I use the same trick when using phantom types (the free "a" type=20
variable encodes the "any kind of window"):

> instance Textual (Window a) where
>   text =3D windowGetLabel

The attentative reader now notices that both instance declarations are=20
illegal in haskell98 and require the "allow undecidable instances"=20
flag (i.e. the context reducer could loop). Furthermore, the latter=20
also uses a type synonym but that is easy to circumvent (Window a =3D=3D =

Ptr (CWxObject (CEvtHandler (CWindow a)))

However, there is an important difference -- If we really want, we=20
could replace the first instance declaration with a specific instance=20
declaration for each kind of object:

> instance Textual WindowObject
> instance Textual ControlObject
> instance Textual ButtonObject
> ....

This would be haskell98 compliant. Unfortunately, no such thing can be=20
done with phantom types (as the instance heads remain "complex", even=20
though they are always "decidable" (i.e. reduce without looping)).

Given the more complex type signatures and error messages, I=20
personally find the price too high. Especially since in the wxhaskell=20
case the amount of instance declarations would rise from a single=20
declaration to hundreds of instance declarations for each kind of=20
widget. But maybe this gives at least some more insight in the=20
different trade-offs that we can make.

All the best,
 Daaan.

RE: [wxhaskell-users] Re: [GUI] RE: Announce: wxHaskell 0.2

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

Hi Sven,

> Well, if you like it or not: You'll have to handle 
> versionitis somehow. The upcoming GHC 6.2 will need that flag, too.

Yes, I will handle versionitis :-) Just not CVS heads.

> > I am quite sure that this has nothing to do with C vs. C++ :-)
> > [snip]
>
> No, it is not: A library has no "runtime system", it's 
> [snip]

I am quite sure that the startup code is correctly executed as all the
C++ code is in a separate dynamic link library, and not linked in as an 
object file. One reason that I think it is ok is that I am using the 
same system as the wxEiffel people and they have used this on many unix 
and windows systems, even with the LCC compiler to compile their eiffel
C code, and GCC to compile the C++ code. The wxPython project also
combines it in the same kind of way.

So, that is why I think we should first look at other causes for
your segfault. Especially since no such problems have occurred on my
test platforms: Red hat linux, Gentoo linux, and FreeBSD with GTK 1.2
and 2+.

> Another suspect is casting: I'm not quite sure what you are 
> doing in the low-level parts, but I see a lot of casts. The problem
is: In 
> C++, casting is not necessarily value preserving for pointers in the 
> presence of multiple inheritance (or virtual base classes, IIRC).

Oh yeah, it is terrible on the low-level. My own extensions already use
a typed interface without casting. However, remember that this is
code that comes directly from the wxEiffel project and has been
tested quite well over the years (and is semi-automatically generated).
(and they are not "real" casts: just "void*" to class* -- not casts
between classes).

Maybe one day, the wx.NET binding gets far enough -- this is a 
somewhat cleaner binding that also lends itself well to automatic
marshalling generation.

> I was thinking of something like an -rpath option for the 
> linker, so that the resulting executable would automatically find the
dynamic 
> library. BTW, do we really need a *dynamic* library here?

Yes! otherwise we *do* get all those C vs. C++ linking problems that
you describe. Actually, on most platforms you can't even link in C++
code
due to all kinds of linking errors with the standard C libraries (stdc
vs. stdc++)

Maybe GHC can be convinced to use the C++ compiler to compile all its
stuff?? That would surely solve our problems.

For now, the user just has to fiddle with dynamic libraries but I'll
look into
the -rpath option. For the MacOSX installer, we just fix the path :-) 
(/usr/local/wxhaskell) (just as the GHC installer does btw).

Question: I do use the "--soname" option when linking everything, maybe
I
can just put a full install path over there?

Cheers,
 Daan.

> 
> Cheers,
>     S.
> 
> 
> 
> 
> -------------------------------------------------------
> 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] Re: [GUI] RE: Announce: wxHaskell 0.2

[Sven P. <Sve...@in...>]

[ Removed Haskell list from Cc:, it's becoming a bit wxHaskell specific... ]

Daan Leijen wrote:
>>  * You need `-package parsec' for linking wxdirect nowadays.
> 
> Thanks for the hints. I'll look into it for a future version.
> I will not actively support CVS GHC's though -- that will be too much
> work :-)

Well, if you like it or not: You'll have to handle versionitis somehow. The
upcoming GHC 6.2 will need that flag, too.

>>  * When HelloWorld terminates, it segfaults in wxVariant()'s 
>>destructor. [...]
> I am quite sure that this has nothing to do with C vs. C++ :-)
> (I am not linking at all with C++ directly -- instead I am using extern C
> wrappers that are used in a separate dynamic link library with their own
> C++ runtime system. This is just like calling any other systems library.)

No, it is not: A library has no "runtime system", it's usually the startup
code which cares for things like global constructors/destructors, sets up
exception handling, initializes the memory allocator, etc. And you get the
correct startup code for the language you are using (C vs. C++) "under the
hood" when linking your application together. At least that's the story for
*nix systems I'm aware of, I don't have a clue on WinDoze. One of the
problems with wxHaskell currently is that the applications are linked together
(via GHC) with a C compiler, not a C++ one.

> The segfault is really weird though -- it might be that you started
> "main" twice from GHCi (a known bug in wxGTK),

Nope, I used GHC and started the resulting executable directly.

> that your GHC is broken,

The usual "help desk" answer... ;-)

> that you use an old GTK,

I'm on the bleeding edge already, doing regular online updates of my SuSE
system.

> anything really.... :-(

Another suspect is casting: I'm not quite sure what you are doing in the
low-level parts, but I see a lot of casts. The problem is: In C++, casting
is not necessarily value preserving for pointers in the presence of multiple
inheritance (or virtual base classes, IIRC).

>>  * The package configuration should include linker flags for 
>>the path of libwxc.so, otherwise a non-superuser has to fiddle around
>> with LD_LIBRARY_PATH and the like.
> 
> I am fairly hesitant here -- this means that I need two different package
> description files -- one for binary installs and one for developer installs.
> I'll look into it, but since I am not a real unix wizard, maybe you can
> tell me offline what you exactly need/want.

I was thinking of something like an -rpath option for the linker, so that the
resulting executable would automatically find the dynamic library. BTW, do we
really need a *dynamic* library here?

Cheers,
    S.

[wxhaskell-users] RE: Announce: wxHaskell 0.2

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

Hi Sven,

(I'll reply to the portability issues in a separate mail)

>   * It would be nice if the directory created by unzipping 
> wxhaskell-src-0.2.zip  contained a version number.
> 
>   * It would be even nicer if wxhaskell-doc-0.2.zip unzipped 
> into a *single*  directory.
> 
>   * You need `-package parsec' for linking wxdirect nowadays.

Thanks for the hints. I'll look into it for a future version.
I will not actively support CVS GHC's though -- that will be too much
work :-)

>   * When HelloWorld terminates, it segfaults in wxVariant()'s 
> destructor. I have no idea what's going on here, but I can only repeat
my 
> warnings stated some time ago: Mixing a C++ library with pure C (=
GHC's code) 
> is a highly  delicate, platform/compiler dependent and fragile thing
to do...

I am quite sure that this has nothing to do with C vs. C++ :-)
(I am not linking at all with C++ directly -- instead I am using extern
C
wrappers that are used in a separate dynamic link library with their own
C++ runtime system. This is just like calling any other systems library.
)

The segfault is really weird though -- it might be that you started
"main" twice
from GHCi (a known bug in wxGTK), that your GHC is broken, that you use
an
old GTK, anything really.... :-(

>   * The package configuration should include linker flags for 
> the path of libwxc.so, otherwise a non-superuser has to fiddle around
with
>     LD_LIBRARY_PATH and the like.

I am fairly hesitant here -- this means that I need two different
package
description files -- one for binary installs and one for developer
installs.
I'll look into it, but since I am not a real unix wizard, maybe you can
tell me offline what you exactly need/want.

All the best,
 Daan.

[wxhaskell-users] RE: Announce: wxHaskell 0.2

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

Hi Sven,

> the library documentation says: "Portability: 
> portable", but this is not the case at all, wxHaskell uses 
> quite a few extensions (apart from the FFI, which can be 
> considered portable nowadays):

wxHaskell consists of two layers: WXCore and WX.

The WXCore layer is supposed to be totally Haskell98 compatible
(or really easy to make compatible).

The WX layer is a nice haskellized version of the wxWindows
API on top of WXCore that uses extensions.

>   * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around 
> with unboxed values and GHC interna for performance reasons. Is this 
> really necessary?   (Apart from that, it triggers a bug in GHC's new
Lexer :-}

No, it is not. Actually on <http://www.cs.uu.nl/~daan/ddata.html> you
can
find a Hugs98 and "standard" haskell98 version. I just used this one as
I only
use GHC but it can easily be replaced.

>   * The default declaration of setBitMask in
wx/src/Graphics/UI/WX/Types.hs uses
>     a scoped type variable. This could probably be rewritten to
something more
>     portable.

Thanks for the hint. I'll remove the type declaration.

>   * wx/src/Graphics/UI/WX/Attributes.hs uses existentially 
> quantified data constructors (:=, :~, ::=, and ::~) for purely 
> aesthetical reasons.

Yes, I am considering changing it to "=:" operators, that look less
nice,
but remove the dependency on rank-2 polymorphism. However, I haven't
removed them yet as 1) not enough people complained, 2) any serious
haskell 
compiler supports "forall" now, and 3) the (:=) operator looks *really*
good, 
and 4) I depend on more devious things already which are harder to
avoid, namely:

>   * Type synonyms in instance heads + complex instance heads are quite
pervasive:

This is a devious thing to do, but totally unavoidable given the way I
model
inheritance with phantom types. I have considered using type classes to
model
the inheritance but that leads to a) other dependencies on extensions,
b) hard
to understand error messages, and c) a much more complex model. (See
Andre Pang's
master thesis for a ingenious way to model full inheritance)

On the other hand, phantom type inheritance is easy *and* using type
synonyms
in instance heads is *very* convenient (a huge improvement compared to
all the
instance declarations I had to write for GIO). (So, I guess I am making
a case for
supporting this extension in future Haskells as it is so useful).

>   * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with 
> functional dependencies.

Hmm, yes, but these could be removed -- they are not very important.

> I don't want to sound too negative, Daan has done an 
> impressive job, but I'm a bit concerned about all this 
> non-portable stuff when we are planning to use wxHaskell as 
> the basis for our GUI efforts.

I share your concerns. However, keep in mind that WXCore is Haskell98 +
FFI,
and that only the nicified abstraction WX uses extensions. That is,
anyone can
build another nicified abstraction that is H98 compatible. However, it
seems that
for "real" libraries, one wants a bit more power.

In the end though, I would like wxHaskell to be an open community effort
and not to
be "daan's" library. In that sense, anyone can change the libraries
interface if
enough people support that. I am not emotionally attached to my design
and will certainly
support people that want to change or fix the library (especially given
my lack
of time to spend on this project :-). 


All the best, and thanks for your comments,
  Daan.

> Cheers,
>     S.
> 
> 
> _______________________________________________
> Haskell mailing list
> Ha...@ha... http://www.haskell.org/mailman/listinfo/haskell
> 
> 

[wxhaskell-users] Re: Announce: wxHaskell 0.2

[Sven P. <Sve...@in...>]

I just had a look at wxHaskell (GHC from CVS, about a week old, SuSE
Linux 8.2 on x86). A few remarks:

  * It would be nice if the directory created by unzipping wxhaskell-src-0.2.zip
    contained a version number.

  * It would be even nicer if wxhaskell-doc-0.2.zip unzipped into a *single*
    directory.

  * You need `-package parsec' for linking wxdirect nowadays.

  * When HelloWorld terminates, it segfaults in wxVariant()'s destructor. I have
    no idea what's going on here, but I can only repeat my warnings stated some
    time ago: Mixing a C++ library with pure C (= GHC's code) is a highly
    delicate, platform/compiler dependent and fragile thing to do...

  * The package configuration should include linker flags for the path of
    libwxc.so, otherwise a non-superuser has to fiddle around with
    LD_LIBRARY_PATH and the like.

Furthermore, the library documentation says: "Portability: portable", but this
is not the case at all, wxHaskell uses quite a few extensions (apart from the
FFI, which can be considered portable nowadays):

  * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around with unboxed
    values and GHC interna for performance reasons. Is this really necessary?
    (Apart from that, it triggers a bug in GHC's new Lexer :-}

  * The default declaration of setBitMask in wx/src/Graphics/UI/WX/Types.hs uses
    a scoped type variable. This could probably be rewritten to something more
    portable.

  * wx/src/Graphics/UI/WX/Attributes.hs uses existentially quantified data
    constructors (:=, :~, ::=, and ::~) for purely aesthetical reasons.

  * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with functional dependencies.

  * Type synonyms in instance heads + complex instance heads are quite pervasive:
    wx/src/Graphics/UI/WX/{Events,Window,Frame,Menu,Timer,Draw,Controls,Dialogs}.hs
    wxcore/src/Graphics/UI/WXCore/Layout.hs

I don't want to sound too negative, Daan has done an impressive job, but I'm a
bit concerned about all this non-portable stuff when we are planning to use
wxHaskell as the basis for our GUI efforts.

Cheers,
    S.

[wxhaskell-users] Announce: wxHaskell 0.2

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

Announcement: wxHaskell version 0.2 
----------------------------------------------------------------------

<http://wxhaskell.sourceforge.net>

The new release has (improved) support for tree controls, list 
controls, toolbars, splitter windows, sliders, gauges, and bitmap
buttons. Screenshots of these widgets on different platforms have been
added to the website. Furthermore, there are numerous small bug fixes,
especially for wxGTK. A list of non-compatible changes is attached at 
the end of this mail.

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

wxHaskell has been build with GHC 6.0/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.


ps. More funny statistics: the wxWindows libraries have been 
downloaded over a million times at sourceforge! The Python binding to 
wxWindows (wxPython) about 600.000 times, and the Haskell binding
to wxWindows about 100 times :-)


----------------------------------------------------------------------
Breaking changes to version 0.1:

- Renamed the "WXH" layer to "WXCore". 
  > import Graphics.UI.WXCore
  instead of 
  > import Graphics.UI.WXH

- Changed the interface of menu items a bit. The label and help text 
  is now  supplied via attributes:
  > medit    <- menuPane       [text := "&Edit"]
  > mfont    <- menuItem medit [text := "&Font...\tCtrl+F"
  >                            ,help := "Set the font"]
 

RE: [wxhaskell-users] drag and drop, notebook, bitmapbuttons, rightclick

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

Thanks for you sample Luc!  
I'll add it to the CVS tree and it will ship in version 0.2.
 
 

Still, one glitch is the popupmenu that I was expecting near the button,
not top left.
Also, I did not use a Use a "wxBitmapButton" as u mentions, I did not
found it, neither what it should provides.. hm ? 

Well, a wxWindows type "wxBitmapButton" is translated as
"bitmapButtonCreate" in "WxcClasses".
When I create abstractions in the "WX" library, I remove the "Create"
bit, and call it "bitmapButton".
The abstractions take for example a list of attributes as arguments etc.
 
-- Daan.

 
{-| 
    Author      :   Luc Taesch 2003
    
 
    Maintainer  :  da...@cs...
    Stability   :  provisional
    Portability :  portable ? (tested on XP)
    
    Illustrate more controls from wxHaskell, Hacked from Controls.hs (
Daan Leijen 2003)
    namely bitmapButtons, righ click menus, vertical labels on
notebooks, usage of tooltips
-}
 
module Main where
 
import Graphics.UI.WX
import Graphics.UI.WXH 
 
main :: IO ()
main
  = start gui
 
gui :: IO ()
gui
  = do -- main gui elements: frame, panel, text control, and the
notebook
       f       <- frame [text := "Controls" ]
       p       <- panel f []
       nb      <- notebook2 p []
       textlog <- textCtrl p WrapLine [enable := False]
       file  <- menuList "&File" []
       aRightClick  <- menuItem file "Say Something\tCtrl+Q" "An
interesting Message" [] 
 


       -- use text control as logger
       textCtrlMakeLogActiveTarget textlog
       logMessage "logging enabled"              
 
       -- button page
       p1   <- panel  nb [text := "buttons"]
       bm <- bitmapCreateFromFile ".\\haskell_icon.gif"
       ok   <- bitmapButton p1 0 bm [text := "Ok", on command :=
logMessage "bitmap button pressed", 
                                     tooltip := "tooltip",
                                     on clickRight := (\pt -> menuPopup
file pt p)]
 

       -- specify layout
       set f [layout :=
                container p $
                column 0
                 [ tabs nb
                    [container p1 $ margin 10 $ floatCentre $ row 5  
                      $ [widget ok]
   ]
                 , hfill $ widget textlog                 
                 ]
                 , on (menu aRightClick) := infoDialog f "Say.."
"Something"
             , clientSize := sz 400 300 ]
       return ()
 
  where
    logSelect labels w
      = do i <- get w selection
           s <- get w (item i)
           logMessage ("selected index: " ++ show i ++ ": " ++ s)
           
 

-- like notebook, with labels created on the side ( rather than on top):
wxNB_RIGHT
notebook2 parent props 
  = do nb <- notebookCreate parent idAny rectNull ( wxCLIP_CHILDREN +
wxNB_RIGHT)
       set nb props
       return nb
       
-- like buttonEx, with a bitmap instead of the label 
bitmapButton parent flags bm props 
  = do --bm <- bitmapCreateFromFile ".\\haskell_icon.gif"
       b <- bitmapButtonCreate parent idAny bm  rectNull flags
       set b props
       return b
 

 

----- Original Message ----- 
From: Daan  <mailto:daa...@xs...> Leijen 
To: 'Luc Taesch' <mailto:li...@ta...>  ;
wxh...@li... 
Sent: Monday, September 01, 2003 11:36 AM
Subject: [wxhaskell-users] drag and drop, notebook, bitmapbuttons,
rightclick


Hi Luc,
 
I will just answer all your questions in one go :-)

does wxhaskell support drag and drop ? 

No, not yet. It needs some more C wrapper support. However,
it is easy to add and it will be there in version 0.3 or something.
(I plan to release 0.2 in a few weeks). (unless you add it for me and
send me the patches... see wxDropTarget and friends).
 

 >  Is there any (layout ?) possibilities to have the notebook "buttons"
on the (right side) rather than on the top ? 
 
Yes. You have to create the notebook with the "wxNB_RIGHT" flag.  Look
at the
source code in "WX.Controls" to see how to create a notebook control.
(it seems from the docs though that "wxNB_RIGHT" is not supported yet by

wxWindows under windowsXP).
 
 >  doew wxhaskell  support  bitmapbuttons ? 
 
Yes. Use a "wxBitmapButton". with "bitmapButtonCreate".
 
 > does wxHaskell support  rightclick menu, an dideally specific to an
area , say on a button ?
 
Yes. Use "on clickRight" together with "menuPopup".
 
I hope this helps,
All the best.
  Daan.
 
ps. I think you could have answered the last three questions yourself by

studying the documentation and samples. Don't worry though :-), I am
very
happy that you use my stuff and I have no problem answering any
questions at all -- however, any time I spend on email can't be spend on
advancing wxHaskell. Therefore, try to experiment and study the docs a
little
bit before asking questions. 

Re: [wxhaskell-users] drag and drop, notebook, bitmapbuttons, rightclick

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

MessageDaan, here is a small contribution example, built on your =
explanations.
It may fit in the samples, to illustrate these interesting features from =
wxHaskell. it needs a bitmap in the current directory, say =
haskell_icon.gif

You will note that "wxNB_RIGHT" seems to work on XP, finally.

Still, one glitch is the popupmenu that I was expecting near the button, =
not top left.
Also, I did not use a Use a "wxBitmapButton" as u mentions, I did not =
found it, neither what it should provides.. hm ?

{-|=20
    Author      :   Luc Taesch 2003
   =20

    Maintainer  :  da...@cs...
    Stability   :  provisional
    Portability :  portable ? (tested on XP)
   =20
    Illustrate more controls from wxHaskell, Hacked from Controls.hs ( =
Daan Leijen 2003)
    namely bitmapButtons, righ click menus, vertical labels on =
notebooks, usage of tooltips
-}

module Main where

import Graphics.UI.WX
import Graphics.UI.WXH=20

main :: IO ()
main
  =3D start gui

gui :: IO ()
gui
  =3D do -- main gui elements: frame, panel, text control, and the =
notebook
       f       <- frame [text :=3D "Controls" ]
       p       <- panel f []
       nb      <- notebook2 p []
       textlog <- textCtrl p WrapLine [enable :=3D False]
       file  <- menuList "&File" []
       aRightClick  <- menuItem file "Say Something\tCtrl+Q" "An =
interesting Message" []=20


       -- use text control as logger
       textCtrlMakeLogActiveTarget textlog
       logMessage "logging enabled"             =20

       -- button page
       p1   <- panel  nb [text :=3D "buttons"]
       bm <- bitmapCreateFromFile ".\\haskell_icon.gif"
       ok   <- bitmapButton p1 0 bm [text :=3D "Ok", on command :=3D =
logMessage "bitmap button pressed",=20
                                     tooltip :=3D "tooltip",
                                     on clickRight :=3D (\pt -> =
menuPopup file pt p)]

=20
       -- specify layout
       set f [layout :=3D
                container p $
                column 0
                 [ tabs nb
                    [container p1 $ margin 10 $ floatCentre $ row 5 =20
                      $ [widget ok]
   ]
                 , hfill $ widget textlog                =20
                 ]
                 , on (menu aRightClick) :=3D infoDialog f "Say.." =
"Something"
             , clientSize :=3D sz 400 300 ]
       return ()

  where
    logSelect labels w
      =3D do i <- get w selection
           s <- get w (item i)
           logMessage ("selected index: " ++ show i ++ ": " ++ s)
          =20


-- like notebook, with labels created on the side ( rather than on top): =
wxNB_RIGHT
notebook2 parent props=20
  =3D do nb <- notebookCreate parent idAny rectNull ( wxCLIP_CHILDREN + =
wxNB_RIGHT)
       set nb props
       return nb
      =20
-- like buttonEx, with a bitmap instead of the label=20
bitmapButton parent flags bm props=20
  =3D do --bm <- bitmapCreateFromFile ".\\haskell_icon.gif"
       b <- bitmapButtonCreate parent idAny bm  rectNull flags
       set b props
       return b



  ----- Original Message -----=20
  From: Daan Leijen=20
  To: 'Luc Taesch' ; wxh...@li...=20
  Sent: Monday, September 01, 2003 11:36 AM
  Subject: [wxhaskell-users] drag and drop, notebook, bitmapbuttons, =
rightclick


  Hi Luc,

  I will just answer all your questions in one go :-)
    does wxhaskell support drag and drop ?=20
  No, not yet. It needs some more C wrapper support. However,
  it is easy to add and it will be there in version 0.3 or something.
  (I plan to release 0.2 in a few weeks). (unless you add it for me and
  send me the patches... see wxDropTarget and friends).

   >  Is there any (layout ?) possibilities to have the notebook =
"buttons" on the (right side) rather than on the top ?=20

  Yes. You have to create the notebook with the "wxNB_RIGHT" flag.  Look =
at the
  source code in "WX.Controls" to see how to create a notebook control.
  (it seems from the docs though that "wxNB_RIGHT" is not supported yet =
by=20
  wxWindows under windowsXP).

   >  doew wxhaskell  support  bitmapbuttons ?=20

  Yes. Use a "wxBitmapButton". with "bitmapButtonCreate".

   > does wxHaskell support  rightclick menu, an dideally specific to an =
area , say on a button ?

  Yes. Use "on clickRight" together with "menuPopup".

  I hope this helps,
  All the best.
    Daan.

  ps. I think you could have answered the last three questions yourself =
by=20
  studying the documentation and samples. Don't worry though :-), I am =
very
  happy that you use my stuff and I have no problem answering any
  questions at all -- however, any time I spend on email can't be spend =
on
  advancing wxHaskell. Therefore, try to experiment and study the docs a =
little
  bit before asking questions.=20

[wxhaskell-users] drag and drop, notebook, bitmapbuttons, rightclick

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

Hi Luc,
 
I will just answer all your questions in one go :-)

does wxhaskell support drag and drop ? 

No, not yet. It needs some more C wrapper support. However,
it is easy to add and it will be there in version 0.3 or something.
(I plan to release 0.2 in a few weeks). (unless you add it for me and
send me the patches... see wxDropTarget and friends).
 
 >  Is there any (layout ?) possibilities to have the notebook "buttons"
on the (right side) rather than on the top ? 
 
Yes. You have to create the notebook with the "wxNB_RIGHT" flag.  Look
at the
source code in "WX.Controls" to see how to create a notebook control.
(it seems from the docs though that "wxNB_RIGHT" is not supported yet by

wxWindows under windowsXP).
 
 >  doew wxhaskell  support  bitmapbuttons ? 
 
Yes. Use a "wxBitmapButton". with "bitmapButtonCreate".
 
 > does wxHaskell support  rightclick menu, an dideally specific to an
area , say on a button ?
 
Yes. Use "on clickRight" together with "menuPopup".
 
I hope this helps,
All the best.
  Daan.
 
ps. I think you could have answered the last three questions yourself by

studying the documentation and samples. Don't worry though :-), I am
very
happy that you use my stuff and I have no problem answering any
questions at all -- however, any time I spend on email can't be spend on
advancing wxHaskell. Therefore, try to experiment and study the docs a
little
bit before asking questions. 

[wxhaskell-users] bitmapbuttons , rightclick

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

doew wxhaskell  support=20
- bitmapbuttons ?
- rightclick menu, an dideally specific to an area , say on a button ?

[wxhaskell-users] notebook on the side (resubmit)

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

Is there any (layout ?) possibilities to have the notebook "buttons" on =
the (right side) rather than on the top ?

(i need to have a fist series of notebook with buttons on the top), and =
a second on the side).
by buttons , i mean the label that activate the notebook.

thanks for the great job.
Luc

[wxhaskell-users] drag and drop

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

does wxhaskell support drag and drop ?

e.g. with IE , i drag a file / url in a   wxhaskell windows, and my =
application is notified, and receive that link passed ?

[wxhaskell-users] notebook on the side

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

Is there any (layout ?) possibilities to have the notebook "buttons" on =
the (right side) rather than on the top ?

(i need to have a fist series of notebook with buttons on the top), and =
a second on the side).
by buttons , i mean the label that activate the notebook.

thanks for the great job.
Luc

AW: [wxhaskell-users] IO String to String

[<Mar...@in...>]

If your modification function is foo, then try it
like this:
 do
   theString <- textCtrlGetValue -- theString will be of type String
   let result =3D foo theString

And forget about unsafePerformIO. It's like opening the
box of pandora.


--
Markus Schnell
Infineon Technologies AG, CPR ET
Tel +49 (89) 234-20875


> -----Urspr=FCngliche Nachricht-----
> Von: David [mailto:ron...@ya...]=20
> Gesendet: Sonntag, 24. August 2003 16:53
> An: wxh...@li...
> Betreff: [wxhaskell-users] IO String to String
>=20
>=20
>  The function "textCtrlGetValue" returns a IO String. I need=20
> to modificate=20
> this string. How can i use it as a string? I mean, how can i=20
> convert an "IO=20
> a" to a simply "a"?
>=20
> --=20
> Using M2, Opera's revolutionary e-mail client:=20
> http://www.opera.com/m2/
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a=20
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click=20
> here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>=20

Re: [wxhaskell-users] IO String to String

[Arie M. <ami...@cs...>]

> The function "textCtrlGetValue" returns a IO String.
> I need to modificate this string. How can i use it
> as a string?

You should read about the concept of monadic IO in Haskell, since that will
probably answer your question. That will tell you about the do-construct
that you can use in this situation and its limits.


> I mean, how can i convert an "IO
> a" to a simply "a"?

There is a nasty function called "unsafePerformIO" that does just that, but
you should not use it in this case as it likely does not behave as you might
expect, since textCtrlGetValue depends on the environment (for example, the
state of the control).

---quote from GHC Haskell Libraries pdf---
unsafePerformIO :: IO a -> a
This is the "back door" into the IO monad, allowing IO computation to be
performed at any time. For this to be safe, the IO computation should be
free of side effects and independent of its environment.
---

[wxhaskell-users] IO String to String

[David <ron...@ya...>]

 The function "textCtrlGetValue" returns a IO String. I need to modificate 
this string. How can i use it as a string? I mean, how can i convert an "IO 
a" to a simply "a"?

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

RE: [wxhaskell-users] problem compiling HelloWorld.hs on debian.

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

> I tried again on my home machine, and everything works fine, but using
> debian unstable and debian testing.  The work machine I was using was
a
> mixture of stable and testing, and that may have been the  problem.
Perhaps
> it was an issue of gcc 3.3/2.94 incompatibility.  In any  case, it now
seems
> to work fine.  :)

Good to hear this. Btw. be aware that the latest CVS version has renamed
WXH to WXCore, and that the menu interface has changed slightly.

-- Daan.

> -- 
> David Roundy
> http://www.abridgegame.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a 
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click 
> here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

RE: [wxhaskell-users] where is windowGetAdjustedBestSize?

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

hi Jose,

> Hi. I have noticed some methods, like windowGetAdjustedBestSize, 
> windowSetPosition, etc., have not been implemented (they might be in 
> wxcClasses.hs). Some are redundant, like windowSetPosition, 
> so there is no matter about them. But some like
windowGetAdjustedBestSize 
> can not be simulated with other methods (because it needs to keep
track of 
> manually setted sizes).

You are right. Not everything has been implemented. On the other
hand, it is easy to add a method yourself: add a wrapper to
"wxc/extra.cpp"
and add the type signature to "wxc.h". 

I'll add this one to upcoming 0.2 release. (planned for the end of
september).
If you come across more of these issues, please let me know so that I
can
either add them, or apply your patches (or make you a developer so you
can
commit them yourself).

All the best,
 Daan.


> 
> Actually, it seems not a wxhaskell bug, since the C sources 
> from the ELJ 
> project do not provide these methods (I have checked it, and i.e. 
> wxWindow_GetAdjustedBestSize does not appear). But I got 
> confused when I read 
> at wxEiffel site that they have got the wrap for wxWindow class fully 
> implemented. This can not be true: where is the 
> wxWindow::GetAdjustedBestSize 
> method?
> 
> Regards,
> 
> Jose
> David.
> 
> ---------------------------------------------
> Este mensaje lo ha enviado un Alumno de la Universidad de Malaga.
> http://www.alumnos.uma.es/
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a 
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click 
> here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

RE: [wxhaskell-users] AOL Communicator uses wxWindows :-)

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

Hi Fred,

> I began to use it and I appreciate it so much that I just 
> wrote a paper about it in the french newspaper "L'Informaticien".
> It should be published in october. I will let you know.

You mean that you have already written an article about wxHaskell?!
If that is the case, that would be great :-) I am highly curious --
maybe you can send me copy? (just for fun, as I am quite bad at
french and it will take me ages to translate it. But hey, I am good
enough at it to go snowboarding in France each year :-)

Forgive my curiousity, but were you already familiar with Haskell 
or did you need to learn Haskell too in order to use wxHaskell? 
I am always wondering how big the burden is to learn Haskell.

> (I already wrote many paper about wxWindows and wxPython in 
> some french newspapers)

Good work. I think that wxWindows (and Haskell) deserves more
attention than it is getting now. Not many people are able to
write good articles for a general audience.

All the best,
 Daan.

> 
> 
> Congratulations for wxHaskell!
> 
> Best regard
> 
> Fred
> 
> 
> > Alas, before we can write those slick themed interfaces with
> > wxHaskell, I first have to finish the improved wrappers for
> > the Tree and List controls ;-)
> >
> > -- Daan
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: VM Ware
> > With VMware you can run multiple operating systems on a 
> single machine.
> > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> > at the same time. Free trial click
> here:http://www.vmware.com/wl/offer/358/0
> > _______________________________________________
> > wxhaskell-users mailing list
> > wxh...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
> 

Re: [wxhaskell-users] problem compiling HelloWorld.hs on debian.

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

On Sat, Aug 23, 2003 at 11:43:57AM +0200, Daan Leijen wrote:
> Hi David,
> 
> > I just downloaded the CVS version of wxhaskell.  It compiles 
> > and installs
> > fine with a simple ./configure && make && make install, but I get the
> > following error when I try to compile HelloWorld.hs:
> > I run:
> > 
> > ghc -package wx -o HelloWorld HelloWorld.hs
> > 
> > and on link I get many lines such as the following:
> > /usr/lib/libwxc.so: undefined reference to 
> > `wxGrid::GetColLabelValue(int)'
> > 
> > So it looks like the wxgtk library isn't getting included in the link
> > somehow.  
> 
> Hmm, strange -- I just compiled the latest CVS version
> with ghc 5.5 with gtk-2.4 on freeBSD without problems. 
> (at home I use ghc 6.01 on windows). Arthur showed yesterday that
> the latest CVS also works on macOSX

I tried again on my home machine, and everything works fine, but using
debian unstable and debian testing.  The work machine I was using was a
mixture of stable and testing, and that may have been the problem.  Perhaps
it was an issue of gcc 3.3/2.94 incompatibility.  In any case, it now seems
to work fine.  :)
-- 
David Roundy
http://www.abridgegame.org