wxhaskell-users — General mailing list for wxhaskell users

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

[Arjan v. I. <af...@cs...>]

Hello Claus,

>  For instance, how do I get arrowheads
> at the end of my lines?

I do not know what this means.

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

This happens to me too on Windows XP. I think it is a consequence of 
the way Daan uses wxWidgets. Specifying everything dynamically is not 
something the C++ library is used to.

> The wxhaskell applications page mentions a
> NetEdit tool but the source doesn't seem to be available?

I develop the NetEdit tool. It is an editor for probabilistic networks 
(summary: nodes and arcs and probability tables at each node). You can 
get the source from me if you want. It is growing larger and larger and 
does much more than just editing networks, but maybe you can partially 
evaluate it to your needs :-)

> Also, there seem to be a few oddities with the demos on
> a windows98 box (in addition to the window size problem):

Can't help you here.

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

No, its GHC only. It is of course possible to write SOEGraphics on top 
of wxHaskell. A nice student project I would think...

Cheers, Arjan

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

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

I've just started playing around with wxhaskell a little bit
more seriously, and keep having problems finding my way
through the docs. For instance, how do I get arrowheads
at the end of my lines? How do I avoid my wxhaskell window
to flick to an interim size before settling on the intended size
(happens, e.g., with the bouncing ball demo)?

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

Also, there seem to be a few oddities with the demos on
a windows98 box (in addition to the window size problem): 

    - TimeFlows: only "Time" follows the mouse, the other
        words hang in the upper left corner
    - Process: responds only with error pings, whatever the
        input    

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

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

Cheers,
Claus

Re: [wxhaskell-users] TreeCtrl Drag and Drop

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

> Note that I removed the propagateEvent in the first case, as I
> have handled it now.

That is exactly what fixed it.  I wonder why it "hurts" to propagate the
event.  I'm assuming any further propagation would/should be ignored?  In
any case, I have a working solution now.  Thanks for your help Daan (and
for wxHaskell to begin with!).

Re: [wxhaskell-users] TreeCtrl Drag and Drop

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

> Hmm, doesn't crash on me.  But I went ahead and added the images, but
> nothing changed.  Note that I said try with and without the "veto",
> because I'm not sure it should really even be "veto".  In the C++
> version, you have to explicitly allow the dragging, because the default
> is not to drag, as evidenced in the wxWidgets sample program:

No, it should be "allow", as signified by the documentation of
TreeCtrl events :-)

I tried it and it works on my machine -- ie. I have:

  onTreeEvent t event
    = case event of
       TreeBeginDrag item point allow
         -> putStrLn "dragging..."
       other
         -> propagateEvent

Note that I removed the propagateEvent in the first case, as I
have handled it now.

I have a windows-XP system with wxWidgets 2.4.2 and ghc 6.2.1.
If you tell me your system, I can maybe test it better on Monday,
perhaps there is an OS dependency somewhere.
(I have a MacOSX panther and Fedora core1 machine available).

I hope this helps,
-- Daan.

Re: [wxhaskell-users] TreeCtrl Drag and Drop

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

> Well, when I tried your example, it first crashed on me! As I am using
> a debug version, I quickly found out that the wxWidget code asserts that
> an image list is present when dragging -- even when just using text
> labels :-(
> I just wonder whether that might cause you trouble. When I added images
> (using
> the filebrowse example images) everything worked -- of course, drags were
> vetoed
> so, nothing would happen.

Hmm, doesn't crash on me.  But I went ahead and added the images, but
nothing changed.  Note that I said try with and without the "veto",
because I'm not sure it should really even be "veto".  In the C++
version, you have to explicitly allow the dragging, because the default
is not to drag, as evidenced in the wxWidgets sample program:

void MyTreeCtrl::OnBeginDrag(wxTreeEvent& event)
{
    // need to explicitly allow drag
    if ( event.GetItem() != GetRootItem() )
    {
        m_draggedItem = event.GetItem();
 
        wxLogMessage(wxT("OnBeginDrag: started dragging %s"),
                     GetItemText(m_draggedItem).c_str());
 
        event.Allow();
    }
    else
    {
        wxLogMessage(wxT("OnBeginDrag: this item can't be dragged."));
    }
}
 
That's why I wasn't sure if the "veto" wasn't really this "event.Allow()"
call.  But it doesn't matter, because I try it both ways and neither way
works.  Any ideas?

Thanks.

Re: [wxhaskell-users] TreeCtrl Drag and Drop

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

Hi alias in space and time :-)

On Tue, 18 May 2004 23:31:00 -0500, <wxh...@al...> wrote:

> Continuing with my last example, I have been trying to get drag and drop
> working for trees.  Is this implemented yet?  The following doesn't seem
> to work with or without the "veto" line commented out.  Any guidance
> would be appreciated.  If it hasn't been implemented yet, how much work
> would be required to do so?

Well, when I tried your example, it first crashed on me! As I am using
a debug version, I quickly found out that the wxWidget code asserts that
an image list is present when dragging -- even when just using text labels :-(
I just wonder whether that might cause you trouble. When I added images (using
the filebrowse example images) everything worked -- of course, drags were vetoed
so, nothing would happen.

I hope this helps,
All the best,
    Daan.

>
> Thanks
>
> module Main where
>
> import Graphics.UI.WX
> import Graphics.UI.WXCore
>
> imageNone :: Int
> imageNone = (-1)
>
> appendChild tree parent child = treeCtrlAppendItem tree parent child
> imageNone imageNone objectNull
>
> appendList tree parent children = mapM_ (appendChild tree parent)
> children
>
> main :: IO()
> main = start test
>
> test :: IO()
> test = do f <- frame [text := "Hello!"]
>           tree <- treeCtrl f []
>           root <- treeCtrlAddRoot tree "Root" imageNone imageNone
>           objectNull
>           child1 <- treeCtrlAppendItem tree root "Child1" imageNone
>           imageNone objectNull
>           child2 <- treeCtrlAppendItem tree root "Child2" imageNone
>           imageNone objectNull
>           appendList tree child1 ["A","B","C"]
>           appendList tree child2 ["1","2","3"]
>           set tree [on treeEvent := onTreeEvent tree]
>           set f [layout := fill $ widget tree, clientSize := sz 500 300]
>
>
> onTreeEvent :: TreeCtrl a -> EventTree -> IO ()
> onTreeEvent t event
>   = case event of
>       TreeBeginDrag item point veto
>         -> do putStrLn "started dragging..."
>               veto
>               propagateEvent
>       TreeEndDrag item point
>         -> do putStrLn "stopped dragging..."
>               propagateEvent
>       other
>         -> propagateEvent
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] TreeCtrl Drag and Drop

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

Hello again,

Continuing with my last example, I have been trying to get drag and drop
working for trees.  Is this implemented yet?  The following doesn't seem
to work with or without the "veto" line commented out.  Any guidance
would be appreciated.  If it hasn't been implemented yet, how much work
would be required to do so?

Thanks

module Main where
 
import Graphics.UI.WX
import Graphics.UI.WXCore
 
imageNone :: Int
imageNone = (-1)
 
appendChild tree parent child = treeCtrlAppendItem tree parent child
imageNone imageNone objectNull
 
appendList tree parent children = mapM_ (appendChild tree parent)
children
 
main :: IO()
main = start test
 
test :: IO()
test = do f <- frame [text := "Hello!"]
          tree <- treeCtrl f []
          root <- treeCtrlAddRoot tree "Root" imageNone imageNone
          objectNull
          child1 <- treeCtrlAppendItem tree root "Child1" imageNone
          imageNone objectNull
          child2 <- treeCtrlAppendItem tree root "Child2" imageNone
          imageNone objectNull
          appendList tree child1 ["A","B","C"]
          appendList tree child2 ["1","2","3"]
          set tree [on treeEvent := onTreeEvent tree]
          set f [layout := fill $ widget tree, clientSize := sz 500 300]
 
 
onTreeEvent :: TreeCtrl a -> EventTree -> IO ()
onTreeEvent t event
  = case event of
      TreeBeginDrag item point veto
        -> do putStrLn "started dragging..."
              veto
              propagateEvent
      TreeEndDrag item point
        -> do putStrLn "stopped dragging..."
              propagateEvent
      other
        -> propagateEvent
 

Re: [wxhaskell-users] TreeCtrl problem

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

> If that doesn't work, maybe you should download the sources of GeBoB (see
> application screenshots for a link). He uses a tree control for the
> "brain"
> component and maybe it gives some more info on using tree controls.

The solution was not related to treeCtrl at all, but did come from
looking at GeBoB.  One should always "fill" the containing widget.

Here is the updated, working code (with 6 additional characters):

module Main where
                                                                                
import Graphics.UI.WX
import Graphics.UI.WXCore
                                                                                
imageNone :: Int
imageNone = (-1)
                                                                                
main :: IO()
main = start test
                                                                                
test :: IO()
test = do f <- frame [text := "Hello!"]
          tree <- treeCtrl f []
          top <- treeCtrlAddRoot tree "Root" imageNone imageNone
          objectNull
          item <- treeCtrlAppendItem tree top "Child" imageNone imageNone
          objectNull
          set f [layout := fill $ widget tree, clientSize := sz 500 300]
                                                                                

Re: [wxhaskell-users] TreeCtrl problem

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

On Sun, 16 May 2004 12:32:31 -0500, <wxh...@al...> wrote:

> Hello,
>
> I'm attempting to do a simple tree with 2 nodes.  However, the following
> is giving me a blank window with 2 tiny white tabs in the upper-left
> corner.  Anyone have an idea what I'm missing?

I haven't tried it myself, but maybe you need to expand the root node:

  treeCtrlExpand tree top


If that doesn't work, maybe you should download the sources of GeBoB (see
application screenshots for a link). He uses a tree control for the "brain"
component and maybe it gives some more info on using tree controls.

All the best,
  Daan.



>
> Thanks!
>
> module Main where
>
> import Graphics.UI.WX
> import Graphics.UI.WXCore
>
> imageNone :: Int
> imageNone = (-1)
>
> main :: IO()
> main = start test
>
> test :: IO()
> test = do f <- frame [text := "Hello!"]
>           tree <- treeCtrl f []
>           top <- treeCtrlAddRoot tree "Root" imageNone imageNone
>           objectNull
>           item <- treeCtrlAppendItem tree top "Child" imageNone imageNone
>           objectNull
>           set f [layout := widget tree, clientSize := sz 500 300]
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] TreeCtrl problem

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

Hello,

I'm attempting to do a simple tree with 2 nodes.  However, the following
is giving me a blank window with 2 tiny white tabs in the upper-left
corner.  Anyone have an idea what I'm missing?

Thanks!

module Main where
                                                                                
import Graphics.UI.WX
import Graphics.UI.WXCore
                                                                                
imageNone :: Int
imageNone = (-1)
                                                                                
main :: IO()
main = start test
                                                                                
test :: IO()
test = do f <- frame [text := "Hello!"]
          tree <- treeCtrl f []
          top <- treeCtrlAddRoot tree "Root" imageNone imageNone
          objectNull
          item <- treeCtrlAppendItem tree top "Child" imageNone imageNone
          objectNull
          set f [layout := widget tree, clientSize := sz 500 300]
                                                                                

[wxhaskell-users] Re: Dealing with threads

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

On 11.05.2004, at 02:51, Duncan Coutts wrote:

> I would see as the goal, a solution that allows multiple Haskell 
> threads
> to be bound to the single OS thread (the GUI thread), so that all calls
> that query or modify the GUI occur in the same single OS thread.

I would recommend not to go down that route...

*) It places a high burden on the Haskell implementation - GHC's is the 
only RTS where this is even remotely implementable, whereas the current 
"bound threads" scheme can be implemented in a variety of different 
ways. I like to consider lightweight threads as an implementation 
detail (used to achieve top performance in GHC) and not as a language 
feature that has to be duplicated by all future implementations.

*) Having multiple threads trigger actions in the GUI thread can be 
done without any special support by the RTS (see below).

*) Executing two Haskell threads in one OS thread leads to a lot of 
problems when interacting
with foreign code. Nobody seems to have succeeded in even specifying 
exactly what should happen in all the strange situations that arise 
here. For example, let's assume we have two Haskell threads, A and B, 
running in one OS thread.
Now A calls a foreign function "foo" that takes a long time to execute. 
During this time, B doesn't execute at all, right?
OK, so now after "foo" is finished, A calls another foreign function, 
"bar", which immediately calls back into Haskell. So as soon as the RTS 
is re-entered, B should continue to run?
But what if B calls another foreign function, which in turn calls back 
to Haskell? Now if the A-callback wants to return to bar, will that be 
possible? No, it'll have to wait for that other foreign call in another 
thread.
It's a can of worms, we _don't_ want to go there.

*) Executing two Haskell threads in one OS thread does not solve the 
problem.
Sometimes we want to make library calls A, B and C in order, and not 
have another thread call D in-between; for example because the library 
has some global or thread-local state which we don't want to be messed 
up, or perhaps because we want A, B and C to be done right after each 
other (e.g. updating different parts of one window), and D might take a 
long time (show a dialog box).

> I'm interested in your thoughts on this issue, (especially alternative
> proposals) and what priority you feel it deserves.

Well...
let's assume we've imported a few things from some "foreign" GUI 
library (sorry, I don't know much about either gtk or wx, so I'll try 
to stay general):

> runMainLoop :: IO ()	 -- returns only when the program is over, calls 
> lots of callbacks.
> 	-- send a user event to the main loop (wrap the IO action in a stable 
> pointer)
> postUserEvent :: IO () -> IO ()
>
> {-# NOINLINE uiThread #-}
> uiThread = unsafePerformIO $ newIORef (undefined :: ThreadId)
>
> onClick :: ... -> IO () -- just an example
> onClick blah blah blah = do tid <- myThreadId
>                             writeIORef uiThread tid
>                             handleTheEvent
>
> 	-- handle a user event
> onUserEvent :: IO () -> IO ()
> 							
> onUserEvent action = do tid <- myThreadId
>                         writeIORef uiThread tid
>                         action
>
> doInUIThread action = do tid <- myThreadId
>                          uiTid <- readIORef uiThread
>                          if tid == uiTid
>                              then action
>                              else postUserEvent action

And then we can either wrap doInUIThread around every function we 
import from the UI library (slow), or we can use it manually to do 
things in bigger chunks.
I think we do _not_ want the handling of one event to be preempted by 
UI actions from other threads; we might be in the progress of building 
a dialog box in response to a user event, we don't want a background 
thread to display e.g. an error message when we have a half-finished 
dialog box...

Cheers,

Wolfgang

[wxhaskell-users] Dealing with threads

[Duncan C. <dun...@wo...>]

All,

I gather that wxHaskell does not yet work nicely with multiple Haskell
threads (eg the long computation in a separate thread in order to show a
progress bar).

I'm working on the same issue with gtk2hs and was hoping we could
coordinate in designing a solution and in talking to the ghc developers
if necessary.

Current solutions are not very satisfactory, one can either add an idle
handler that periodically yields to the ghc rts, or sprinkle your long
running action with calls to yield to the gui main loop.

The former is not good because it is basically polling which costs cpu
time, even when your app should be idle. The latter is either difficult
and annoying or impossible; the long running process may involve code
from a different library that knows nothing of GUIs (which you would
have to modify) or may even be pure code in which case you can't yield
to the gui main loop at all.

While using multiple threads may well not be a good technique for GUIs
written in traditional languages (since the locking issues with OS
threads are considerable), using lightweight Haskell threads should be a
nice way of structuring GUI programs in Haskell. There are a couple
research papers on this theme. Also, if we can make sure that all the
Haskell threads accessing the GUI are running in the context of the same
OS thread then there are no locking issues.

So here's some of my ideas for what we would want:

I would see as the goal, a solution that allows multiple Haskell threads
to be bound to the single OS thread (the GUI thread), so that all calls
that query or modify the GUI occur in the same single OS thread.

If we had such a mechanism, then we still have to solve the problem that
the GUI event loop blocks until it gets an event; while we would like to
get control to return to the ghc rts occasionally so that it can service
any active Haskell threads that want to make gui calls. We also want to
be able to do this without polling.

This may require some mechanism to get the appropriate information from
the ghc rts so that the gui event loop can block, and return control to
the ghc rts for one timeslice whenever there are events that ghc's rts
is interested in (timers, io activity etc)

I'm interested in your thoughts on this issue, (especially alternative 
proposals) and what priority you feel it deserves.

Duncan Coutts

[wxhaskell-users] RE: Integrating ghc's rts into other single-threaded frameworks

[Simon Peyton-J. <si...@mi...>]

| I'm thinking about how to make threaded Haskell program work nicely
with
| Gtk+ (the widget toolkit) and whether the new threaded rts will help
or
| not.
|=20
...
|=20
| Would bound threads help? I'm not sure I understand the idea very
well.

That's *exactly* what the bound-threads idea is for.  It's implemented
in GHC 6.2.1 (see the bound-thread operations in Control.Concurrent).
There is a more detailed writeup about bound threads that I think we
neglected to complete and publish.  Wolfgang Thaller is the main author,
and I hope he may pick this up.  Meanwhile we'll put the current draft
on the GHC site.

Simon

Re: [wxhaskell-users] wxHtmlWindow and custom tags / embedded widgets

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

On Mon, 3 May 2004 20:10:16 +0200, Benedikt Grundmann <Ben...@we...> wrote:

> I want to use a html widget and embed a normal wxwidget inside.  This is
> normally (i.e in wxWindows) done using custom tags, which can be defined
> using some special macros provided by wxwindows.  But how do I do it in
> wxHaskell?

You can't do that at the moment :-(  Just as you say, the custom tag mechanism
in wxWidgets is done statically with macros while the interface from Haskell is
entirely dynamic. There are basically two solutions:
1) Add extra code to the wxc wrapper that includes your custom widget (difficult)
2) Add extra code to the wxc wrapper that exposes a custom component
that allows for dynamic binding of custom tags for Haskell -- allowing normal
haskell functions to register as event handlers for those tags. For example:

> set html [on (tag "custom") := logMessage "custom parsed"]

Of course, solution (2) seems right for wxHaskell but I just never got around
to doing it. If someone on this list, or maybe you, is willing to try, I'll be happy
to give guidance -- but (on first sight) it seems a rather difficult job to do,
requiring good understanding of the wxHtml controls.

Sorry for the lack of functionality,
All the best,
  Daan.




>
> Cheers,
>
> Bene
>

Re: [wxhaskell-users] Integrating ghc's rts into other single-threaded frameworks

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

On Monday 03 May 2004 23:09, Vincenzo aka Nick Name wrote:
> But is this the mailing list you intended to send your message?

yes, yes, I see :)

Re: [wxhaskell-users] Integrating ghc's rts into other single-threaded frameworks

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

On Monday 03 May 2004 22:56, Duncan Coutts wrote:
> Graphics toolkits (X windows or win32 GDI) typically have pretty
> strict requirements on threads. While it is possible to make use of
> multiple OS/kernel threads, the locking issues are non-trivial and it
> is generally not encouraged. It is probably best to consider them as
> single threaded libraries.

If you create windows (call GUI functions) in the same thread of the GUI 
main loop you have absolutely no problem, and your main program can run 
in parallel; if you use a channel carrying IO actions you can have the 
main GUI thread do anything you want (you send IO actions to it and it 
executes those); this might seem difficult but it's easy, surely easier 
than shared memory and locks or any other way to do the same thing 
(which is indeed considered very difficult for the reasons you cite). I 
am not sure if this is what you are looking for.

But is this the mailing list you intended to send your message?

V.

[wxhaskell-users] Integrating ghc's rts into other single-threaded frameworks

[Duncan C. <dun...@wo...>]

All,

I'm thinking about how to make threaded Haskell program work nicely with
Gtk+ (the widget toolkit) and whether the new threaded rts will help or
not.

Graphics toolkits (X windows or win32 GDI) typically have pretty strict
requirements on threads. While it is possible to make use of multiple
OS/kernel threads, the locking issues are non-trivial and it is
generally not encouraged. It is probably best to consider them as single
threaded libraries.

So while my initial thought was to make a blocking call to Gtk's main
loop in another OS thread using the threadsafe atribute so that it runs
in a separate thread, I now think this is not the best approach. The
problem is that calls to Gtk functions in other Haskell threads will be
made in a different OS thread from the one running the Gtk main loop.

Would bound threads help? I'm not sure I understand the idea very well.

(It is possible to set up a polling system where gtk periodically calls
back to Haskell land and we call ghc's yield function. As you might
expect, this works but performs poorly and consumes cpu time when idle.)

So a better approach might be to try and integrate the main loops of
gtk+ and the ghc rts. Gtk provides a fairly flexible API for controlling
it's main loop. You can either run it as a single blocking function or
run a single iteration at a time or even split up each iteration into
phases.

So the question is which main loop gets to block? Unfortunately, neither
can do so unless it knows the full set of file descriptors and timeouts
of both main loops. So the question is which would be easier?

The glib main loop could act as the master main loop since there are
functions for registering callbacks for fds and timeouts. At the moment,
I don't believe there is any way to ask the ghc rts what fds & timeouts
it is interested in.

The glib main loop is designed so that it can integrate into an external
main loop (though no doubt with some difficulty). See:
http://www.gtk.org/~otaylor/gtk/2.0/main-loop.html
also an older message
http://mail.gnome.org/archives/gtk-devel-list/1999-March/msg00145.html

The glib main loop can be split up into phases (prepare, query, check,
dispatch), see:
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#mainloop-states
It's not clear to me how one would use that to integrate two main loops,
but perhaps it's clearer to the ghc rts gurus. There is also a function
for changing the 'poll' function that the glib main loop uses. This
might be another way to allow the ghc rts main loop to be the master
one.

I'd guess that it would be easier to expose some rts function that tells
us what fds & timeouts ghc's rts is interested in at any particular time
and write some glue code (in C) to install ghc's rts events sources in
an external main loop.

What would such an API look like? Presumably we'd need to know if there
are runnable Haskell threads and we'd need to be able to run them for
one timeslice. If there were no runnable threads, we'd want to know the
set of fds & timeouts that the rts would want to block upon.

[sorry, this next bit is a bit implementation specific]
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#GSource
To create a GSource from this we would need to implement a prepare,
check & dispatch to fill out a GSourceFuncs struct. In prepare we'd
check to see if there are currently any runnable Haskell threads
(returning true if there were). It would also set up the set of fds to
be polled. It would also return the timeout of the soonest timeout that
the ghc rts has (or -1). In check we'd return true if any fds were ready
or a timeout had expired. In dispatch we'd ask the ghc rts to run for
one timeslice.

Any simpler / better ideas anyone?

Duncan

[wxhaskell-users] wxHtmlWindow and custom tags / embedded widgets

[Benedikt G. <Ben...@we...>]

Hello all,

I want to use a html widget and embed a normal wxwidget inside.  This is 
normally (i.e in wxWindows) done using custom tags, which can be defined
using some special macros provided by wxwindows.  But how do I do it in
wxHaskell?

Cheers,

Bene

-- 
Benedikt Grundmann

The reason why truth is so much stranger than fiction
is that there is no requirement for it to be consistent.
		-- Mark Twain --

Re: [wxhaskell-users] How do I call statusBarSetStatusWidths :: StatusBar a -> Int -> Ptr CInt -> IO ()

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

On Mon, 26 Apr 2004 11:13:11 -0700, David Bakin <d....@co...> wrote:

> Because I didn't know about it!  I was looking in Controls for a status bar
> wrapper, not Menus.  None of the samples had status bars and I wanted to
> start off by doing something that wasn't in the samples.  I guess I need to
> browse *all* of the documentation so I have a better idea of what's where.
>
> Thanks for your help!  -- David

You've hit one the most important issues wxHaskell: documentation :-)
Although I think that it is a good thing that there is at least
some (good) documentation, it would be good if there was some better
overview of where to find the things you are looking for -- especially
with regard to attributes.

Success with the statusbars,
  -- Daan.

ps. See the "samples/wx/" "minimal" and "imageviewer" example for a statusbar


>
> ----- Original Message -----
> From: "Daan Leijen" <daa...@xs...>
> To: "David Bakin" <d....@co...>;
> <wxh...@li...>
> Sent: Monday, April 26, 2004 4:39 AM
> Subject: Re: [wxhaskell-users] How do I call statusBarSetStatusWidths ::
> StatusBar a -> Int -> Ptr CInt -> IO ()
>
>
>> On Mon, 26 Apr 2004 01:18:11 -0700, David Bakin <d....@co...>
> wrote:
>>
>> > Hi.  I'd like to call statusBarSetStatusWidths - apparently it wants an
> array of integers (the status field widths) - how do I create that as a Ptr
> CInt?
>>
>> Hi Dave,
>>
>> This should be in wxhaskell of course, I'll add it to the next version.
>> For now, you can use the same code as in
> "WXCore.Frame.statusBarCreateFields".
>> If you don't have access to the sources, here it is:
>>
>>   import Foreign.Marshal.Array
>>   ...
>>   statusBarCreateFields :: Frame a -> [Int] -> IO (StatusBar ())
>>   statusBarCreateFields parent widths
>>     = do ...
>>           then do withArray (map toCInt widths)
>>                             (\pwidths -> statusBarSetStatusWidths sb
> (length widths) pwidths)
>>                   ...
>>
>> All the best,
>>   Daan.
>>
>> btw. I am curious why you need to call this function? Are the functions
>> in "WX.Menu" not good enough (and why not)? Maybe we can improve the
> interface?
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

Re: [wxhaskell-users] How do I call statusBarSetStatusWidths :: StatusBar a -> Int -> Ptr CInt -> IO ()

[David B. <d....@co...>]

Because I didn't know about it!  I was looking in Controls for a status bar
wrapper, not Menus.  None of the samples had status bars and I wanted to
start off by doing something that wasn't in the samples.  I guess I need to
browse *all* of the documentation so I have a better idea of what's where.

Thanks for your help!  -- David

----- Original Message ----- 
From: "Daan Leijen" <daa...@xs...>
To: "David Bakin" <d....@co...>;
<wxh...@li...>
Sent: Monday, April 26, 2004 4:39 AM
Subject: Re: [wxhaskell-users] How do I call statusBarSetStatusWidths ::
StatusBar a -> Int -> Ptr CInt -> IO ()


> On Mon, 26 Apr 2004 01:18:11 -0700, David Bakin <d....@co...>
wrote:
>
> > Hi.  I'd like to call statusBarSetStatusWidths - apparently it wants an
array of integers (the status field widths) - how do I create that as a Ptr
CInt?
>
> Hi Dave,
>
> This should be in wxhaskell of course, I'll add it to the next version.
> For now, you can use the same code as in
"WXCore.Frame.statusBarCreateFields".
> If you don't have access to the sources, here it is:
>
>   import Foreign.Marshal.Array
>   ...
>   statusBarCreateFields :: Frame a -> [Int] -> IO (StatusBar ())
>   statusBarCreateFields parent widths
>     = do ...
>           then do withArray (map toCInt widths)
>                             (\pwidths -> statusBarSetStatusWidths sb
(length widths) pwidths)
>                   ...
>
> All the best,
>   Daan.
>
> btw. I am curious why you need to call this function? Are the functions
> in "WX.Menu" not good enough (and why not)? Maybe we can improve the
interface?
>
>

Re: [wxhaskell-users] How do I call statusBarSetStatusWidths :: StatusBar a -> Int -> Ptr CInt -> IO ()

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

On Mon, 26 Apr 2004 01:18:11 -0700, David Bakin <d....@co...> wrote:

> Hi.  I'd like to call statusBarSetStatusWidths - apparently it wants an array of integers (the status field widths) - how do I create that as a Ptr CInt?

Hi Dave,

This should be in wxhaskell of course, I'll add it to the next version.
For now, you can use the same code as in "WXCore.Frame.statusBarCreateFields".
If you don't have access to the sources, here it is:

  import Foreign.Marshal.Array
  ...
  statusBarCreateFields :: Frame a -> [Int] -> IO (StatusBar ())
  statusBarCreateFields parent widths
    = do ...
          then do withArray (map toCInt widths)
                            (\pwidths -> statusBarSetStatusWidths sb (length widths) pwidths)
                  ...

All the best,
  Daan.

btw. I am curious why you need to call this function? Are the functions
in "WX.Menu" not good enough (and why not)? Maybe we can improve the interface?

[wxhaskell-users] How do I call statusBarSetStatusWidths :: StatusBar a -> Int -> Ptr CInt -> IO ()

[David B. <d....@co...>]

Hi.  I'd like to call statusBarSetStatusWidths - apparently it wants an =
array of integers (the status field widths) - how do I create that as a =
Ptr CInt?

Thanks!  -- Dave

Re: [wxhaskell-users] How to make the Filter programm?

[shelarcy <she...@ca...>]

On Sun, 11 Apr 2004 16:22:23 +0200, Daan Leijen <daa...@xs...> 
wrote:
>> I was making a Filter (Low pass Filter) programm in wxHaskell.
>> [snip]
>>
>>                     im <- imageCreateFromBitmap bm
>>                     pxe <- imageGetPixelBuffer im
>> [snip]
>>                     fillpixelBuffer pxe
>>                     bm2  <- bitmapCreateFromImage im (-1)
>> [snip]
>>
>> But these code doesn't work.
>>
>> Where is wrong?
>
> I think that when you get the pixelbuffer from an image, you get a fresh 
> copy
> and you are not manipulating the image itself. So, you probably need to 
> use
> "imageCreateFromPixelBuffer" to create a new "image" from the 
> pixelbuffer again.
> (See the "PaintDirect" sample in the contrib directory)
>
> I hope this helps,
> All the best,
>   Daan.

I changed my programm under that advice, but programm doesn't work yet.
I'm thinking that reason many time ... Do I misunderstand your message?

let fillpixelBuffer pb = do
                            mapM_ (drawLowpassFilter pb) (pixelPoint bsz 0)
                            return pb
                     px2 <- fillpixelBuffer pxe
                     im2 <-imageCreateFromPixelBuffer px2
                     bm2  <- bitmapCreateFromImage im2 (-1)
                     drawBitmap dc bm2 pointZero True []




-- 
shelarcy <she...@ca...>
http://page.freett.com/shelarcy/ 

Re: [wxhaskell-users] Where is the sample programm of wxHaskell OpenGL canvas using the HOpenGL binding?

[shelarcy <she...@ca...>]

On Mon, 12 Apr 2004 23:10:36 +0900, shelarcy 
<she...@ca...> wrote:
> On Sun, 11 Apr 2004 16:37:58 +0200, Daan Leijen <daa...@xs...>
> wrote:
>> Hi Shelarcy,
>>
>> Great that the openGL seems to work for you. Could you send
>> me a screenshot? (With a "little" window)?
>>
>> Furthermore, I would like to put your sample code in the
>> contrib samples. Maybe you could send me minimal working
>> source code (maybe with some comments)?
>>
>> All the best,
>>   Daan.
>
> Here are source code and screen shots.
>
> SF Mailer refused .zip file.

wxHaskell site and CVS doesn't update.
Raw File is ugly or File is lost?

I send the tar.gz file again.


-- 
shelarcy <she...@ca...>
http://page.freett.com/shelarcy/ 

Re: [wxhaskell-users] RE: [Haskell] Dynamically loading wxhaskell?

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

Hi all,

On Wed, 14 Apr 2004 11:24:02 -0500, <wxh...@al...> wrote:
>
> Yes, I pointed this out to Daan back on Feb 24, but never saw a patch. :)

Sorry for that James :-)

Well, it seems that on wxWidgets 2.5.1 the call to wx-config --gl-libs
always returns the libraries needed for opengl :(
I'll write the wxWidgets devs to see what I should do -- maybe it is just
a bug on their part, in which case I can check the wxwidgets version
and issue an appropiate warning if necessary.

to be continued...

-- Daan.


>
> James
>
>
> ----- Original message -----
> From: "Andres Loeh" <an...@cs...>
> To: "Daan Leijen" <daa...@xs...>
> Date: Wed, 14 Apr 2004 18:25:23 +0200
> Subject: Re: [wxhaskell-users] RE: [Haskell] Dynamically loading
> wxhaskell?
>
>> That is probably the problem. I did not see all messages of this thread,
>> but one should indeed use "--with-opengl" on wxHaskell configure if
>> wxWidgets
>> was build with "--with-opengl".
>>
>> Unfortunately, due to wxWidgets changes, I can not automatically detect the
>> need for this flag, but I promise to discuss it with the wxWidgets
>> devs.
>
> I think this has been discussed before: as far as I can see, the flag
> --with-opengl is always safe, and should therefore be the default.
> The call to "wx-config --gl-libs" returns the empty string if
> wxWidgets has not been built using GL.
>
> Best,
>   Andres
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>