Future of Haskell: GUI development
[This is a summary on the GUI discussion at the Haskell workshop/HIM, as announced by Henrik Nilsson] The future development of GUI libraries for Haskell The development of Haskell applications with a graphical user interface has long been complicated by the large number of mostly incomplete libraries. In spring of this year people tried to focus the development effort and came up with the idea of a Common GUI API (CGA for short) which should define an intersection of three major platform APIs (Win32, Gnome/Gtk and Mac OS X) and that addresses the requirements of the platform's style guide (or human interface guidelines). The process of defining this CGA is a major undertaking. The alternative is to use a readily available cross-platform API, like wxWindows, at the expense of creating applications that might violate a platform's style guide and the cannot make use of platform specific functionality. A quick poll at the Haskell workshop revealed that 1/3 of the people thought that the CGA approach is worthwhile, 2/3 thought that the cross-platform approach is adequate. Hence the CGA idea as it stands right now will not be pursued. The discussions at the Haskell Implementor Meeting (HIM) yielded some interesting options (or compromises) that could help to target and unify the development effort of the different library maintainers. In particular we would like to - focus development on wxWindows (in form of wxHaskell) as this cross-platform toolkit should be adequate for most needs - move the programming model of Yahu (Attribute/set/get functionality) into the Haskell library hierarchy so that other (GUI) libraries can use it. - exploit wxWindow's capability to extract platforms specific handles/objects. The goal is to use other libraries (like gtk+hs, gtk2hs, Mocca, etc.) if wxWindows does not provide the needed functionality. - mention the names of the maintainers of each GUI library on the Haskell web site so that programmers can estimate how well-maintained a library is. Update these names regularly. In case people feel inclined to still pursue the CGA idea, one of the following two routes could be taken: - re-expose parts of wxHaskell in a way that forces the user to write applications that look and feel native on different platforms, i.e. a "Common GUI API on top of wxWindows" - write a GUI Builder application for Haskell; it would surely make Haskell itself more attractive as a rapid development language (such a Builder could also cater for the look-and-feel requirements of the different platforms) Please send any comments or critics to gui@haskell.org . All input (and development effort) is welcome. Axel (on behalf of the GUI Task Force).
Alle 12:47, mercoledì 10 settembre 2003, Axel Simon ha scritto:
In case people feel inclined to still pursue the CGA idea, one of the following two routes could be taken: - re-expose parts of wxHaskell in a way that forces the user to write applications that look and feel native on different platforms, i.e. a "Common GUI API on top of wxWindows"
I think that this could be done, to have an haskell GUI library instead of a wxwindows binding, wich would be just an implementation. And this decision makes a fast startup because Daan is already trying this.
- write a GUI Builder application for Haskell; it would surely make Haskell itself more attractive as a rapid development language (such a Builder could also cater for the look-and-feel requirements of the different platforms)
Well, this should be done anyway, but maybe not here. Am I unsubscribed to this list, or people do not want to comment on anymore? The main problem of wxwin was, according to (if I remember well) Wolfgang Thaller, that it does not feel native on OSX; so I guess the opinion of some OSX user or developer would be interesting now. bye Vincenzo
On Sun, Sep 14, 2003 at 01:51:17AM +0200, Nick Name wrote:
Alle 12:47, mercoledì 10 settembre 2003, Axel Simon ha scritto:
In case people feel inclined to still pursue the CGA idea, one of the following two routes could be taken: - re-expose parts of wxHaskell in a way that forces the user to write applications that look and feel native on different platforms, i.e. a "Common GUI API on top of wxWindows"
I think that this could be done, to have an haskell GUI library instead of a wxwindows binding, wich would be just an implementation. And this decision makes a fast startup because Daan is already trying this.
I agree. I am excited by the progress on wxHaskell, but am even more interested in a well designed CGA. Not necesarily featuring every widget on earth, but something that looks like it would be practical to create another backend for. And I think that this is the way I would do it if I had time.
Am I unsubscribed to this list, or people do not want to comment on anymore? The main problem of wxwin was, according to (if I remember well) Wolfgang Thaller, that it does not feel native on OSX; so I guess the opinion of some OSX user or developer would be interesting now.
Well, I've coded with wxwin for mac, and the only problem with it that comes to mind is the menus. It is possible to write an (almost?) native-behaving application using wxwin, although it requires considerable #ifdefing to get it to work. I proposed a solution (codeless, of course) to this a while back, and if I ever got around to doing any GUI work (been too busy) I'd probably try to implement it on top of wxhaskell. By the way, the (almost?) in the above paragraph refers to the preferences menu item. Last I used wxwin (over a year ago) I couldn't figure out how to create that menu item in the application menu where it belongs. On the other hand, wxwin is very actively developed, and the mac port is very young, so I wouldn't be surprised if there now an interface to create the preferences menu item. -- David Roundy http://www.abridgegame.org/darcs
Nick Name wrote:
Am I unsubscribed to this list, or people do not want to comment on anymore? The main problem of wxwin was, according to (if I remember well) Wolfgang Thaller, that it does not feel native on OSX; so I guess the opinion of some OSX user or developer would be interesting now.
It actually looks and feels better than I expected. While it is not perfect, it appears to be moving in the right direction. The biggest problems with the current Mac OS X version of wxWindows seem to stem from it's backward compatibility with Mac OS 8 and 9, rather than it's cross-platform nature. Specifying and implementing a CGA that works better (for basic tasks) than wxWindows will take some time, and I have been convinced that it is not certain that we would succeed. I'm therefore stepping aside and giving wxWindows & wxHaskell a chance. However, if you or someone else on the list would like to continue discussing the subject of a Common GUI API, feel free to do so. While im not interested in spending large amounts of time on this at this point in time, I'll still watch the list in case anybody has questions that fall in my area of expertise (i.e. Mac OS). If there is progress on this CGA (like, for example, a specification that looks like it can be implemented _well_ on all platforms), or if wxWindows fails to meet my expectations in the future, I might also become more interested in this approach again. Cheers, Wolfgang
On Wednesday, 2003-09-10, 12:47, CEST, Axel Simon wrote:
[...]
A quick poll at the Haskell workshop revealed that 1/3 of the people thought that the CGA approach is worthwhile, 2/3 thought that the cross-platform approach is adequate. Hence the CGA idea as it stands right now will not be pursued.
I have to say that I'm very disappointed by this decision. I was very enthused that there was such a strong focus on "nativeness" in the past because, in my opinion, this "nativeness" is very important. I fear that the wxWindows approach won't give us applications that conform to the platform-specific conventions very well. Therefore, I'm interested in developments like HToolkit where there's a strong emphasis on styleguide conformance.
[...]
Please send any comments or critics to gui@haskell.org .
Done. ;-)
All input (and development effort) is welcome.
Axel (on behalf of the GUI Task Force).
Wolfgang
Wolfgang Jeltsch
On Wednesday, 2003-09-10, 12:47, CEST, Axel Simon wrote:
[...]
A quick poll at the Haskell workshop revealed that 1/3 of the people thought that the CGA approach is worthwhile, 2/3 thought that the cross-platform approach is adequate. Hence the CGA idea as it stands right now will not be pursued.
I have to say that I'm very disappointed by this decision. I was very enthused that there was such a strong focus on "nativeness" in the past because, in my opinion, this "nativeness" is very important. I fear that the wxWindows approach won't give us applications that conform to the platform-specific conventions very well. Therefore, I'm interested in developments like HToolkit where there's a strong emphasis on styleguide conformance.
Better a viable GUI binding with some reasonable level of nativeness now than chasing after the ideal binding for two years and be left with nothing. What makes you think that the few people in the Haskell community who are interested in building GUI infrastructure can do a better job at a cross-platform API than the masses of GUI developers for whom this is their daily bread? I think we are better off by piggy-backing on a major cross-platform effort driven by a large developer community than by wasting our time on trying to solve problems that the experts couldn't crack so far. Cheers, Manuel
Alle 17:05, domenica 14 settembre 2003, Manuel M T Chakravarty ha scritto:
What makes you think that the few people in the Haskell community who are interested in building GUI infrastructure can do a better job at a cross-platform API than the masses of GUI developers for whom this is their daily bread?
I agree with you on this point, that we were wrong designing everything from scratch, but instead:
I think we are better off by piggy-backing on a major cross-platform effort driven by a large developer community than by wasting our time on trying to solve problems that the experts couldn't crack so far.
What about just taking wxwin, feature by feature, and give it a more haskell-like view? (note that this has to be done anyway, and that Daan is doing just that alone). This means - supporting wxhaskell in primis - work for some time, wich can be short or long depending on how much free time people have - reuse the design decisions of wxwin in the large, but be able to make minor changes like adjusting the menu layout of macosx - be able to make a quick binding to other libraries like qt or dialog directly in haskell, if there ever is a qt or dialog binding for haskell of course. Vincenzo
What about just taking wxwin, feature by feature, and give it a more haskell-like view? (note that this has to be done anyway, and that Daan is doing just that alone).
Of course. I did consider that to be part of the wxHaskell effort.
- reuse the design decisions of wxwin in the large, but be able to make minor changes like adjusting the menu layout of macosx
Utility modules that utilise Haskell's potential for higher-level abstraction are most definitely welcome! A small helper function that manages correct ordering of the standard buttons in dialog boxes would already make wxWindows applications look and feel a lot better on the Mac.
- be able to make a quick binding to other libraries like qt or dialog directly in haskell, if there ever is a qt or dialog binding for haskell of course.
Of course there can and probably should be bindings to other libraries. But what does that have to do with wxWindows & wxHaskell? Cheers, Wolfgang
Alle 19:39, domenica 14 settembre 2003, Wolfgang Thaller ha scritto:
Of course there can and probably should be bindings to other libraries. But what does that have to do with wxWindows & wxHaskell?
This has to do with the CGA, if there has to be one. I think that a library wich is NOT wxhaskell has to be created, and that it has to use wxhs as a backend for now, and other backends in the future. V.
Hi All,
What about just taking wxwin, feature by feature, and give it a more haskell-like view? (note that this has to be done anyway, and that Daan is doing just that alone). This means
I would like to clarify this point: At the moment, there is a "WXCore" layer that implements the core interfaces to wxWindows together with some convenience functions. The "WX" layer builds a more abstract framework, using attributes and type classes, to make *wxWindows* programming more convenient. So, it is true that the WX library gives a haskell-like view to wxWindows but it doesn't try to be a CGA -- it totally relies on wxWindows on the moment to do the "right thing" on different platforms. However, in the upcoming 0.2 release, I have added the ability to inspect variables like the current platform, so that we can start adding more CGA like abstractions -- for example, getting the automatic button layout proposed by Wolfgang Thaller. I am not sure yet if these functions should be in WX or in some other library (but I like evolutionary approaches so we'll see what happens :-) All the best, Daan.
On Sunday, Sep 14, 2003, at 17:22 Europe/Paris, Nick Name wrote:
Alle 17:05, domenica 14 settembre 2003, Manuel M T Chakravarty ha scritto:
What makes you think that the few people in the Haskell community who are interested in building GUI infrastructure can do a better job at a cross-platform API than the masses of GUI developers for whom this is their daily bread?
I agree with you on this point, that we were wrong designing everything from scratch, but instead:
Although the idea is kinda dead now, I object to Manuel that we wanted to reinvent wxWindows. We never meant to build an API that covers everything from every platform. But even wxWindows doesn't cover everything. So I think it would be useful if we can provide a way to extract native handles, so that you can plug in a QuickTime widget on Apple and a media player COM object on Windows. I guess this is what Vincenzo suggested as well:
- be able to make a quick binding to other libraries like qt or dialog directly in haskell, if there ever is a qt or dialog binding for haskell of course.
I think we are better off by piggy-backing on a major cross-platform effort driven by a large developer community than by wasting our time on trying to solve problems that the experts couldn't crack so far.
What about just taking wxwin, feature by feature, and give it a more haskell-like view? (note that this has to be done anyway, and that Daan is doing just that alone). This means [..] I think it would be very interesting to port Fudgets to wxWindows and see if people are able to use it and find it easier than the IO Monad approach. Actually, what Vincenzo suggested quite some time ago about streams is exactly what Fudgets are about. I don't think there is a use of an abstraction over the whole of wxWindows at the level of the IO Monad. But
- reuse the design decisions of wxwin in the large, but be able to make minor changes like adjusting the menu layout of macosx
, since the MacOS menu bar is important and maybe should be enforced by the API of wxHaskell. Axel.
Nick Name
Alle 17:05, domenica 14 settembre 2003, Manuel M T Chakravarty ha scritto:
I think we are better off by piggy-backing on a major cross-platform effort driven by a large developer community than by wasting our time on trying to solve problems that the experts couldn't crack so far.
What about just taking wxwin, feature by feature, and give it a more haskell-like view? (note that this has to be done anyway, and that Daan is doing just that alone). This means
- supporting wxhaskell in primis
- work for some time, wich can be short or long depending on how much free time people have
- reuse the design decisions of wxwin in the large, but be able to make minor changes like adjusting the menu layout of macosx
- be able to make a quick binding to other libraries like qt or dialog directly in haskell, if there ever is a qt or dialog binding for haskell of course.
Seems like a lot of work with little gain. Keep in mind that wxWindows is a moving target. Just tracking all their improvements is going to be major work. Who is going to do that in the long run? Manuel
Alle 15:44, lunedì 15 settembre 2003, Manuel M T Chakravarty ha scritto:
Seems like a lot of work with little gain. Keep in mind that wxWindows is a moving target. Just tracking all their improvements is going to be major work. Who is going to do that in the long run?
I see that I have to surrender ;) Really, I have looked at wxhs again, and I could personally be convinced that whatever I would like to do is overlapping with the mid-level layer of wxhs, and since the attribute system coming from YAHU is easily extensible, I can always add a module if I want to add functionality. But I don't see how that mid-level layer will differ in amount of work from what I was looking forward to do: won't we have to track wxwindow changes anyway? Vincenzo
Am Sonntag, 14. September 2003, 17:05 schrieb Manuel Chakravarty:
[...]
What makes you think that the few people in the Haskell community who are interested in building GUI infrastructure can do a better job at a cross-platform API than the masses of GUI developers for whom this is their daily bread?
I think we are better off by piggy-backing on a major cross-platform effort driven by a large developer community than by wasting our time on trying to solve problems that the experts couldn't crack so far.
Maybe, the reason for GUI libraries not really providing native look-and-feel is not only that the task is hard but also that many people just don't care that much about look-and-feel. I remember a discussion with someone who wanted me to convince that GTK has native look-and-feel under Windows. In order to proof himself correct, he pointed me to a screenshot which definitely showed the standard GTK L&F and not the Windows one. Maybe he thought: "Oh, there are scrollbars and buttons which are grey and have a 3D look, so it definitely looks like Windows." Well, I cannot really say how difficult it is to implement a GUI library adhering to the different styleguides as I haven't been involved in GUI development very much.
Cheers, Manuel
Wolfgang
participants (7)
-
Axel Simon -
Daan Leijen -
David Roundy -
Manuel M T Chakravarty -
Nick Name -
Wolfgang Jeltsch -
Wolfgang Thaller