Hello, This question is just idle curiosity. I don't actually plan to write a desktop GUI program. With that said, what library would you recommend to someone who wants to write a cross-platform desktop app with Haskell? Consider the following requirements: 1) Cross-platform. Windows, Linux and preferably OS X too. 2) Maintained, stable, mature, documented, etc. 3) Easy to use. Notice that this has much to do with the Haskell bindings. For example, Qt might be a fabulous toolkit, but qtHaskell might be immature (it looks like it started in Dec 2007). wxHaskell looks good. I like the idea behind wxWidgets, but I have never used it (or any GUI toolkit for that matter). Thank you for your input. Cheers, Daniel.
If I were to write one right now (and I might actually need in a few days), I'd use Gtk2Hs. Cons: - Does not fit Haskell's style. - Very imperative, everything in IO. Pros: - Terrific binding: (almost) complete, working, tested. - Multi-platform (as far as Gtk itself is). - If you need, reading Gtk's C docs is straightforward. - Seamless integration with Cairo (yay!). - ... (probably more) I already used Gtk on other languages before Haskell, though, so I'm somewhat biased. -- Felipe.
Hi Felipe, I think I read somewhere that Gtk2Hs is the more active project, so it might be more mature. On the other hand, Gtk kinda sucks on Mac OS X. I hate how Gimp or GnuCash look when I run them on OS X. On Windows Gtk runs fine except that the file browser looks out of place. Daniel. Felipe Lessa wrote:
If I were to write one right now (and I might actually need in a few days), I'd use Gtk2Hs.
Cons: - Does not fit Haskell's style. - Very imperative, everything in IO.
Pros: - Terrific binding: (almost) complete, working, tested. - Multi-platform (as far as Gtk itself is). - If you need, reading Gtk's C docs is straightforward. - Seamless integration with Cairo (yay!). - ... (probably more)
I already used Gtk on other languages before Haskell, though, so I'm somewhat biased.
-- Felipe. _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On Thu, Apr 30, 2009 at 12:40:54AM +0200, Daniel Carrera wrote:
I think I read somewhere that Gtk2Hs is the more active project, so it might be more mature. On the other hand, Gtk kinda sucks on Mac OS X. I hate how Gimp or GnuCash look when I run them on OS X. On Windows Gtk runs fine except that the file browser looks out of place.
Although I don't have access to a Mac, people usually don't like Gtk there. But there seems to be a native port somewhere that is going to be merged into Gtk+ someday :). Now, good support today for Mac OS X would be my only reason to go through the wxWindows route. I use Gtk+ because back in the days that I tried wxWindows, it had a terrible appearence when using Gtk as a backend, but probably things improved since then. -- Felipe.
Felipe Lessa wrote:
Daniel Carrera wrote:
I think I read somewhere that Gtk2Hs is the more active project, so it might be more mature. On the other hand, Gtk kinda sucks on Mac OS X. I hate how Gimp or GnuCash look when I run them on OS X. On Windows Gtk runs fine except that the file browser looks out of place.
Although I don't have access to a Mac, people usually don't like Gtk there. But there seems to be a native port somewhere that is going to be merged into Gtk+ someday :).
I think the "native" refers not to the GUI appearance but to the feature that you don't need an X server to run a Gtk application anymore.
Now, good support today for Mac OS X would be my only reason to go through the wxWindows route. I use Gtk+ because back in the days that I tried wxWindows, it had a terrible appearence when using Gtk as a backend, but probably things improved since then.
WxWindows on Mac OS X doesn't really look great either, I'm afraid. Regards, apfelmus -- http://apfelmus.nfshost.com
Heinrich Apfelmus wrote:
WxWindows on Mac OS X doesn't really look great either, I'm afraid.
Really? The screen shots look good to me. See: http://wxhaskell.sourceforge.net/images/controls-macosx.png Daniel.
On 30 Apr 2009, at 10:44, Daniel Carrera wrote:
Heinrich Apfelmus wrote:
WxWindows on Mac OS X doesn't really look great either, I'm afraid.
Really? The screen shots look good to me. See:
Really, here's what that *should* look like: http://www.cs.kent.ac.uk/people/rpg/tatd2/controls-macosx.png Of note though, the main problem with WX is not that the controls look different, it's that they behave differently. UI is not just about looks ;). Bob
Thomas Davie wrote:
Really, here's what that *should* look like:
http://www.cs.kent.ac.uk/people/rpg/tatd2/controls-macosx.png
Your link is for Panther, my link was for Jaguar. The wxHaskell also has a screenshot on Panther: http://wxhaskell.sourceforge.net/images/controls-macosx2.png
Of note though, the main problem with WX is not that the controls look different, it's that they behave differently. UI is not just about looks ;).
Ok.. how do they behave? I bet you that they behave better than the Gtk controls on OS X... ugh. You are right that UI is not just looks. That's another of the issues with X11 on OS X, it behaves wrong. The command key doesn't do anything, so for example, it's a major pain to use Gimp on OS X without a two button mouse. How about Qt? Do you know if Qt behaves well on OS X? I thought that Qt didn't look native on OS X (I'm on Ubuntu right now, so I can't check). Daniel.
On 30 Apr 2009, at 11:12, Daniel Carrera wrote:
Thomas Davie wrote:
Really, here's what that *should* look like: http://www.cs.kent.ac.uk/people/rpg/tatd2/controls-macosx.png
Your link is for Panther, my link was for Jaguar. The wxHaskell also has a screenshot on Panther:
http://wxhaskell.sourceforge.net/images/controls-macosx2.png
My link was on leopard actually, but that still looks significantly different to the natively designed UI.
Of note though, the main problem with WX is not that the controls look different, it's that they behave differently. UI is not just about looks ;).
Ok.. how do they behave? I bet you that they behave better than the Gtk controls on OS X... ugh.
I very much doubt that actually – mac users in my experience notice when things are annoyingly slightly different from the norm – a kind of uncanny valley effect, it's almost what you expect, but not quite. In the mean time, gtk being entirely non-OS X like running in X11 says "hey, I'm different, deal with it", and people do.
You are right that UI is not just looks. That's another of the issues with X11 on OS X, it behaves wrong. The command key doesn't do anything, so for example, it's a major pain to use Gimp on OS X without a two button mouse.
Well yes, but then all macs come with 2 button mice, so *shrug*. But yes, X11 apps in general behave wrong, and mac users don't like them much, but they like them better than apps that pretend to be OS X like, but don't get it right.
How about Qt? Do you know if Qt behaves well on OS X? I thought that Qt didn't look native on OS X (I'm on Ubuntu right now, so I can't check).
Qt get closer into uncanny valley than gtk does, because it runs natively. This really though comes down to the fact that it's totally impossible to design cross platform UIs for applications. Different platforms UIs behave differently, so deal with it, and write different UIs for the different platforms. Don't expect everyone to fit into your one- size-fits-all straight jacket. This is extra work, but 1) it enforces a good abstraction layer between your UI and your actual application, and 2) it gives major benefits in terms of happy customers. Bob
Thomas Davie wrote:
http://wxhaskell.sourceforge.net/images/controls-macosx2.png
My link was on leopard actually, but that still looks significantly different to the natively designed UI.
Significantly different? They are practically identical.
Ok.. how do they behave? I bet you that they behave better than the Gtk controls on OS X... ugh.
I very much doubt that actually – mac users in my experience notice when things are annoyingly slightly different from the norm – a kind of uncanny valley effect, it's almost what you expect, but not quite. In the mean time, gtk being entirely non-OS X like running in X11 says "hey, I'm different, deal with it", and people do.
I am a Mac user and I disagree. I know several mac users who also disagree. I remember that NeoOffice used to be much more popular than OpenOffice.org on Mac because OOo used X11 and NeoOffice didn't, even though it was clear that NeoOffice was not quite native. You are the first mac user I meet that feels the way you feel. I have met quite a few mac users who don't share your views. X11 apps look like crap. And I disagree with the "uncanny valley" thing because *native* OS X apps can look quite different. There isn't a single uniform look for native OS X apps but at least two. Looking at the screen shots on the wxHaskell website, if I saw that on my Mac, it wouldn't cross my mind that it isn't native.
Well yes, but then all macs come with 2 button mice, so *shrug*.
Mine doesn't and every mac I've seen doesn't, so don't dismiss me like that, it's very rude. Also, in macs the command key is used a lot, you can't just throw it away and "shrug" like you just did. Daniel.
Daniel Carrera wrote:
Thomas Davie wrote:
http://wxhaskell.sourceforge.net/images/controls-macosx2.png
My link was on leopard actually, but that still looks significantly different to the natively designed UI.
Significantly different? They are practically identical.
IMHO, they are quite different, and it shows. :) The first difference is the spacing. In the wxHaskell version, the enclosing tab is glued to the window border left and right, while there is a considerable margin in the native version. The inner boxes have spacious margins, too. The second is the capitalization in the native version. That gives it a totally different look! I even thought that they were using different fonts at first. Thirdly, the textlogs have different fonts. Again, the wxHaskell one looks non-standard. Overall, I think it's quite visible that the wxHaskell version is not native. What I don't understand is why, though; after all, most of the above is specified in Apple's Human Interface Guidelines, it's just a matter of implementing them. Regards, apfelmus -- http://apfelmus.nfshost.com
Heinrich Apfelmus wrote:
The first difference is the spacing. In the wxHaskell version, the enclosing tab is glued to the window border left and right, while there is a considerable margin in the native version. The inner boxes have spacious margins, too.
The second is the capitalization in the native version. That gives it a totally different look! I even thought that they were using different fonts at first.
I didn't notice any of these except for the tab margin until you pointed it out. The tab margin left and right is the only thing I noticed. Taking a second look, I also notice the margin *below* the tab box.
Thirdly, the textlogs have different fonts. Again, the wxHaskell one looks non-standard.
Honestly, I can't tell. They are both very similar, sans fonts. Also, the font could be explained by the fact that these screen shots are taken on different computers (different OS versions, different settings). I just went to the wxWidgets website. On that site, the Mac OS screen shots show the buttons capitalized. In any case, I think these differences are minor. More importantly, I'm not sure that a different cross-platform toolkit would do a better job. Daniel.
I thought wxWidgets was actually one of the only toolkits that actually *used* the native GUI libraries??? See e.g. http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits So I don't understand how come the look and feel is different then... On Fri, May 1, 2009 at 11:26 AM, Daniel Carrera < daniel.carrera@theingots.org> wrote:
Heinrich Apfelmus wrote:
The first difference is the spacing. In the wxHaskell version, the enclosing tab is glued to the window border left and right, while there is a considerable margin in the native version. The inner boxes have spacious margins, too.
The second is the capitalization in the native version. That gives it a totally different look! I even thought that they were using different fonts at first.
I didn't notice any of these except for the tab margin until you pointed it out. The tab margin left and right is the only thing I noticed. Taking a second look, I also notice the margin *below* the tab box.
Thirdly, the textlogs have different fonts. Again, the wxHaskell one
looks non-standard.
Honestly, I can't tell. They are both very similar, sans fonts. Also, the font could be explained by the fact that these screen shots are taken on different computers (different OS versions, different settings).
I just went to the wxWidgets website. On that site, the Mac OS screen shots show the buttons capitalized. In any case, I think these differences are minor. More importantly, I'm not sure that a different cross-platform toolkit would do a better job.
Daniel.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Peter Verswyvelen wrote:
I thought wxWidgets was actually one of the only toolkits that actually *used* the native GUI libraries??? See e.g. http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
So I don't understand how come the look and feel is different then...
Using native GUI libraries is necessary, but not sufficient for achieving the same look and feel. :) Other elements are layout and spacing, http://developer.apple.decenturl.com/human-interface-guidelines-layout http://developer.apple.decenturl.com/hi-guidelines-windows drag & drop, http://developer.apple.decenturl.com/hi-guidelines-dragndrop writing style and fonts http://developer.apple.decenturl.com/human-interface-guidelines-text etc, etc. Daniel Carrera wrote:
Thirdly, the textlogs have different fonts. Again, the wxHaskell one looks non-standard.
Honestly, I can't tell. They are both very similar, sans fonts. Also, the font could be explained by the fact that these screen shots are taken on different computers (different OS versions, different settings).
There is a default set of fonts http://developer.apple.decenturl.com/human-interface-guidelines-text The "mini system font" is the typography of choice for text boxes, but it looks the "application font" is acceptable as well.
In any case, I think these differences are minor.
I don't. :)
More importantly, I'm not sure that a different cross-platform toolkit would do a better job.
True, that. It's just that this doesn't mean that wxWidgets does a very good job. Regards, apfelmus -- http://apfelmus.nfshost.com
This is one of many reasons why I don't believe any of these cross- platform toolkits will ever be good enough to make truly native-like UIs – The bottom line is that tab views are different between Mac OS and other OSes, they have much more padding round them on Mac OS. This means that any layout you create involving them will never work on both platforms. Bob On 1 May 2009, at 17:25, Heinrich Apfelmus wrote:
Peter Verswyvelen wrote:
I thought wxWidgets was actually one of the only toolkits that actually *used* the native GUI libraries??? See e.g. http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
So I don't understand how come the look and feel is different then...
Using native GUI libraries is necessary, but not sufficient for achieving the same look and feel. :)
Other elements are layout and spacing,
http://developer.apple.decenturl.com/human-interface-guidelines- layout http://developer.apple.decenturl.com/hi-guidelines-windows
drag & drop,
http://developer.apple.decenturl.com/hi-guidelines-dragndrop
writing style and fonts
http://developer.apple.decenturl.com/human-interface-guidelines-text
etc, etc.
Daniel Carrera wrote:
Thirdly, the textlogs have different fonts. Again, the wxHaskell one looks non-standard.
Honestly, I can't tell. They are both very similar, sans fonts. Also, the font could be explained by the fact that these screen shots are taken on different computers (different OS versions, different settings).
There is a default set of fonts
http://developer.apple.decenturl.com/human-interface-guidelines-text
The "mini system font" is the typography of choice for text boxes, but it looks the "application font" is acceptable as well.
In any case, I think these differences are minor.
I don't. :)
More importantly, I'm not sure that a different cross-platform toolkit would do a better job.
True, that. It's just that this doesn't mean that wxWidgets does a very good job.
Regards, apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Well, cross-platform toolkits could work if they don't provide widgets as
first class objects :-) So never allow specifying the GUI widgets and layout
directly, only indirectly.
So you basically provide just the model and some hints/constraints and let
the GUI toolkit automatically generate native look&feel widgets to present
and edit the model. This means the GUI toolkit needs to understand and
implement the guidelines on each platform (how many GUI developers actually
follow these guidelines 100%?)
If you provide constraints that are conflicting between GUI platforms, you
have to either relax the constraints or provide different widgets for each
platform.
All nice theoretically, but not done yet?
On Fri, May 1, 2009 at 5:55 PM, Thomas Davie
This is one of many reasons why I don't believe any of these cross-platform toolkits will ever be good enough to make truly native-like UIs – The bottom line is that tab views are different between Mac OS and other OSes, they have much more padding round them on Mac OS. This means that any layout you create involving them will never work on both platforms.
Bob
On 1 May 2009, at 17:25, Heinrich Apfelmus wrote:
Peter Verswyvelen wrote:
I thought wxWidgets was actually one of the only toolkits that actually *used* the native GUI libraries??? See e.g. http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
So I don't understand how come the look and feel is different then...
Using native GUI libraries is necessary, but not sufficient for achieving the same look and feel. :)
Other elements are layout and spacing,
http://developer.apple.decenturl.com/human-interface-guidelines-layout http://developer.apple.decenturl.com/hi-guidelines-windows
drag & drop,
http://developer.apple.decenturl.com/hi-guidelines-dragndrop
writing style and fonts
http://developer.apple.decenturl.com/human-interface-guidelines-text
etc, etc.
Daniel Carrera wrote:
looks non-standard.
Honestly, I can't tell. They are both very similar, sans fonts. Also,
Thirdly, the textlogs have different fonts. Again, the wxHaskell one the font could be explained by the fact that these screen shots are taken on different computers (different OS versions, different settings).
There is a default set of fonts
http://developer.apple.decenturl.com/human-interface-guidelines-text
The "mini system font" is the typography of choice for text boxes, but it looks the "application font" is acceptable as well.
In any case, I think these differences are minor.
I don't. :)
More importantly, I'm not sure that a different cross-platform
toolkit would do a better job.
True, that. It's just that this doesn't mean that wxWidgets does a very good job.
Regards, apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Heinrich Apfelmus wrote:
More importantly, I'm not sure that a different cross-platform toolkit would do a better job.
True, that. It's just that this doesn't mean that wxWidgets does a very good job.
Well, "very good job" is a really fuzzy term. Based on the very limited set of screen shots that I have seen, I think WX does well enough for anyone but a pedant (and you disagree, I know). Anyways, to bring back some context into the discussion. We were talking about whether WX is better than X11+Gtk on Mac. I am confident that it is. Daniel.
Daniel Carrera wrote:
Anyways, to bring back some context into the discussion. We were talking about whether WX is better than X11+Gtk on Mac. I am confident that it is.
I concur. What has put me off of cross-platform GUIs so far is probably not even the appearance, but rather that the programs I've seen don't work correctly: weird behavior, drawing bugs when updating the screen, sluggishness, and crashes. The Gtk+X11 ones (Gimp, Inkscape) usually work better than those who try to use a native toolkit. Hopefully, Haskell easily avoids these kinds of problems. :) Regards, apfelmus -- http://apfelmus.nfshost.com
On 1 May 2009, at 22:20, Daniel Carrera wrote:
Heinrich Apfelmus wrote:
More importantly, I'm not sure that a different cross-platform toolkit would do a better job. True, that. It's just that this doesn't mean that wxWidgets does a very good job.
Well, "very good job" is a really fuzzy term. Based on the very limited set of screen shots that I have seen, I think WX does well enough for anyone but a pedant (and you disagree, I know).
Unfortunately for you, many Mac users are pedants - they expect everything to be exactly in place, perfectly. Bob
Peter Verswyvelen wrote:
I thought wxWidgets was actually one of the only toolkits that actually *used* the native GUI libraries???
It does, and while I'm no expert on the subject, my understanding is that wxWidgets does the best job at matching the native UI. So far it seems that the things wx doesn't get right are small. The most significant difference I've seen so far is capitalization, and I'm not sure that this is an issue with wxWidgets per se, because the other screen shots on the wxWidgets site have the correct capitalization. Daniel.
Felipe Lessa wrote:
Although I don't have access to a Mac, people usually don't like Gtk there. But there seems to be a native port somewhere that is going to be merged into Gtk+ someday :).
Now, good support today for Mac OS X would be my only reason to go through the wxWindows route. I use Gtk+ because back in the days that I tried wxWindows, it had a terrible appearence when using Gtk as a backend, but probably things improved since then.
Thanks. I guess one would have to try making a simple program with each and see. After all, one of the selling points of WX is that it's supposed to look right in all platforms. I have been sort of assuming that between WX and Gtk you might as well pick WX because WX uses Gtk in the platforms where Gtk looks right. The choice would be simpler if Gtk ran natively on Mac. Right now it looks horrible and it is hard to setup if you are not a technical person or don't have the latest OS X. At a *minimum* you'll need to install fink or mac ports and run the program from the terminal. Btw, I have read the first few chapters of the Gtk2Hs tutorial. The code looks extremely imperative. Even more than wxHaskell. I mean... initGUI, "widgetShowAll window", "mainGUI"... In principle I would be happy with any WX, Gtk and Qt. I think well of all of them. It's just that they all seem to have a lot of limitations. Cheers, Daniel.
Daniel Carrera
Felipe Lessa wrote:
Although I don't have access to a Mac, people usually don't like Gtk there. But there seems to be a native port somewhere that is going to be merged into Gtk+ someday :).
Now, good support today for Mac OS X would be my only reason to go through the wxWindows route. I use Gtk+ because back in the days that I tried wxWindows, it had a terrible appearence when using Gtk as a backend, but probably things improved since then.
Thanks. I guess one would have to try making a simple program with each and see. After all, one of the selling points of WX is that it's supposed to look right in all platforms. I have been sort of assuming that between WX and Gtk you might as well pick WX because WX uses Gtk in the platforms where Gtk looks right.
The choice would be simpler if Gtk ran natively on Mac. Right now it looks horrible and it is hard to setup if you are not a technical person or don't have the latest OS X. At a *minimum* you'll need to install fink or mac ports and run the program from the terminal.
Btw, I have read the first few chapters of the Gtk2Hs tutorial. The code looks extremely imperative. Even more than wxHaskell. I mean... initGUI, "widgetShowAll window", "mainGUI"... Yep, very imperative, but it works. At least gtk2hs is easiest way to build Haskell GUI program.
-- Andy
Andy Stewart wrote:
Btw, I have read the first few chapters of the Gtk2Hs tutorial. The code looks extremely imperative. Even more than wxHaskell. I mean... initGUI, "widgetShowAll window", "mainGUI"... Yep, very imperative, but it works. At least gtk2hs is easiest way to build Haskell GUI program.
Thanks. It's hard to argue with "it works". I'd rather have something that works on two platforms than something that fails on three platforms :-) Have you any experience with wxHaskell? Do you find it harder to use? Or is it more buggy? Daniel.
Hi Daniel,
Daniel Carrera
Hello,
This question is just idle curiosity. I don't actually plan to write a desktop GUI program. With that said, what library would you recommend to someone who wants to write a cross-platform desktop app with Haskell?
Consider the following requirements:
1) Cross-platform. Windows, Linux and preferably OS X too. 2) Maintained, stable, mature, documented, etc. 3) Easy to use. I use gtk2hs, it yes to all your need above.
I use gtk2hs-0.10.0 with GHC 6.10 (6.10.1 or 6.10.2) in Ubuntu (or Debian). Below is detail install method: 1) Install GHC 6.10, :) 2) Install depend libraries: sudo aptitude install automake libglade2-dev libgtksourceview-dev libgtksourceview2.0-dev libgconf2-dev librsvg2-dev libgstreamer-plugins-base0.10-dev libgstreamer0.10-dev libgtkglext1-dev libgnomevfs2-dev xulrunner-dev -y 3) Download gtk2hs-0.10.0: http://downloads.sourceforge.net/gtk2hs/gtk2hs-0.10.0.tar.gz 4) Compile gtk2hs-0.10.0: autoconf && ./configure --enable-docs && make && sudo make install And this have tutorial that introduce how to use gtk2hs: http://darcs.haskell.org/gtk2hs/docs/tutorial/Tutorial_Port/ -- Andy
Notice that this has much to do with the Haskell bindings. For example, Qt might be a fabulous toolkit, but qtHaskell might be immature (it looks like it started in Dec 2007).
wxHaskell looks good. I like the idea behind wxWidgets, but I have never used it (or any GUI toolkit for that matter).
Thank you for your input.
Cheers, Daniel.
participants (6)
-
Andy Stewart -
Daniel Carrera -
Felipe Lessa -
Heinrich Apfelmus -
Peter Verswyvelen -
Thomas Davie