[Haskell-cafe] GUI Program Hangs in GHCI
Hello,
I have a GUI program that when I compile it and run it there are no
problems. When I load it into GHCI and type, main, it loads the
main window but there are no window decorations and the program hangs
to the point where I have to kill the ghci process. You see a
spinning cursor when you mouse over the window.
I found this old email regarding gtk2hs:
http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI
I recompiled the program to use -threaded but the behavior is
unchanged (if the email above describes my problem then I expected the
compiled version to start having issues).
What else can cause the hangs I'm seeing?
I'm using the GLFW-b library on hackage and the program I'm trying to
run are any of the executables from the nehe-tuts package (also on
hackage). To reproduce my hangs, I think you need OSX (I didn't test
this on windows or linux), and then type the following:
{{{
mkdir -p ~/tmp/test
cd ~/tmp/test
cabal update
cabal-dev install-deps nehe-tuts
cabal unpack nehe-tuts
cabal-dev ghci nehe-tuts-0.2.3/lesson01.hs
*Main main
}}}
Doing a force quit on ghci gives me a stack trace via the OSX crash
reporting system. You'll find the relevant bits from that at the end
of this email.
What debugging techniques do I have at my disposal for figuring out
what is going wrong here? At least one person has suggested that
possibly ghci and the GUI bits of glfw are competing for input and
conflicting with each other. If that's the case, how could I be sure
and what would I do about it?
Thanks,
Jason
{{{
Process: ghc [48045]
Path:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/ghc
UID: 502
Thread 84d5f8 DispatchQueue 1
User stack:
47 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff8760ef8a]
Kernel stack:
46 semaphore_wait_continue + 0 [0x22a88f]
1 lo_alltraps + 454 [0x2a1976]
1 i386_astintr + 47 [0x2aacb4]
1 ast_taken + 247 [0x219432]
1 bsd_ast + 806 [0x48fea8]
1 postsig + 432 [0x48cfff]
1 exit1 + 449 [0x48187a]
1 task_terminate_internal + 242 [0x22ca4d]
1 ipc_space_destroy + 177 [0x215868]
1 ipc_right_clean + 397 [0x215256]
1 mach_notify_no_senders + 75 [0x23ff7b]
1 mach_msg_send_from_kernel_proper + 90 [0x21e0cb]
1 ipc_kmsg_send + 105 [0x210a86]
1 ipc_kobject_server + 267 [0x21dbfc]
1 iokit_notify + 154 [0x284eed]
1 iokit_client_died + 85 [0x571527]
1 com.apple.GeForce 6.3.0 + 47083 [0x830867eb]
1 com.apple.GeForce 6.3.0 + 305981
[0x830c5b3d]
1 com.apple.GeForce 6.3.0 +
258633 [0x830ba249]
1 OSObject::release() const +
25 [0x506759]
1
OSObject::taggedRelease(void const*) const + 32 [0x50673e]
1 com.apple.GeForce 6.3.0
+ 253194 [0x830b8d0a]
1 com.apple.GeForce
6.3.0 + 251919 [0x830b880f]
1 com.apple.NVDAResman
6.3.0 + 453556 [0x83689bb4]
1
com.apple.NVDAResman 6.3.0 + 445937 [0x83687df1]
1
com.apple.NVDAResman 6.3.0 + 302211 [0x83664c83]
1
com.apple.NVDAResman 6.3.0 + 249957 [0x83658065]
1
com.apple.NVDAResman 6.3.0 + 112888 [0x836368f8]
1
com.apple.NVDAResman 6.3.0 + 111718 [0x83636466]
1
com.apple.nvidia.nv50hal 6.3.0 + 623157 [0x83e1a235]
1
com.apple.nvidia.nv50hal 6.3.0 + 605845 [0x83e15e95]
1
com.apple.nvidia.nv50hal 6.3.0 + 606056 [0x83e15f68]
Thread 84d67e DispatchQueue 2
User stack:
46 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff875edfc5]
46 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff875ee128]
46 _dispatch_worker_thread2 + 252 (in libSystem.B.dylib)
[0x7fff875ee7fe]
46 _dispatch_queue_invoke + 185 (in libSystem.B.dylib)
[0x7fff875eecd4]
46 kevent + 10 (in libSystem.B.dylib) [0x7fff875ed12a]
Kernel stack:
46 kevent + 97 [0x47a681]
Thread 84d5f9
User stack:
46 kevent64 + 10 (in libSystem.B.dylib) [0x7fff87687512]
Kernel stack:
46 kevent + 97 [0x47a681]
Thread 84d5fa
User stack:
46 ??? [0x10681d9e8]
38 ??? [0x10a60403b]
37 CGLFlushDrawable + 67 (in OpenGL)
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I found this old email regarding gtk2hs: http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI I recompiled the program to use -threaded but the behavior is unchanged (if the email above describes my problem then I expected the compiled version to start having issues). On second though, I think this *IS* a threading issue. Depending on where I add either forkIO or forkOS in main the compiled program either behaves the same as it does in ghci or it segfaults. I don't know how to fix it, but I suspect that I have to do something like what is described here: http://www.cocoabuilder.com/archive/cocoa/292830-nstimer-not-working-in-multithreaded-application.html I think the issue is that when I run the GUI code one a thread that isn't the original thread then I need to explicitly call that threads run loop. The above link points at this bit of documentation and I probably need to read it to develop a better understanding: http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 8:31 PM, Alexander Solla alex.so...@gmail.com wrote: On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html Heh. Yes, good memory! That's a link to an email I wrote in response to Conal. I'm looking into the issues that Conal mentions there. So far I've discovered that there is a bug in the Objective-C part of glfw when it inits threads[1]. Fixing that bug makes it so that I can use forkIO in the compiled version of my program but I still have the bad behavior in ghci. I think the remaining bit is that OSX (and probably windows too) makes it very hard to run your event loop on a thread other than your original thread[2]. I'm now wondering if the threading model in GHC even gives me enough control to handle this situation correctly. Jason [1] https://sourceforge.net/tracker/?func=detailaid=3352963group_id=72569atid=534938 [2] http://www.cocoabuilder.com/archive/cocoa/205803-event-loop-in-secondary-thread-nibless-cocoa.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 9:06 PM, Jason Dagit dag...@gmail.com wrote: On Sun, Jul 3, 2011 at 8:31 PM, Alexander Solla alex.so...@gmail.com wrote: On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html Heh. Yes, good memory! That's a link to an email I wrote in response to Conal. I'm looking into the issues that Conal mentions there. So far I've discovered that there is a bug in the Objective-C part of glfw when it inits threads[1]. Fixing that bug makes it so that I can use forkIO in the compiled version of my program but I still have the bad behavior in ghci. I think the remaining bit is that OSX (and probably windows too) makes it very hard to run your event loop on a thread other than your original thread[2]. I'm now wondering if the threading model in GHC even gives me enough control to handle this situation correctly. My test was incorrect. Even with that fix I still can't use the threaded RTS in the compiled version. I think I understand the issue now and I'm looking for a solution in a different thread (pun intended?). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Designer
On 18.11.10 21:28, c8h10n4o2 wrote: There's a tutorial on how to use qtDesigner with qtHaskell ? sorry, i don't know of any tutorial, but there are some examples in the `examples' directory of the source distribution (e.g. tetrix.hs). basically you load the ui file, retrieve named widgets and attach signal handlers in haskell. signals and slots of compatible types can also be connected directly in Designer. sk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Designer
On 18 November 2010 20:28, c8h10n4o2 asaferibei...@ymail.com wrote: Or how to use XRC files with wxHaskell? There are sample files in the wxHaskell distribution. If you can wait a day or two I will have a step-by-step blog article, but it's not quite finished yet. Regards Jeremy -- View this message in context: http://haskell.1045720.n5.nabble.com/GUI-Designer-tp3271441p3271441.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI Designer
There's a tutorial on how to use qtDesigner with qtHaskell ? Or how to use XRC files with wxHaskell? -- View this message in context: http://haskell.1045720.n5.nabble.com/GUI-Designer-tp3271441p3271441.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI programming
On Fri, Feb 5, 2010 at 9:54 PM, Mario Blažević mblaze...@stilo.com wrote:
Victor Nazarov wrote:
Hello,
I've been writing some GUI application with Gtk2hs. It's an
interpreter for lambda-calculus and combinatory logic, it's GPL and if
you interested I can share it with cafe.
The problem is that the GUI code has become very ugly and I'm tempted
to rewrite it totally. I've been looking forward to the FRP stuff, but
I've never seen a single definition of the term. Conal Eliot's
denotational programming is too general to be definition. I want to
try Grapefruit, but I got totally lost when I see arrow notation.
I consider more lightweight and more imperative approach, something
closer to CSP (Communicating Secuential Processes) then FRP. I've just
crafted some sample program to illustrate my idea.
The behaviour is a monad and it's IO monad so you can do any IO
(Gtk2hs) programming you wish. The differences is that you don't
attach static event handlers and tries to determine what to do
dependent on application state. You attach and detach handlers as much
as possible. Behaviour looks like a process that can stop execution
and wait for some GUI event. When event arrived it continues
execution.
To summarize, the behaviour is a suspendable IO computation. It looks
very much like a coroutine, in fact. I'm planning to extract the
Control.Concurrent.Coroutine module [1] into a separate package soon. It
implements a similar concept but generalized to transform any monad and any
functorial suspension.
[1]
http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concurrent-Coroutine.html
Yes, behaviour is exactly a coroutine. Your coroutine module seem
cool, but I would like to have a DSL closer to GUI programming than to
concurrent programming.
Do you see this approach viable. There are steel some details to emerge:
* How to wait for several events
* How to handle IO exceptions
I don't really know how applicable the idea is to GUI programming.
That's not my area of expertise. I am surprised, though, that neither your
code not your comments seem to address the issue of concurrency, as I expect
that would be crucial in a GUI setting. Wouldn't you need different
behaviours to run in different threads?
As I understand Gtk2hs still don't run in -threaded environment. And
I've been trying to avoid multithreading as much as possible. I've
already implemented exception handling through MonadError instance and
multi-event waits. Now I'm trying to rewrite GUI code of my
lambda-interpreter, and I'll publish it on hackage, when I am done.
Here is the code:
{-# LANGUAGE ExistentialQuantification #-}
...
I don't see the purpose of your BBind constructor. It seems to me
that you could simply move the first three cases of runBehaviour
implementation into your = and get rid of the constructor. Do you need
that much laziness?
I think, I need it, I can't see the way to rewrite it without
intermediate data-structure. The problem is the third case:
runBehaviour (BBind (BBind a f) g) = runBehaviour (a = (\x - f x = g))
See Heinrich Apfelmus' entry in Monad.Reader to see operational view
on monads. My implementation is very close to this idea.
--
Victor Nazarov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI programming
On Mon, Feb 08, 2010 at 12:54:03PM +0300, Victor Nazarov wrote: As I understand Gtk2hs still don't run in -threaded environment. It does run, just use unsafeInitGUIForThreadedRTS. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] GUI programming
Hello Felipe, Monday, February 8, 2010, 1:10:07 PM, you wrote: As I understand Gtk2hs still don't run in -threaded environment. It does run, just use unsafeInitGUIForThreadedRTS. ... and run all GUI primitives via special wrapper or in GUI thread -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI programming
Victor Nazarov wrote:
Hello,
I've been writing some GUI application with Gtk2hs. It's an
interpreter for lambda-calculus and combinatory logic, it's GPL and if
you interested I can share it with cafe.
The problem is that the GUI code has become very ugly and I'm tempted
to rewrite it totally. I've been looking forward to the FRP stuff, but
I've never seen a single definition of the term. Conal Eliot's
denotational programming is too general to be definition. I want to
try Grapefruit, but I got totally lost when I see arrow notation.
I consider more lightweight and more imperative approach, something
closer to CSP (Communicating Secuential Processes) then FRP. I've just
crafted some sample program to illustrate my idea.
The behaviour is a monad and it's IO monad so you can do any IO
(Gtk2hs) programming you wish. The differences is that you don't
attach static event handlers and tries to determine what to do
dependent on application state. You attach and detach handlers as much
as possible. Behaviour looks like a process that can stop execution
and wait for some GUI event. When event arrived it continues
execution.
To summarize, the behaviour is a suspendable IO computation. It looks
very much like a coroutine, in fact. I'm planning to extract the
Control.Concurrent.Coroutine module [1] into a separate package soon. It
implements a similar concept but generalized to transform any monad and
any functorial suspension.
[1]
http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concurrent-Coroutine.html
Do you see this approach viable. There are steel some details to emerge:
* How to wait for several events
* How to handle IO exceptions
I don't really know how applicable the idea is to GUI programming.
That's not my area of expertise. I am surprised, though, that neither
your code not your comments seem to address the issue of concurrency, as
I expect that would be crucial in a GUI setting. Wouldn't you need
different behaviours to run in different threads?
Here is the code:
{-# LANGUAGE ExistentialQuantification #-}
...
I don't see the purpose of your BBind constructor. It seems to me that
you could simply move the first three cases of runBehaviour
implementation into your = and get rid of the constructor. Do you
need that much laziness?
import Data.IORef
import System.Glib
import Graphics.UI.Gtk
import Control.Monad.Trans
type Event obj = IO () - IO (ConnectId obj)
data Behaviour a =
forall b. BBind (Behaviour b) (b - Behaviour a)
| BIO (IO a)
| forall obj. GObjectClass obj = BWaitEvent (Event obj) (Behaviour a)
instance Monad Behaviour
where action = generator = BBind action generator
return a = BIO (return a)
instance MonadIO Behaviour
where liftIO action = BIO action
runBehaviour :: Behaviour a - IO a
runBehaviour (BBind (BWaitEvent event after) f) = runBehaviour
(BWaitEvent event (after = f))
runBehaviour (BBind (BIO a) f) = a = \x - runBehaviour (f x)
runBehaviour (BBind (BBind a f) g) = runBehaviour (a = (\x - f x = g))
runBehaviour (BIO a) = a
runBehaviour (BWaitEvent event after) =
do sigIdRef - newIORef (error You can't access sigIdRef before
signal is connected)
sigId - event $
do sigId - readIORef sigIdRef
signalDisconnect sigId
runBehaviour after
return ()
writeIORef sigIdRef sigId
return (error You can't expect result from behaviour)
waitEvent :: GObjectClass obj = Event obj - Behaviour ()
waitEvent event = BWaitEvent event (return ())
main :: IO ()
main =
do initGUI
window - windowNew
onDestroy window mainQuit
set window [windowTitle := Hello World]
button - buttonNew
let buttonB label =
do liftIO $ set button [buttonLabel := label]
waitEvent (onClicked button)
buttonB (label ++ *)
runBehaviour (buttonB *)
set window [containerChild := button]
widgetShowAll window
mainGUI
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Mario Blazevic
mblaze...@stilo.com
Stilo International
This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI programming
Hello,
I've been writing some GUI application with Gtk2hs. It's an
interpreter for lambda-calculus and combinatory logic, it's GPL and if
you interested I can share it with cafe.
The problem is that the GUI code has become very ugly and I'm tempted
to rewrite it totally. I've been looking forward to the FRP stuff, but
I've never seen a single definition of the term. Conal Eliot's
denotational programming is too general to be definition. I want to
try Grapefruit, but I got totally lost when I see arrow notation.
I consider more lightweight and more imperative approach, something
closer to CSP (Communicating Secuential Processes) then FRP. I've just
crafted some sample program to illustrate my idea.
The behaviour is a monad and it's IO monad so you can do any IO
(Gtk2hs) programming you wish. The differences is that you don't
attach static event handlers and tries to determine what to do
dependent on application state. You attach and detach handlers as much
as possible. Behaviour looks like a process that can stop execution
and wait for some GUI event. When event arrived it continues
execution.
Do you see this approach viable. There are steel some details to emerge:
* How to wait for several events
* How to handle IO exceptions
Here is the code:
{-# LANGUAGE ExistentialQuantification #-}
module Main where
import Data.IORef
import System.Glib
import Graphics.UI.Gtk
import Control.Monad.Trans
type Event obj = IO () - IO (ConnectId obj)
data Behaviour a =
forall b. BBind (Behaviour b) (b - Behaviour a)
| BIO (IO a)
| forall obj. GObjectClass obj = BWaitEvent (Event obj) (Behaviour a)
instance Monad Behaviour
where action = generator = BBind action generator
return a = BIO (return a)
instance MonadIO Behaviour
where liftIO action = BIO action
runBehaviour :: Behaviour a - IO a
runBehaviour (BBind (BWaitEvent event after) f) = runBehaviour
(BWaitEvent event (after = f))
runBehaviour (BBind (BIO a) f) = a = \x - runBehaviour (f x)
runBehaviour (BBind (BBind a f) g) = runBehaviour (a = (\x - f x = g))
runBehaviour (BIO a) = a
runBehaviour (BWaitEvent event after) =
do sigIdRef - newIORef (error You can't access sigIdRef before
signal is connected)
sigId - event $
do sigId - readIORef sigIdRef
signalDisconnect sigId
runBehaviour after
return ()
writeIORef sigIdRef sigId
return (error You can't expect result from behaviour)
waitEvent :: GObjectClass obj = Event obj - Behaviour ()
waitEvent event = BWaitEvent event (return ())
main :: IO ()
main =
do initGUI
window - windowNew
onDestroy window mainQuit
set window [windowTitle := Hello World]
button - buttonNew
let buttonB label =
do liftIO $ set button [buttonLabel := label]
waitEvent (onClicked button)
buttonB (label ++ *)
runBehaviour (buttonB *)
set window [containerChild := button]
widgetShowAll window
mainGUI
--
Victor Nazarov
{-# LANGUAGE ExistentialQuantification #-}
module Main where
import Data.IORef
import System.Glib
import Graphics.UI.Gtk
import Control.Monad.Trans
type Event obj = IO () - IO (ConnectId obj)
data Behaviour a =
forall b. BBind (Behaviour b) (b - Behaviour a)
| BIO (IO a)
| forall obj. GObjectClass obj = BWaitEvent (Event obj) (Behaviour a)
instance Monad Behaviour
where action = generator = BBind action generator
return a = BIO (return a)
instance MonadIO Behaviour
where liftIO action = BIO action
runBehaviour :: Behaviour a - IO a
runBehaviour (BBind (BWaitEvent event after) f) = runBehaviour (BWaitEvent event (after = f))
runBehaviour (BBind (BIO a) f) = a = \x - runBehaviour (f x)
runBehaviour (BBind (BBind a f) g) = runBehaviour (a = (\x - f x = g))
runBehaviour (BIO a) = a
runBehaviour (BWaitEvent event after) =
do sigIdRef - newIORef (error You can't access sigIdRef before signal is connected)
sigId - event $
do sigId - readIORef sigIdRef
signalDisconnect sigId
runBehaviour after
return ()
writeIORef sigIdRef sigId
return (error You can't expect result from behaviour)
waitEvent :: GObjectClass obj = Event obj - Behaviour ()
waitEvent event = BWaitEvent event (return ())
main :: IO ()
main =
do initGUI
window - windowNew
onDestroy window mainQuit
set window [windowTitle := Hello World]
button - buttonNew
let buttonB label =
do liftIO $ set button [buttonLabel := label]
waitEvent (onClicked button)
buttonB (label ++ *)
runBehaviour (buttonB *)
set window [containerChild := button]
widgetShowAll window
mainGUI
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI programming
Hello Victor,
2010/2/2, Victor Nazarov asviraspossi...@gmail.com:
I've been writing some GUI application with Gtk2hs. It's an
interpreter for lambda-calculus and combinatory logic, it's GPL and if
you interested I can share it with cafe.
Sure, why not?
I consider more lightweight and more imperative approach, something
closer to CSP (Communicating Secuential Processes) then FRP. I've just
crafted some sample program to illustrate my idea.
All this process calculus stuff reminds me of Fudgets. Maybe this
approach is more pragmatic at the moment: even more so, I think it's
theoretical underpinnings are appealing as well. Who said that all
programming should be reduced to pure functions? :-)
As a side note, there's a book How to Design Worlds which discusses
interactive purely functional programming (using games as an example).
While it is only tangentially related to GUI programming, I wonder if
their approach can be adapted for use in GUIs.
Cheers,
Artyom Shalkhakov
The behaviour is a monad and it's IO monad so you can do any IO
(Gtk2hs) programming you wish. The differences is that you don't
attach static event handlers and tries to determine what to do
dependent on application state. You attach and detach handlers as much
as possible. Behaviour looks like a process that can stop execution
and wait for some GUI event. When event arrived it continues
execution.
Do you see this approach viable. There are steel some details to emerge:
* How to wait for several events
* How to handle IO exceptions
Here is the code:
{-# LANGUAGE ExistentialQuantification #-}
module Main where
import Data.IORef
import System.Glib
import Graphics.UI.Gtk
import Control.Monad.Trans
type Event obj = IO () - IO (ConnectId obj)
data Behaviour a =
forall b. BBind (Behaviour b) (b - Behaviour a)
| BIO (IO a)
| forall obj. GObjectClass obj = BWaitEvent (Event obj) (Behaviour a)
instance Monad Behaviour
where action = generator = BBind action generator
return a = BIO (return a)
instance MonadIO Behaviour
where liftIO action = BIO action
runBehaviour :: Behaviour a - IO a
runBehaviour (BBind (BWaitEvent event after) f) = runBehaviour
(BWaitEvent event (after = f))
runBehaviour (BBind (BIO a) f) = a = \x - runBehaviour (f x)
runBehaviour (BBind (BBind a f) g) = runBehaviour (a = (\x - f x = g))
runBehaviour (BIO a) = a
runBehaviour (BWaitEvent event after) =
do sigIdRef - newIORef (error You can't access sigIdRef before
signal is connected)
sigId - event $
do sigId - readIORef sigIdRef
signalDisconnect sigId
runBehaviour after
return ()
writeIORef sigIdRef sigId
return (error You can't expect result from behaviour)
waitEvent :: GObjectClass obj = Event obj - Behaviour ()
waitEvent event = BWaitEvent event (return ())
main :: IO ()
main =
do initGUI
window - windowNew
onDestroy window mainQuit
set window [windowTitle := Hello World]
button - buttonNew
let buttonB label =
do liftIO $ set button [buttonLabel := label]
waitEvent (onClicked button)
buttonB (label ++ *)
runBehaviour (buttonB *)
set window [containerChild := button]
widgetShowAll window
mainGUI
--
Victor Nazarov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI: Custom widgets - wxHaskell or gtk2hs ?
Hi, I need to create a custom widget and I wonder which of the above gui-toolkits makes that easier. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] GUI library
Deallocation is automatic (just like C++ Qt) C++ Qt has excellent unicode support. I haven't explicit tried it in qtHaskell, but as far as I know it should work just fine. Unfortunatly it does not currently build just with cabal, however the build scripts are very clean (no configure) and the haskell half is cabalized. To build on windows you only need the haskell platform and the Qt SDK (and then you either have to put the ghc path into Qts qtEnv.bat (what I did), or you have to put the Qt paths into the system path) and then you run the qtHaskells build.bat and you're done. To build on linux you need the haskell platform and Qt4 dev libraries (they are probably in your distros package manager) and then you run the qtHaskells build script, and your done. Umm, with one gotcha, on my system I had to replace two instances of 'gmake' in the build script with 'make'. You might not have to do that on your system. Qt uses the native APIs to draw controls, so your apps look appropriate on different platforms. - Job On Tue, Sep 1, 2009 at 12:43 AM, Bulat Ziganshin bulat.zigans...@gmail.comwrote: Hello Job, Tuesday, September 1, 2009, 1:16:38 AM, you wrote: I recommend qtHaskell. how it's in areas of - memory deallocation when it's no more need - is it automatic or manual? - unicode support - compatibiliy with latest ghc versions - does it build by Cabal or we need to wait while gurus release installers for Windows? - does it use native GUI controls on Windows or draws them itself? i'm asking because those questions arise when using other libs -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI library
If you're already used to C++ Qt and PyQt, qtHaskell should be relatively straightforward (though probably with a few gotchas). You could download qtHaskell and look at the examples to get an idea for the feel of it. If you're already used to Qt they should look familiar. Subclassing _is_ done a little weird: First you declare a dummy datatype: data MyQPushButton = MyQPushButton And then you use the qSubClass function: myQPushButton :: String - IO (QPushButton MyQPushButton) myQPushButton s = qSubClass $ qPushButton1 s The type signature here is necessary. It's the only thing that forces the new (QPushButton a) to be a QPushButton MyQPushButton. Then you can use your subclassed buttons like so: main :: IO () main = do app - qApplication dialog - qDialog button1 - myQPushButton Click for Stuff qObject_connectSlot1 button1 clicked() button1 click() $ on_pbutton_clicked dialog mainLayout - qVBoxLayout qLayout_addWidget mainLayout button1 qWidget_setLayout dialog mainLayout qWidget_setWindowTitle dialog Stuff Test ok - qDialog_exec dialog return() on_pbutton_clicked :: QDialog () - QPushButton MyQPushButton - IO () on_pbutton_clicked _dlg _this = do mb - qMessageBox1 _dlg qMessageBox_setText mb $ Stuff qWidget_show mb return () Hmmm, though it doesn't look like you can currently overload methods of your parent class, usually you don't need too though as you can just tie into a signal (so you still can do things like paint). Though I'm kinda suprised I didn't notice this before, I'll have to email the guy and see if this is actually an issue. Also, qtHaskell doesn't fully support all the Qt widgets (though it covers most of them) but there is a new version coming out soon that should be more complete. Overall qtHaskell has served my perposes well. There is also a good listing of GUI toolkits for Haskell at http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries - Job On Tue, Sep 1, 2009 at 1:49 AM, Michael Mossey m...@alumni.caltech.eduwrote: Thanks for the info. Interesting. I'm already familiar with C++ Qt and also PyQt. I am also a fan of Qt. However, as a beginner to Haskell, I want to be sure I don't get myself into trouble. I hope that qtHaskell is straightforward. Qt depends on deriving user classes. How is this handled in qtHaskell? Thanks, -Mike Job Vranish wrote: I recommend qtHaskell. I am a big fan of Qt in general. It has good documentation and extensive examples, is very well designed, and has a good license. I'd even say the C++ version is good choice for beginners (certainly easier to understand/use than say GTK). The qtHaskell bindings are also pretty good. The documentation and examples are not as extensive, but you can usually use the C++ documentation to fill in the gaps. Being already familiar with C++ Qt, using qtHaskell was a snap. However, if you're unfamiliar with both Qt and Haskell it will probably be confusing at first. Though I'd bet money the GTK bindings aren't any better in that regard. I'd still say you'd be more productive with qtHaskell in the long run. - Job On Sat, Aug 29, 2009 at 11:03 AM, Michael Mossey m...@alumni.caltech.edumailto: m...@alumni.caltech.edu wrote: I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) I decided to use Haskell for its great features as a functional programming language. Regarding a choice of GUI library, I want these factors: - it needs to provide at a minimum a drawing surface, a place I can draw lines and insert characters, in addition to all the standard widgets and layout capabilities we have to come to expect from a GUI library. - This is a Windows application. - it needs to be non-confusing for an intermediate-beginner Haskeller. Hopefully good documentation and examples will exist on the web. - It might be nice to have advanced graphics capability such as Qt provides, things like antialiasied shapes, and a canvas with efficient refresh (refereshes only the area that was exposed, and if your canvas items are only primitives, it can do refreshes from within C++ (no need to touch your Haskell code at all). However I'm wondering if qtHaskell fits my criteria well-documented and lots of examples aimed at beginners. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] GUI library
I recommend qtHaskell. I am a big fan of Qt in general. It has good documentation and extensive examples, is very well designed, and has a good license. I'd even say the C++ version is good choice for beginners (certainly easier to understand/use than say GTK). The qtHaskell bindings are also pretty good. The documentation and examples are not as extensive, but you can usually use the C++ documentation to fill in the gaps. Being already familiar with C++ Qt, using qtHaskell was a snap. However, if you're unfamiliar with both Qt and Haskell it will probably be confusing at first. Though I'd bet money the GTK bindings aren't any better in that regard. I'd still say you'd be more productive with qtHaskell in the long run. - Job On Sat, Aug 29, 2009 at 11:03 AM, Michael Mossey m...@alumni.caltech.eduwrote: I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) I decided to use Haskell for its great features as a functional programming language. Regarding a choice of GUI library, I want these factors: - it needs to provide at a minimum a drawing surface, a place I can draw lines and insert characters, in addition to all the standard widgets and layout capabilities we have to come to expect from a GUI library. - This is a Windows application. - it needs to be non-confusing for an intermediate-beginner Haskeller. Hopefully good documentation and examples will exist on the web. - It might be nice to have advanced graphics capability such as Qt provides, things like antialiasied shapes, and a canvas with efficient refresh (refereshes only the area that was exposed, and if your canvas items are only primitives, it can do refreshes from within C++ (no need to touch your Haskell code at all). However I'm wondering if qtHaskell fits my criteria well-documented and lots of examples aimed at beginners. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] GUI library
Hello Job, Tuesday, September 1, 2009, 1:16:38 AM, you wrote: I recommend qtHaskell. how it's in areas of - memory deallocation when it's no more need - is it automatic or manual? - unicode support - compatibiliy with latest ghc versions - does it build by Cabal or we need to wait while gurus release installers for Windows? - does it use native GUI controls on Windows or draws them itself? i'm asking because those questions arise when using other libs -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] GUI library
Hello Michael, Saturday, August 29, 2009, 8:52:41 PM, you wrote: about ugliness - look at http://freearc.org/Screenshots.aspx Hi Jean-Denis, Thanks for the information. Do you know how WxHaskell fits my needs? For example, does it have good docs and examples for a beginner? Does it have the ability to draw lines and characters on a surface? Does it have a type of canvas which usually refers to an optimized drawing surface? Thanks, Mike Jean-Denis Koeck wrote: I began writing a commercial app with a GUI using Gtk2hs, but it looked ugly on Windows. I'm switching to WxHaskell. 2009/8/29 Michael Mossey m...@alumni.caltech.edu mailto:m...@alumni.caltech.edu I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) I decided to use Haskell for its great features as a functional programming language. Regarding a choice of GUI library, I want these factors: - it needs to provide at a minimum a drawing surface, a place I can draw lines and insert characters, in addition to all the standard widgets and layout capabilities we have to come to expect from a GUI library. - This is a Windows application. - it needs to be non-confusing for an intermediate-beginner Haskeller. Hopefully good documentation and examples will exist on the web. - It might be nice to have advanced graphics capability such as Qt provides, things like antialiasied shapes, and a canvas with efficient refresh (refereshes only the area that was exposed, and if your canvas items are only primitives, it can do refreshes from within C++ (no need to touch your Haskell code at all). However I'm wondering if qtHaskell fits my criteria well-documented and lots of examples aimed at beginners. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI library
On Sat, 29 Aug 2009, Michael Mossey wrote: I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) Nice to know. Things in this direction are also implemented in http://hackage.haskell.org/package/haskore You find a lot about music programmed in Haskell in http://www.haskell.org/haskellwiki/Category:Music and in the haskell-art mailing list: http://lists.lurk.org/mailman/listinfo/haskell-art So, good luck with your GUI based music editor! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI library
I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) I decided to use Haskell for its great features as a functional programming language. Regarding a choice of GUI library, I want these factors: - it needs to provide at a minimum a drawing surface, a place I can draw lines and insert characters, in addition to all the standard widgets and layout capabilities we have to come to expect from a GUI library. - This is a Windows application. - it needs to be non-confusing for an intermediate-beginner Haskeller. Hopefully good documentation and examples will exist on the web. - It might be nice to have advanced graphics capability such as Qt provides, things like antialiasied shapes, and a canvas with efficient refresh (refereshes only the area that was exposed, and if your canvas items are only primitives, it can do refreshes from within C++ (no need to touch your Haskell code at all). However I'm wondering if qtHaskell fits my criteria well-documented and lots of examples aimed at beginners. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI library
Hi Jean-Denis, Thanks for the information. Do you know how WxHaskell fits my needs? For example, does it have good docs and examples for a beginner? Does it have the ability to draw lines and characters on a surface? Does it have a type of canvas which usually refers to an optimized drawing surface? Thanks, Mike Jean-Denis Koeck wrote: I began writing a commercial app with a GUI using Gtk2hs, but it looked ugly on Windows. I'm switching to WxHaskell. 2009/8/29 Michael Mossey m...@alumni.caltech.edu mailto:m...@alumni.caltech.edu I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) I decided to use Haskell for its great features as a functional programming language. Regarding a choice of GUI library, I want these factors: - it needs to provide at a minimum a drawing surface, a place I can draw lines and insert characters, in addition to all the standard widgets and layout capabilities we have to come to expect from a GUI library. - This is a Windows application. - it needs to be non-confusing for an intermediate-beginner Haskeller. Hopefully good documentation and examples will exist on the web. - It might be nice to have advanced graphics capability such as Qt provides, things like antialiasied shapes, and a canvas with efficient refresh (refereshes only the area that was exposed, and if your canvas items are only primitives, it can do refreshes from within C++ (no need to touch your Haskell code at all). However I'm wondering if qtHaskell fits my criteria well-documented and lots of examples aimed at beginners. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI library
On Sat, Aug 29, 2009 at 8:03 AM, Michael Mosseym...@alumni.caltech.edu wrote: I want to choose a GUI library for my project. Some background: I'm a beginner to functional programming and have been working through Haskell books for a few months now. I'm not just learning Haskell for s**ts and giggles; my purpose is to write music-composition-related code; in particular, I want to write a graphical musical score editor. (Why write my own editor, you may ask? Because I want to fully integrate it with computer-assisted-composition algorithms that I plan to write, also in Haskell.) I decided to use Haskell for its great features as a functional programming language. Regarding a choice of GUI library, I want these factors: - it needs to provide at a minimum a drawing surface, a place I can draw lines and insert characters, in addition to all the standard widgets and layout capabilities we have to come to expect from a GUI library. - This is a Windows application. - it needs to be non-confusing for an intermediate-beginner Haskeller. Hopefully good documentation and examples will exist on the web. - It might be nice to have advanced graphics capability such as Qt provides, things like antialiasied shapes, and a canvas with efficient refresh (refereshes only the area that was exposed, and if your canvas items are only primitives, it can do refreshes from within C++ (no need to touch your Haskell code at all). However I'm wondering if qtHaskell fits my criteria well-documented and lots of examples aimed at beginners. I've never used it myself, but if you're going to be drawing a lot perhaps cairo is right for you? http://cairographics.org/hscairo/ I suspect you'll have to be self-taught here. Gtk2Hs and WxHaskell are probably the most mature gui libs for Haskell. Yet with either one you may end up dropping down into GDI/GDI+ or opengl on windows to get what you want. GDI/GDI+ is confusing in any language, but good books/resources do exist. So perhaps the trick here is to translate good documentation from other languages/sources into Haskell examples. You could do this as a warm up exercise before starting on your music editor. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI library
Jason Dagit wrote: I've never used it myself, but if you're going to be drawing a lot perhaps cairo is right for you? http://cairographics.org/hscairo/ I suspect you'll have to be self-taught here. Gtk2Hs and WxHaskell are probably the most mature gui libs for Haskell. Yet with either one you may end up dropping down into GDI/GDI+ or opengl on windows to get what you want. GDI/GDI+ is confusing in any language, but good books/resources do exist. So perhaps the trick here is to translate good documentation from other languages/sources into Haskell examples. You could do this as a warm up exercise before starting on your music editor. Jason Thanks, Jason. My drawing needs are pretty rudimentary. A music editor doesn't need much more than the ability to draw lines and characters. A nice addition would be antialiased curves such as Qt offers but that is optional. A so-called canvas sometimes offers optimized drawing updates, so the editor doesn't have to redraw the entire page if one portion of it changes. That is not strictly necessary, and in fact it wouldn't be hard to implement a bit of that functionality myself. -Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI and background processing
Greetings, fellow haskellers. Currently I'm writing some kind of web crawler in haskell with gtk2hs gui. All network operations are run in separate thread, but sometimes input from user is needed. Afaik, gtk2hs is not thread safe, so I came up with following: I create two mvars, A and B, one for question, one for answer. Worker thread puts question in A and blocks trying to take B. Gui thread checks for question by polling with tryTakeMVar. Then question is ready, it asks user and puts his answer into B. Worker awakens and continues processing. Also, for progress report, I use a Chan which is written to by worker and is read by polling by gui thread. This scheme works, but I don't like it. All these mvars and chans create too much clutter, and polling looks rather ugly too. Is there a better way for implementing similar patterns of interaction? Best regards, Dmitry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI and background processing
Hello Dmitry, Monday, June 1, 2009, 4:24:36 PM, you wrote: All network operations are run in separate thread, but sometimes input from user is needed. Afaik, gtk2hs is not thread safe, so I came up with look for postGUISync and postGUIASync -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI semantics [was: Achim ranting]
First of all, thanks. I had almost judged the cafe to be unable to discuss any UI issue except rendering backends. Fraser Wilson blancoli...@gmail.com wrote: You know, I read the Fudgets thesis, and threw together an experiment which used Glade for layout and Haskell for semantics [1]. As somebody else noted, this isn't really a clean division, because of things like editable flags in the layout. The darcs repository has a couple of demo applications, there's also a Bridge game that doesn't quite work (not included), and I understand that Arrows would solve all my problems, but I still don't grok them, alas. It depends on what you may flag as editable. I just re-watched Conal's techtalk about TV's, which short-circuited a few neurons that were held apart by things like Functors and the ilk: Flagging an input as editable or not is OK, flagging an output is not (duh). In retrospect, TV's appear to me as being too denotationalistic[1]: From what I can tell, the way a String is displayed is _solely_ controlled by the run* functions. In a line-oriented text environment there's only one way, so it doesn't matter, but in a GUI, you might want to display it either as a label, or as an input-disabled textbox (so the user can copy the string). It might also be the text of a button, or the label of a node edge in a graph editor. Reactive gives us a way to describe the String (and other things) as a function of time, now we need to figure out how to describe the rest of its properties: A thing is not only defined by its inherent properties, but also by its interaction with the rest of the world. A hungry cat next to a mouse behaves different from a hungry cat next to a stone; how can we make a String aware of being the input of a label vs. being the input of a textbox, without shoving all knowledge of interaction into the world itself? Can we avoid specifying into textbox or into label (or in 14.5pt slanted Helvetica) if we don't care or the rendering backend just doesn't support it? Can we specify a new renderer that knows about a new attribute, and enrich our model with that attribute without changing the whole core? What I found was that wiring the events through the application in a nice, functional way was quite tricky, but it was unclear whether this was just an API problem, or something more fundamental. The entire state seems to turn up in every connection between widgets (which really suggests that it's imperative with a veneer of declarative style, which of course it is). I've also noticed this. Right now, my code would thread one event stream through everything, splitting and rejoining as necessary, but always uni-directional and staying one stream[2]. If I wanted feedback (I do, but haven't actually implemented it), I'd send an event down the stream, collect it at the end, and sink it back into the beginning (via IO, that is, threads and mvars). I bet there's a way to define fixpoints on event streams so that feedback does not have to take a full round-trip, and, most importantly, can flow on more paths than one, and I'm absolutely positive that it would break my current model (which, most likely, would be a good thing to do). I'm also not using Behaviours at all, which annoys me: I'd say textbox, change the string of that label if you're changed, not label, you form a Widget behaviour influenced by the string output of that Widget over there (which happens to be a textbox). I guess that once I understand what fixpoints mean in this context, stuff will clear up a lot. [1] TM. [2] It is modelled as a tuple of two streams of different type, one getting drained by handling functions, the other filled. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
I have just successfully built Gtk2Hs against the native Mac OS X port of Gtk at: http://developer.imendio.com/projects/gtk-macosx This implies we can now use Gtk2Hs on the Mac without X11. The sample apps still look rather alien compared to normal Mac apps, but they are a big improvement over the X11 version. Regards, Neil On 12 Dec 2007, at 19:40, Miguel Mitrofanov wrote: Is there any really cross-platform GUI library for Haskell? Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. I was able to install wxHaskell (after some hacking - this was really painful); and Blobs editor compiled successfully, but then resisted to run. Tk-based libraries seem to be good, and Tk can be run natively on Mac (i.e., without X), but none of them seem to compile. Sorry if this message seems like I'm angry; I am, but that's only for a moment. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI
Is there any really cross-platform GUI library for Haskell? Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. I was able to install wxHaskell (after some hacking - this was really painful); and Blobs editor compiled successfully, but then resisted to run. Tk-based libraries seem to be good, and Tk can be run natively on Mac (i.e., without X), but none of them seem to compile. Sorry if this message seems like I'm angry; I am, but that's only for a moment. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
On Dec 12, 2007 5:40 PM, Miguel Mitrofanov [EMAIL PROTECTED] wrote: Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. Gtk is going native on Mac: http://developer.imendio.com/projects/gtk-macosx . The Gtk# guys are starting to try it now, and they're using a reasonably big software as test case: http://tirania.org/blog/archive/2007/Dec-02-2.html . So I guess going with Gtk2Hs isn't a bad path. Well, I confess I don't have a Mac, but it looks like things are getting better =). HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
I prefer the elegant high-level style of wxhaskell over the current state of gtk2hs. duncan has said he's interested in making a gtk2hs more elegant, and daan has said he'll start supporting wxhaskell again. i don't know which will happen first. - Conal On Dec 12, 2007 11:47 AM, Neil Mitchell [EMAIL PROTECTED] wrote: Hi Is there any really cross-platform GUI library for Haskell? Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. On Windows, Gtk2hs is not as native as wxHaskell, but is the best GUI toolkit available. On Windows, there is no requirement to have X installed. The Gtk2hs developers (or more specifically Duncan) have shown a continuing desire to make Gtk2hs more Windows friendly, even to the point of filing Gtk bugs and tracking their progress. I'm sure having made Mac friendly noises, they will come rushing to your aid :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
On Dec 12, 2007, at 14:51 , Felipe Lessa wrote: On Dec 12, 2007 5:40 PM, Miguel Mitrofanov [EMAIL PROTECTED] wrote: Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. Gtk is going native on Mac: http://developer.imendio.com/projects/ gtk-macosx . Huh. I found the sourceforge project, which seems to have died in 2003; this looks a bit more hopeful. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
Hi Is there any really cross-platform GUI library for Haskell? Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. On Windows, Gtk2hs is not as native as wxHaskell, but is the best GUI toolkit available. On Windows, there is no requirement to have X installed. The Gtk2hs developers (or more specifically Duncan) have shown a continuing desire to make Gtk2hs more Windows friendly, even to the point of filing Gtk bugs and tracking their progress. I'm sure having made Mac friendly noises, they will come rushing to your aid :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
Am Mittwoch, 12. Dezember 2007 schrieb Miguel Mitrofanov: Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but it's not native on my Mac; some Mac users don't install it and almost all Mac users don't always run it. the problem is Apple. if you want to have a native gui on OSX then you are either nearly stuck to Objective-C or to obsolete gui libraries. i'm not a mac user, but i know one who is; he told me. on osx there are two main gui apis: carbon and cocoa. carbon is obsolete, but it partially runs on osx -- it is not 64bit compatible. http://en.wikipedia.org/wiki/Carbon_%28API%29 cocoa is the newer one, which every mac user likes. AFAIK there is no C backend to that api, so you will have to develop a C backend first and then the haskell (or gtk2) wrapper. there are some bindings for other languages, i.e. C#, but no C. http://en.wikipedia.org/wiki/Carbon_%28API%29 if you are able to code objective-c and know how to access cocoa using c, please help those gtk developers to port gtk2 to native OSX. it will then automagically work with gtk2hs. - marc signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
| abi compatibility would be very nice to have (if the library/binding | code | doesn't change, newer ghc major versions should still be able to link | to | bindings compiled with older ones). that is only going to become more | important as fewer libraries are going to be shipped with ghc itself | now | (also with dynamically linked libraries). That is all true. ABI compatibility would be nice. But I don't see how to combine with GHC's other goals. Notably, we frequently add new information to interface files, and it would be a major constraint not to be able to do so. For the present at any rate, ABI incompatibility between major releases seems like the lesser evil. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
That is all true. ABI compatibility would be nice. But I don't see how to combine with GHC's other goals. Notably, we frequently add new information to interface files, and it would be a major constraint not to be able to do so. that is the bit i never quite understood: if newer formats just add information, that should be no problem. the problem, presumably, comes when newer ghcs can no longer manage without that extra information. so, if ghc was truly upgraded (add things, improve things) instead of modified (add some, take away some), then it should be able to work with old compiled libs at least as well as its previous version would have. just that it could do even better if it was allowed to recompile the old lib itself.. what am i missing? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
I'm not sure if you're talking about C++ ABIs or C ABIs? If you're already using a C ABI, and you're getting incompatibilities, well I have nothing useful to say :-) If you're talking about C++ ABIs, technically it's possible to use a Generator to drop-down into a C ABI, pump across the interface at a C level, function by function, then wrap back into C++ classes. The advantage is that you decouple the classes on either side of the interface, so it's possible to add new methods to the classes without breaking anything. (Warning: I have no idea to what extent what I just wrote relates to ghc etc. I did make a generator to cross a C++ ABI boundary before, to link an msvc C++ dll with a mingw C++ exe: http://spring.clan-sy.com/phpbb/viewtopic.php?t=7991 ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
| You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version. Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On 7/19/07, Claus Reinke [EMAIL PROTECTED] wrote: the idea is well known: build your app as a server, and put an ajax-based gui in front of it, even if server and browser run on the same machine. A more desktopy alternative: http://www.gtk-server.org/ martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no [...] - bug report
as Marc pointed out, there was a problem with my javascript use that showed up as an event error in firefox. Miguel has suggested how to remove that issue. i've also added commands to set the colour explicitly, and to move to the origin after translation, so that firefox now draws whole squares, rather than leaving out the first line. having just upgraded my opera (so much smaller and easier than full gui libs;-), the modified code appears to work with opera (9.22) and firefox (1.5.0.6), on windows, using ghc 6.6.1. to avoid spamming this list, i've put the updated code and a couple of screenshots online at: http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/browsing/ please note that this code is not at all pretty, but is meant to show most of the necessary pieces. if you want to use the idea seriously, the haskell code would need cleaning up, the html/javascript would need checking for standard compliance (there are several standards involved, so it is tempting to code by modifying examples, which are not always correct, even if they work on some browser). you might also want to consider using one of the many javascript/ ajax browser gui frameworks, if only to isolate you from browser incompatibilities. but even if you code to a single standard-compliant browser, your clients might find it easier to download and install that than a full gui-lib binding. hth, claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
| You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version. Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you. it may indeed only be major versions, but that is troublesome enough. at one point, i had the then current 6.4.2, the upcoming 6.6, and head, and then there are of course those heads up mails for head, suggesting rebuilds of all libraries.. i was using wxhaskell instead of gtk2hs, but that had the same issues (even worse when there was no maintainer, as ghc moved on, there were no lib binaries for new ghc versions, and any existing lib binaries for old ghc versions were useless..). abi compatibility would be very nice to have (if the library/binding code doesn't change, newer ghc major versions should still be able to link to bindings compiled with older ones). that is only going to become more important as fewer libraries are going to be shipped with ghc itself now (also with dynamically linked libraries). is there even tool support for i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version.? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 12:07 +0100, Claus Reinke wrote: the idea is well known: build your app as a server, and put an ajax-based gui in front of it, even if server and browser run on the same machine. A more desktopy alternative: http://www.gtk-server.org/ that looks promising. does that mean one could have the best of both worlds - gtk2hs were available, gtk-server everywhere else? or does this require different code? It'd certainly requires different code internally to present the same API that Gtk2Hs provides. even so, it might be worth it to get a single gui framework working with all haskell implementations and all ghc versions. It would not change the problem with ghc versions. Gtk2Hs does and (almost) always has worked with all versions of GHC, the problem is only the Windows binary builds that are specific to one version of ghc - as are all other binary builds of ghc packages. Using gtk-server would not change that. or perhaps gtk2hs could offer a bridge to hide any differences between direct and server style code? That sounds like a lot of work, probably more work than making the current Gtk2Hs code base work with hugs and yhc. And as I say, it would not solve the ghc binary build version issue. One advantage though would be that a GUI api that used gtk-server would not use any FFI and so would not require any header files installed on the target machine so it'd be easier to distribute as source that any end user could build (where as building Gtk2Hs or wxHaskell from source on Windows is non-trivial.) Personally I'd rather spend any effort elsewhere, like binding more of the Gtk+ api, or providing new simple graphics apis on top of Gtk2Hs, or setting up automatic Windows builds so that there are always installers available for all current and recent ghc versions. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 10:06 +0100, Simon Peyton-Jones wrote: | You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version. Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you. Yes, I've always been confused by that. You go to some effort to not change the binary format of .hi files or change the ABI of the RTS etc and yet ghc explicitly checks that the .hi files are exactly the same version preventing any mixing anyway: Foo.hs: module Foo where foo = 3 Bar.hs module Bar where import Foo bar = foo + foo $ ghc-6.6 -c Foo.hs $ ghc-6.6.1 -c Bar.hs Bar.hs:3:0: Bad interface file: Foo.hi mismatched interface file versions: expected 6061, found 6060 So yes, that's why the Gtk2Hs 0.9.11 Windows installer checks for exactly ghc-6.6 and not 6.6.x in general. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 12:02 +0100, Claus Reinke wrote: is there even tool support for i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version.? Gentoo has such a tool. The ghc ebuild instructs users to run ghc-updater after upgrading ghc. It identifies all ghc library packages that portage installed for all other versions of ghc and re-emerges them in the correct order (possibly upgrading them at the same time). It'd probably be a useful feature to include in cabal-install. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 13:01 +0100, Duncan Coutts wrote: On Thu, 2007-07-19 at 10:06 +0100, Simon Peyton-Jones wrote: | You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version. Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you. Yes, I've always been confused by that. You go to some effort to not change the binary format of .hi files or change the ABI of the RTS etc and yet ghc explicitly checks that the .hi files are exactly the same version preventing any mixing anyway: This is where you go in and hack the version, but I'll shut up now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
is there even tool support for i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version.? We will have soon. The nix distribution system will be able to do exactly this. You pass a ghc compiler for each build description. Passing another and reinstalling a package will cause all dependencies to be rebuild as well. I'm working on this. I'v already around 100 packages installed from hackage. (But no gui lib yet) I hope that this all will work at least to be able to test within the following 2 weeks. (But things may change) Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
gui libs are wonderful, but haskell sometimes has too few and sometimes has too many. and those we have do not work with every haskell implementation. and when they do work (usually with ghc, these days), they need to be rebuilt whenever ghc is updated, even if the gui lib hasn't changed at all (one gui lib binding per ghc version). still, we put up with that when we need all those gui lib features, because we have to, and we're happy to live in one of those periods when there are such bindings to full-featured gui libraries. but what about quick and dirty/cheap and cheerful graphics? over the years, HGL/SOEGraphics has served as a persistent reminder that things keep changing, and that when they do, something breaks. even if all people want to do is draw some simple graphics, or animations. i don't have a solution, but i'd like to throw another alternative into the ring, based on the ongoing fight between web browsers and other guis for world dominance.. the idea is well known: build your app as a server, and put an ajax-based gui in front of it, even if server and browser run on the same machine. attached is a silly quickdirty demo of some of the relevant concepts, including a fake haskell http-server, an html/canvas/httprequest/ javascript-based gui, and some simple graphics/buttons/text. tested on windows, with opera 9.01 and ghc 6.6.1. it will probably not work with other browsers, but it should work with opera on other platforms, or with other haskell implementations supporting Network. (you might have to hardcode the file name at the top of the source if not using ghc; to make it work with other browsers, you need workarounds for standard browser incompatibilities) to run, load Canvas.hs into ghci and call main. then start up opera, and visit 'http://localhost:8000/start' (to change that port number, change both 'main' in the haskell source, and 'get' in the html source). that should yield an html page with further instructions. have a look, and please let me know if it works on your os/ haskell implementation, and what you think about the idea. i won't do it myself, but perhaps someone could code up SOEGraphics based on this?-) and if not, this might still help out some of you who need simple low-overhead guis (things can get hairy very quickly if you need more than simple guis)? some of you might have to fight through implementing browser- based guis for their day jobs anyhow, but may want to put haskell behind those guis; or you might find haskell prototyping an easier sell, if the gui can be reused for the real implementation.. claus further reading/download: Opera browser (windows, macos, solaris, linux, ..) http://www.opera.com/download/ html 5 -- working draft, june 2007 (3.14.11 canvas element) http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas tutorial http://developer.mozilla.org/en/docs/Canvas_tutorial http://developer.mozilla.org/en/docs/Drawing_Graphics_with_Canvas Canvas.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 00:12 +0100, Claus Reinke wrote: gui libs are wonderful, but haskell sometimes has too few and sometimes has too many. and those we have do not work with every haskell implementation. and when they do work (usually with ghc, these days), they need to be rebuilt whenever ghc is updated, even if the gui lib hasn't changed at all (one gui lib binding per ghc version). still, we put up with that when we need all those gui lib features, because we have to, and we're happy to live in one of those periods when there are such bindings to full-featured gui libraries. You're right, that's annoying. It's particularly a problem for Windows GHC users who expect pre-built binaries, since GHC currently requires all libs to be rebuilt with each new minor GHC version. It's particularly annoying for GUI libs which are non-trivial to build from source (due to needing so many C header files and such) and so there is always a lag between when GHC gets updated and when someone (me) gets round to making a new binary build for Windows. Our hope is that we can get Gtk2Hs working with Yhc some day. That'd be interesting because it shouldn't have the same versionitis issues and the same compiled GUI program should run unaltered on Windows, Linux or OSX (and several others). but what about quick and dirty/cheap and cheerful graphics? over the years, HGL/SOEGraphics has served as a persistent reminder that things keep changing, and that when they do, something breaks. even if all people want to do is draw some simple graphics, or animations. There's a SOEGraphics implementation with Gtk2Hs, but then of course see problem 1. :-) i don't have a solution, but i'd like to throw another alternative into the ring, based on the ongoing fight between web browsers and other guis for world dominance.. [..] Sounds fun! :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no [...] - bug report
Hi Claus Ising ghc-6.6 and Opera 9.20 i thought that everything would work until I tried the page in Firefox 2.0.0.1 Opera: Those maroon rectangles in all four corners appear, alse the text x/y: ... is shown when clicking. But the drawing doesn't appear, does'n show any errors within the Error Console either. In Firefox (2.0.0.3) Firebug does show the JS error: evt has no properties clicked()start (line 63) onclick(click clientX=0, clientY=0)start (line 1) addLabel(evt.clientX,evt.clientY) But the drawing ( |_| rotating clockwise) appears. Clicking has no effect If you don't know it yet mootools is a really nice JS framework providing transition suppert etc. Perhaps this might be useful somehow as well. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
On Tue, 2006-03-14 at 09:45 +0300, Dmitry V'yal wrote: Christophe Poucet wrote: I have to concur with Duncan. I started using Gtk2Hs for a small project and literally within a couple hours I had a good understanding upon which to build a nice gui as well as the gui itself. I haven't tried out wxhaskell, but trying gtk2hs and it's cairo bindings, I fell in love with the simplicity. Cheers I like gtk2hs too. I used it to make gui for my several toy projects. My experience was mostly positive, but I had some troubles: First of all, it's just a binding to GTK+, so if you don't have an expirience with it (as in my case), you have to learn both GTK+ and gtk2hs simultaneously. Yeah, we know we're rather lacking in Haskell-oriented tutorials. It's something we hope to have done for our upcoming 1.0 release. Secondly, I'm absolutely not satisfied with a size of produced binaries. I hope, I just made something wrong, but I got a 3 megabyte behemot after compiling and stripping my 300-line program. I compiled it with ghc-6.4.1 with ghc --make Main.hs. objdump -T shows a myriad of symbols with gtk_ prefix and I have a hard time guessing what most of them are doing where :) You didn't do anything wrong. By default that's what happens with large libs built with ghc. However, the current development version (and so the next release version) of Gtk2Hs has support for ghc's split objects feature. With this, a simple Gtk2Hs Hello world program is only 30% larger than a trivial Haskell hello world program (main = putStr Hello World!). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
Duncan Coutts wrote: You didn't do anything wrong. By default that's what happens with large libs built with ghc. However, the current development version (and so the next release version) of Gtk2Hs has support for ghc's split objects feature. With this, a simple Gtk2Hs Hello world program is only 30% larger than a trivial Haskell hello world program (main = putStr Hello World!). Duncan Then I'm waiting impatiently for the next release. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
Okay, I've got myself gtk2hs now (and remebered what shied me away the first time: click on dowload opens Pandora's cookie box). Seems to work, although linking takes ages and the binaries are awe-inspiringly huge. Now two questions remain (well, two I find fit to post here): - is there a user-manual or tutorial ? - when building with --enable-docs, how far should the ghc-docdir-path reach? I tried /usr/local/share/ghc-6.4.1/html/libraries and /usr/local/share/ghc-6.4.1/html and was confronted with lots of WARNING: could not resolve ... in both cases. Cheers, Daniel Am Montag, 13. März 2006 10:11 schrieben Sie: On Mon, 2006-03-13 at 09:58 +0100, Daniel Fischer wrote: Hello All, how would I get myself a working (and easy to use) GUI-library? There are two main GUI libraries at the moment: Gtk2Hs and wxHaskell. http://haskell.org/gtk2hs/ http://wxhaskell.sourceforge.net/ Both will work with current versions of GHC etc. You can either use distro packages if they're available for your distro or build from source. Personally I'd recommend Gtk2Hs but then I'm biased because I help maintain Gtk2Hs :-). Duncan -- In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
On Tue, 2006-03-14 at 17:15 +0100, Daniel Fischer wrote: Okay, I've got myself gtk2hs now (and remebered what shied me away the first time: click on dowload opens Pandora's cookie box). Seems to work, although linking takes ages and the binaries are awe-inspiringly huge. Now two questions remain (well, two I find fit to post here): - is there a user-manual or tutorial ? - when building with --enable-docs, how far should the ghc-docdir-path reach? I tried /usr/local/share/ghc-6.4.1/html/libraries and /usr/local/share/ghc-6.4.1/html and was confronted with lots of WARNING: could not resolve ... in both cases. Even when it works perfectly we still get lots of WARNING: could not resolve There are broken cross references in our docs. We've been fixing these but they're not as high a priority as many other things. You can tell if the docs are linking to the ghc base docs if you don't get warnings about not being able to resolve things like Int and String. Rather embarrassingly, it turns out that --ghc-docdir does nothing at all. It has been a broken option for a couple years. Other people noticed it too recently. I'll be replaced or fixed in the next version. In the mean time I think yo might be able to get the effect with: make HADDOCK=haddock --use-package=base or whatever other options you need. Otherwise you'll have to make do with docs that are not linked to the ghc base docs (which is not such a great hardship since almost all the links to things in the base package are just for simple types). Or use the docs online which link to the docs on the ghc website. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI-Woes
Hello All, how would I get myself a working (and easy to use) GUI-library? Fudgets looks good, but I couldn't get it to build. I downloaded the snapshot from 2005, how to compile says make ghc-all; make ghc-install, but it doesn't work. First, in several scripts/makefiles, the ghc version 4.06 was hardwired, after some editing make complained about not finding lmlmk, whatever that is. If that's all that I would need to build it successfully, where would I get it? I also tried FranTk, doesn't look bad either, but has ghc -version 4.04 hardwired, imports IOExts, which I think would have to be replaced with GHC.Exts, and Addr, which I have no clue what it should be now, anyway, it seems pre-hierarchical-libraries, which would mean a lot of editing the source-files. So, since Fudgets does work in principle, - which version should I use and where do I get it? - what else would I have to download to get it to build? - in case it isn't straightforward, how to build it? I have a linux machine with ghc-6.4.1 and hugs, no HBC, NHC, JHC,..., no GTk2hs (would I need that?). Thanks, Daniel -- In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
On Mon, 2006-03-13 at 09:58 +0100, Daniel Fischer wrote: Hello All, how would I get myself a working (and easy to use) GUI-library? There are two main GUI libraries at the moment: Gtk2Hs and wxHaskell. http://haskell.org/gtk2hs/ http://wxhaskell.sourceforge.net/ Both will work with current versions of GHC etc. You can either use distro packages if they're available for your distro or build from source. Personally I'd recommend Gtk2Hs but then I'm biased because I help maintain Gtk2Hs :-). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
I have to concur with Duncan.I started using Gtk2Hs for a small project and literally within a couple hours I had a good understanding upon which to build a nice gui as well as the gui itself. I haven't tried out wxhaskell, but trying gtk2hs and it's cairo bindings, I fell in love with the simplicity. CheersOn 3/13/06, Duncan Coutts [EMAIL PROTECTED] wrote: On Mon, 2006-03-13 at 09:58 +0100, Daniel Fischer wrote: Hello All, how would I get myself a working (and easy to use) GUI-library?There are two main GUI libraries at the moment: Gtk2Hs and wxHaskell. http://haskell.org/gtk2hs/http://wxhaskell.sourceforge.net/Both will work with current versions of GHC etc. You can either use distro packages if they're available for your distro or build fromsource.Personally I'd recommend Gtk2Hs but then I'm biased because I helpmaintain Gtk2Hs :-).Duncan___ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI-Woes
Christophe Poucet wrote: I have to concur with Duncan. I started using Gtk2Hs for a small project and literally within a couple hours I had a good understanding upon which to build a nice gui as well as the gui itself. I haven't tried out wxhaskell, but trying gtk2hs and it's cairo bindings, I fell in love with the simplicity. Cheers I like gtk2hs too. I used it to make gui for my several toy projects. My experience was mostly positive, but I had some troubles: First of all, it's just a binding to GTK+, so if you don't have an expirience with it (as in my case), you have to learn both GTK+ and gtk2hs simultaneously. Secondly, I'm absolutely not satisfied with a size of produced binaries. I hope, I just made something wrong, but I got a 3 megabyte behemot after compiling and stripping my 300-line program. I compiled it with ghc-6.4.1 with ghc --make Main.hs. objdump -T shows a myriad of symbols with gtk_ prefix and I have a hard time guessing what most of them are doing where :) I haven't looked at wxhaskell yet. Personally I don't like wxWidgets because of it's overall orientation on GDI API and resemblance with MFC. What is about size of binaries produced using it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI components for displaying Html pages
On Wed, 2005-02-23 at 03:25 +, David Owen wrote: Hi all, I'm looking for a Haskell GUI library which supports the display of rendered Html pages in the same way that web browsers do. I've been getting to grips recently with wxHaskell as it was recommended on haskell-cafe. I was hoping that a special pane component (or something similar) existed in wxHaskell for the purpose. I've looked through the API but can't seem to see anything which looks suitable. Does anybody know if wxHaskell can support this? If not is anybody aware of a Haskell GUI library which caters for this purpose. There is also Gtk2Hs which has a binding to the Mozilla rendering engine embedded in a Gtk+ widget. We have a demo program which shows how to use it (see demo/mozembed in the source distribution). http://gtk2hs.sourceforge.net/ and the API reference: http://gtk2hs.sourceforge.net/docs/gtk2hs-docs-0.9.7/Graphics.UI.Gtk.MozEmbed.html Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI components for displaying Html pages
Hi all, I'm looking for a Haskell GUI library which supports the display of rendered Html pages in the same way that web browsers do. I've been getting to grips recently with wxHaskell as it was recommended on haskell-cafe. I was hoping that a special pane component (or something similar) existed in wxHaskell for the purpose. I've looked through the API but can't seem to see anything which looks suitable. Does anybody know if wxHaskell can support this? If not is anybody aware of a Haskell GUI library which caters for this purpose. Also, I am hoping to make use of HaXmL to deal with the Html parsing or failing that attempt a very simple home-made parser. Should anybody out there know of a better way of attacking this aspect then that would be much appreciated too! (Apologies, this email might have been better suited to the libraries mailing list!) Cheers all! David (Swansea, UK) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI components for displaying Html pages
On Wed, 23 Feb 2005 03:25:47 +, David Owen [EMAIL PROTECTED] wrote: Hi all, I'm looking for a Haskell GUI library which supports the display of rendered Html pages in the same way that web browsers do. I've been getting to grips recently with wxHaskell as it was recommended on haskell-cafe. I was hoping that a special pane component (or something similar) existed in wxHaskell for the purpose. I've looked through the API but can't seem to see anything which looks suitable. Does anybody know if wxHaskell can support this? If not is anybody aware of a Haskell GUI library which caters for this purpose. Is this what you're looking for: http://wxhaskell.sourceforge.net/doc/Graphics.UI.WXCore.WxcClassesAL.html#88 ? -- Friendly, Lemmih ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
On Mon, Dec 27, 2004 at 11:44:49AM +0100, Arjan van IJzendoorn wrote: However, I want to know if there has been any practical standardisation in the GUI area. Last time I looked at this it seemed some decisions had been made (bind to existing api - wxWindows?). I am waiting for some real standardisation and a mature API before I jump ship from Java for my day-to-day programming. wxHaskell is available at http://www.wxhaskell.sfnet.org/ It runs on Windows, Linux and MacOS X. It has many GUI controls, database access, is well documented and ...[snip] --^^^ Well documented is relative to the background of the user. As a Haskell novice who has no prior experience with wxWindows, I have found the documentation a little bit sparse! For example, the device context (dc) of the widget where an event occurs is apparently passed (by the wxHaskell routines) to the user written callback function for that event. I had a need for the dc of a different widget in a certain callback. I stumbled onto the function withClientDC more or less by accident. I'd like to be able to output my drawing in PostScript. Based on some wxWindows examples, and some function signatures in the wxHaskall documentation, I believe I'll eventually be able to do this, but expect to have to do some heavy digging and reading of a certain amount of C++ code in order to figure out how. This is not a complaint, just a warning to the novice. Don't expect anything like Python's TKInter Life Preserver. I am fairly happy with wxHaskell and get happier with it as I get to understand it better. I'm grateful for the work Daan and others have put into wxHaskell. wxHaskell does have extensive Haddock documentation, the Wiki has a very good wxHaskell page (as far as it goes), and Daan's paper wxHaskell A Portable and Concise GUI Library for Haskell is excellent. I understand that writing documentation for the novice is time consuming. I hope to add some comments to the Wiki for other beginers when I get a little further along. Best, John Velman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
However, I want to know if there has been any practical standardisation in the GUI area. Last time I looked at this it seemed some decisions had been made (bind to existing api - wxWindows?). I am waiting for some real standardisation and a mature API before I jump ship from Java for my day-to-day programming. wxHaskell is available at http://www.wxhaskell.sfnet.org/ It runs on Windows, Linux and MacOS X. It has many GUI controls, database access, is well documented and perfectly stable. We use this toolkit for a Bayesian network tool, Dazzle. See http://www.cs.uu.nl/dazzle/images/screenshot.jpg for a screenshot. Have fun, Arjan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
On Mon, Dec 27, 2004 at 11:44:49AM +0100, Arjan van IJzendoorn wrote: wxHaskell is available at http://www.wxhaskell.sfnet.org/ It runs on Windows, Linux and MacOS X. It has many GUI controls, database access, is well documented and perfectly stable. We use this toolkit for a Bayesian network tool, Dazzle. See http://www.cs.uu.nl/dazzle/images/screenshot.jpg for a screenshot. It seems a bit of a stretch to call wxhaskell perfectly stable, when it seems that the API changes with each release... It's definitely a working interface, but I wouldn't really call it a stable one. I guess it is stable in the sense that it doesn't crash. -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
It seems a bit of a stretch to call wxhaskell perfectly stable, when it seems that the API changes with each release... It's definitely a working interface, but I wouldn't really call it a stable one. I guess it is stable in the sense that it doesn't crash. Yes, you are right. I meant the latter meaning of the word 'stable'. The interface has changed considerably at version 0.8 but will hardly (if at all) be changed at 0.9. Maybe Daan himself can shed some more light on the matter. Cheers, Arjan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI
In message [EMAIL PROTECTED] Matthew Roberts [EMAIL PROTECTED] writes: I know this question is probably going over old ground - so I apologise in advance. However, I want to know if there has been any practical standardisation in the GUI area. Last time I looked at this it seemed some decisions had been made (bind to existing api - wxWindows?). I am waiting for some real standardisation and a mature API before I jump ship from Java for my day-to-day programming. There are also bindings to other existing toolkits: Gtk and FLTK. Both of these projects are (I believe) aiming to have a roughly similar medium level API as wxHaskell has chosen. The aim being to make it easier for users to switch toolkits. As has been noted, none of these projects have hit complete API stability, though wxHaskell and gtk2hs are nearing version 1.0 releases. I would certianly advocate aiming for a common medium level API that covers a core subset of each toolkits functionality. Of course there will always be differences between the different toolkits, particularly in their scope. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI
I know this question is probably going over old ground - so I apologise in advance. However, I want to know if there has been any practical standardisation in the GUI area. Last time I looked at this it seemed some decisions had been made (bind to existing api - wxWindows?). I am waiting for some real standardisation and a mature API before I jump ship from Java for my day-to-day programming. Has there been any progress? Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
