September 2003 - GUI - Haskell.org

Re: Gtk and Object I/O
by Axel Simon 23 Jan '06

23 Jan '06

Good day, and apologies for this very long message. On Mon, Jan 20, 2003 at 09:38:41AM -0000, Simon Peyton-Jones wrote: > I don't think we are waiting for critical user mass. We're waiting for > critical *designer/developer* mass! Yes, I guess that's what I wanted to say. So it is all about acceptance of a toolkit by the programmer. I think a GUI toolkit is more acceptable to a programmer if it fulfills the following (highest priority first): a) it is portable, i.e. programs written to use the GUI library should behave the same on Win32/X/Aqua (MacOS) b) it is functional, i.e. the programmer finds all GUI elements a modern application needs and has the ability to create custom widgets c) it is stable, i.e. the library's API doesn't change too quickly, ideally not at all d) it looks as if written with the native API of the platform I thought b) came before a), but due Simon's comment I swapped them: > Speaking as a potential user of such a library, I would absolutely love > to have a Haskell GUI library that > was available in some form on each major platform > was supported by a bunch of people, so I could have > some confidence in its continued existence > Its exact capabilities are less important: (a) I'd adapt my program to > fit what was available, and (b) I'm sure it would evolve in response to > user feedback. I'd accept compromises in functionality to gain > portability; it'd be OK to have > some platform-specific sexy bits. Worse is better. Let's assume we have a lot of time and nobody is in need of a GUI library right now. For a portable library, we need some layer which is common to all OSes. The question is thus: Where shall we have the common interface between a fixed Haskell API and the specific OS API if we want to minimize the penalty for b) functionality, c) stability and d) look-and-feel. Two main proposals are: 1) Create a common high level layer on top of all native OSes (in C) and then bind to Haskell. Example: HToolkit+Ports 2) Use the native OS functions just for drawing. Create every UI item from scratch. Example: Gtk and gtk+hs/gtk2hs regarding 1): This proposal is geared towards d), look-and-feel. It is nice to have a program which looks as if written with the native API. I think it's impossible, some flame: Dialogs in Windows are specified in dialog units, i.e. they scale with the font size but cannot be resized by the user: scrap Gtk's dynamic sizing capability. Buttons on Aqua cannot have icons in them, scrap icons in Gtk and Windows button. Scrap Aquas hierarchical view in several columns (could be simulated if Windows supports adding columns on the fly, Gtk would), scrap additional columns next to a hierarchical tree since Windows doesn't support that. Scrap Window's concept of groups in dialog and keyboard accelerators in general since Aqua doesn't know about hotkeys. AFAIK a lot of UI elements on Windows which are considered "standard" are implemented in the Microsoft Foundation Classes. Thus to actually use these, one has to use the MFC written in C++ (or .net). I know that these are all minor issues which could be circumvented, but where does the native look-and-feel go? Furthermore, this "finding the common subset" approach will certainly lead to a reduction in b) functionality. Simon PJ said: > (a) I'd adapt my program to fit what was available I wouldn't even start a *bigger* project if I would know that I hit some limits later in the development, but that's my view. > (b) I'm sure it would evolve in response to user feedback This could mean a reduction in c) stability. A major point is that you need to consider *all* platforms before you create any abstraction layer. Otherwise you will have a serious problem with stability. It would be very advisable to use a library of people who have successfully found a common subset of all OSes instead of reinventing the wheel. If we need to do it from scratch, then that could indicate that nobody has ever managed to find this common subset. Well, Sengan said: > I have seen many positive comments about IBM's SWT which > works on the following platforms: > <...everything you ever wished for...> So maybe this is such a library. Is it complete? How is the look-and-feel? -------------------------------------------------------------------------- regarding 2): Using a layer which only builds on the native drawing capabilities is surely easier to port. The b) functionality is quite good in the case of Gtk. It lacks support for sound, but supplies most UI elements known from e.g. Windows. The c) stability is not so much of a concern as the primitive drawing functions will not change that quickly. I would like to apply the "Worse is Better" principle to d) look-and-feel. In the example of Gtk, the inventors have gone through quite some hassle to make the UI changeable. You can tweak the buttons to have the same color and fonts as on Windows, though you cannot change the fact that dialogs are resizable or that buttons have no icons and flash blue if they are the default buttons (Aqua). Gtk is not ported to Aqua but runs under the XonX port of Windows. Last but not least any GUI library has to be maintained. Win32/MFC, Gtk (or Qt) and Aqua will all evolve over time. Using a single library like Gtk reduces the burden of keeping the Haskell library up to date to a single backend. Gtk has many more users as it has bindings to many other languages besides C. Thus the amount of people who can iron out problems with the ports to other platforms is much bigger. ------------------------------------------------------------------------ I did not discuss the issue of how much time it needs to implement the different concepts, that could be another email. Hope these arguments are not too biased, Axel.

9 21

DONATION FOR THE LORD.
by Mrs Serena Jones 30 Sep '03

30 Sep '03

From: Mrs Serena Jones PLEASE ENDEAVOUR TO USED IT FOR THE CHILDREN OF GOD. I am the above named person from Kuwait. I am married to Dr.Harry Jones who worked with Kuwait embassy in Ivory Coast for nine yearsbefore he died in the year 2000.We were married for eleven years without a child. He died after a brief illness that lasted for only four days. Before his death we were both born again Christians.Since his death I decided not to re-marry or get a child outside my matrimonial home which the Bible is against.When my late husband was alive he deposited the sum of$8.6Million (Eight Millionsix hundred thousand U.S. Dollars) with one finance/security company in Amsterderm Holland. Presently, this money is still with the Security Company. Recently, my Doctor told me that I would not last for the next three months due to cancer problem. Though what disturbs me most is my stroke sickness. Having known my condition I decided to donate this fund to church or better still a christian individual that will utilize this money the way I am going to instruct here in. I want a church that will use this fund to fund churches, orphanages and widows propagating the word of God and to ensure that the house of God is maintained. The Bible made us to understand that Blessed is the hand that giveth. I took this decision because I don't have any child that will inherit this money and my husband relatives are not Christians and I don't want my husband's hard earned money to be misused by unbelievers. I don'twant a situation where this money will be used in an ungodly manner. Hence the reason for taking this bold decision. I am not afraid of death hence I know where I am going. I know that I am going to be in the bosom of the Lord. Exodus 14 VS 14 says that the lord will fight my case and I shall hold my peace. I don't need any telephone communication in this regard because of my health because of the presence of my husband's relatives around me always. I don't want them to know about this development. With God all things are possible. As soon as I receiveyour reply I shall give you the contact of the Finance/Security Company in Amsterderm Holland. I will also issue you a letter of authority that will prove you as the original- beneficiary of this fund. I want you and the church to always pray for me because the lord is my shephard. My happiness is that I lived a life of a worthy Christian. Whoever that wants to serve the Lord must serve him in spirit and truth. Please always be prayerful all through your life. Any delay in your reply will give me room in sourcing for a chuch or christian individual for this same purpose. Please assure me that you will act accordingly as I stated herein. Hoping to hearing from you. N.B-PLEASE I WILL ADVICE YOU TO GIVE THE LAWYER IN CHARGE A CALL IN HOLLAND IMMEDIATELY, HE DOES EVERYTHING ON MY BEHALF AND HE'S VERY UNDERSTANDING AND I BELIEVE HE WILL LEAD YOU TO YOUR SUCCESS IN JESUS NAME: James Vincent Email: jamesvin01(a)rediffmail.com Remain blessed in the name of the Lord. Yours in Christ, Mrs Serena Jones

1 0

Announce: wxHaskell 0.2
by Daan Leijen 25 Sep '03

25 Sep '03

Announcement: wxHaskell version 0.2 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> The new release has (improved) support for tree controls, list controls, toolbars, splitter windows, sliders, gauges, and bitmap buttons. Screenshots of these widgets on different platforms have been added to the website. Furthermore, there are numerous small bug fixes, especially for wxGTK. A list of non-compatible changes is attached at the end of this mail. ---------------------------------------------------------------------- wxHaskell is a portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWindows -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- 2766 methods in 505 classes with 1279 constant definitions. wxHaskell has been build with GHC 6.0/6.01 on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows and MacOS X. And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at <http://wxhaskell.sourceforge.net>. All the best, Daan Leijen. ps. More funny statistics: the wxWindows libraries have been downloaded over a million times at sourceforge! The Python binding to wxWindows (wxPython) about 600.000 times, and the Haskell binding to wxWindows about 100 times :-) ---------------------------------------------------------------------- Breaking changes to version 0.1: - Renamed the "WXH" layer to "WXCore". > import Graphics.UI.WXCore instead of > import Graphics.UI.WXH - Changed the interface of menu items a bit. The label and help text is now supplied via attributes: > medit <- menuPane [text := "&Edit"] > mfont <- menuItem medit [text := "&Font...\tCtrl+F" > ,help := "Set the font"]

6 14

inheritance using type classes
by Daan Leijen 17 Sep '03

17 Sep '03

Hi all, (Sorry for the long mail and pollution of the mailing list, but I would like to say a bit more about the trade-offs when modelling inheritance using type classes versus phantom types.) Alle 22:18, martedì 16 settembre 2003, Daan Leijen ha scritto: > This is a devious thing to do, but totally unavoidable given the way > I model inheritance with phantom types. I have considered using > type classes to model the inheritance but that leads to a) other > dependencies on extensions, b) hard to understand error messages, > and c) a much more complex model. (See Andre Pang's master thesis > for a ingenious way to model full inheritance) Inheritance can be modelled fully with type classes but leads to a complicated system that depends on many extensions to work in practice (like MPTC and functional dependencies). That is why I used phantom types to model inheritance in wxHaskell -- simplicity! However, I just realized that with the proper restrictions, there also exists a reasonably simple inheritance model using just haskell98 type classes. (There is a catch of course, but more on that later). Most complications normally arise as we also want to model object methods that are overloaded on their type signatures (like java and c++ allow). For wxHaskell though, we don't need to do this, as no such overloading occurs. This allows us to "lift" the object methods out of a haskell class declaration and to model only the inheritance relationship with type classes. Here is how it works concretely: In the Haskell world, each object is in the end represented by a pointer, say "Addr". So, we can make a class that returns this pointer for each haskell object. > class Object object where > self :: object -> Addr Now, suppose we have a "Window" class with a creation method and show method. First, we create a type that represents this class in Haskell, and we'll call "WindowObject". > newtype WindowObject = WindowObject Addr > > windowCreate :: IO WindowObject > windowCreate = do{ addr <- primWindowCreate; return (WindowObject addr) } Next, we model the inheritance using a (phantom) type class and instance. > class Object window => Window window > > instance Object WindowObject where > self (WindowObject addr) = addr > > instance Window WindowObject The "show" method is written as: > windowShow :: Window window => window -> IO () > windowShow window > = primWindowShow (self window) Note that the inferred type is "Object w => w -> IO ()", but we want to constrain it by hand to windows only. Furthermore, we don't use a "WindowObject" as the argument, as we want to be able to pass *any* kind of Window to this function. For example, a Button object derives from a Control, that in turn derives from the Window class: > newtype ButtonObject = ButtonObject Addr > > class Control button => Button button > > instance Object ButtonObject where > self (ButtonObject addr) = addr > > instance Window ButtonObject > instance Control ButtonObject > instance Button ButtonObject > > buttonCreate :: IO ButtonObject > ... > buttonSetLabel :: Button button => button -> String -> IO () > ... Clearly, we can now use the "windowShow" method on "ButtonObjects" too -- exactly what we want. Furthermore, we can also downcast objects: > downcastWindow :: Window window => window -> WindowObject > downcastWindow window = WindowObject (self window) Up till now, there is not much advantage with regard to using phantom types: the effect is the same and the types with overloading are bit more complicated. However, there may be some other advantages. Suppose I want to create more abstraction and use a type class "Textual" that retrieves some text from an object. > class Textual w where > text :: w -> IO String We use a type class here since we want to use "text" on both the objects imported from the library, but also on user defined data types. Suppose that every window has "windowGetLabel" method. This means that we define "Textual" for any kind of window in one go: > instance Window w => Textual w where > text = windowGetLabel I use the same trick when using phantom types (the free "a" type variable encodes the "any kind of window"): > instance Textual (Window a) where > text = windowGetLabel The attentative reader now notices that both instance declarations are illegal in haskell98 and require the "allow undecidable instances" flag (i.e. the context reducer could loop). Furthermore, the latter also uses a type synonym but that is easy to circumvent (Window a == Ptr (CWxObject (CEvtHandler (CWindow a))) However, there is an important difference -- If we really want, we could replace the first instance declaration with a specific instance declaration for each kind of object: > instance Textual WindowObject > instance Textual ControlObject > instance Textual ButtonObject > .... This would be haskell98 compliant. Unfortunately, no such thing can be done with phantom types (as the instance heads remain "complex", even though they are always "decidable" (i.e. reduce without looping)). Given the more complex type signatures and error messages, I personally find the price too high. Especially since in the wxhaskell case the amount of instance declarations would rise from a single declaration to hundreds of instance declarations for each kind of widget. But maybe this gives at least some more insight in the different trade-offs that we can make. All the best, Daaan.

1 0

Type safe readonly and writeonly attributes with phantom types
by Nick Name 16 Sep '03

16 Sep '03

Yes, I ask dumb questions on haskell-cafe for a reason ;) As the subject already states, I think that it's worth to be considered to use phantom types and type classes to encode the access mode of an attribute. A first approach is the following: ---- Begin 1 ---- class ReadMode mode class WriteMode mode class Mode a data Readable = Readable data Writeable = Writeable data ReadWrite = ReadWrite instance ReadMode Readable instance WriteMode Writeable instance ReadMode ReadWrite instance WriteMode ReadWrite instance ReadMode a => ReadMode (a,b) instance WriteMode b => WriteMode (a,b) data Attr m w a = Attr (w -> IO a) (w -> a -> IO ()) newAttr :: (w -> IO a) -> (w -> a -> IO ()) -> Attr ReadWrite w a readAttr :: (w -> IO a) -> Attr Readable w a writeAttr :: (w -> a -> IO ()) -> Attr Writeable w a get :: ReadMode m => w -> Attr m w a -> IO a ---- End 1 ---- However this has a problem: the combinatorial explosion of data declarations to represent modes, if one has more than two "switches" (as I will have in the next days ;-) The second one, wich I particularly like, is: ---- Begin 2 ---- class ReadMode mode class WriteMode mode class Mode a data Readable = Readable data Writeable = Writeable instance Mode Readable instance Mode Writeable instance ReadMode Readable instance WriteMode Writeable instance (Mode a,Mode b,ReadMode a) => ReadMode (a,b) instance (Mode a,Mode b,WriteMode b) => WriteMode (a,b) data Attr m w a = Attr (w -> IO a) (w -> a -> IO ()) newAttr :: (w -> IO a) -> (w -> a -> IO ()) -> Attr (Readable,Writeable) w a readAttr :: (w -> IO a) -> Attr Readable w a writeAttr :: (w -> a -> IO ()) -> Attr Writeable w a data Prop ... (=:) :: WriteMode m => Attr m w a -> a -> Prop w get :: ReadMode m => w -> Attr m w a -> IO a set :: w -> [Prop w] -> IO () ---- End 2 ---- Note that this is everything haskell98, and can be used (yes, I still haven't tried to recompile htoolkit, but going to try now) like Attr.hs is used right now. This also can solve the already mentioned problem wich is: "I want to breakdown my types in a class hierarchy, so I want to define thing that, say, have a position. So I want to put the type "Menu" in that class, and also the type "Window". But a window can be repositioned, while a menu can't. So I have to make two classes, if I have separated "ReadOnlyAttr" and "ReadWriteAttr" at the type level." To solve this problem, unfortunately, I need multi-parameter type classes, wich could be considered almost legal, but also functional dependencies if I want to avoid type declarations everywhere (and even in places where they aren't haskell98 anyway): ---- Begin 3 ---- class HasMyAttr w m | w -> m where myAttr :: Attr m w () data TestRW = TestRW data TestR = TestR instance HasMyAttr TestRW (Readable,Writeable) where myAttr = newAttr undefined undefined instance HasMyAttr TestR Readable where myAttr = readAttr undefined t1 = set1 TestRW (myAttr =: ()) t2 = get TestRW myAttr t3 = set1 TestR (myAttr =: ()) -- this row can't be compiled t4 = get TestR myAttr ---- End 3 ---- But note how self documenting this code is: the two instance declarations say exactly that "myAttr" is readable and writeable in type TestRW, and read-only in testR. Besides, note that the mode system is extensible: no one constrains an attribute to have a mode wich is one of the types here mentioned, an user has just to conscientiously put its own modes into the right typeclasses. However, if we wish not to allow extention, we still can in some way. Besides, I think that this mode system could be used even if one does not want h98 extentions: it does not limit in any way (AFAIK) the standard (type-correct) usage wrt the present implementation and adds stronger type-checking. I attach the complete modified Attr.hs for reference and wait hopefully for some comment. Vincenzo

1 1

Future of Haskell: GUI development
by Axel Simon 15 Sep '03

15 Sep '03

[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(a)haskell.org . All input (and development effort) is welcome. Axel (on behalf of the GUI Task Force).

7 13

RE: [GUI] Future of Haskell: GUI development
by Simon Peyton-Jones 15 Sep '03

15 Sep '03

I'm glad to see the recent flurry on the GUI mailing list. I think what is now going on is this: We're trying to build a critical-mass of effort and commitment behind one GUI binding NOT to exclude other approaches (because diversity is good) but rather to have enough smart people co-operating that there is some chance that programs written against this API/binding have some chance of working on a variety of platforms (a particularly tricky issue with GUIs) and a variety of Haskell implementations and stay working over a period of time GUIs have very wide interfaces, so doing anything viable is a lot of work. Doing it for lots of platforms is even more work. A big advantage of the Wx approach is that it lets us piggy-back on a much larger effort that has very similar multi-platform goals. Wx isn't perfect -- the Mac menu bar thing seems a case in point -- but at least the Wx crew have exactly the same problem, so there is reason to suppose that the situation may improve. And it does seem to be good enough; by which I mean that it would be hard to improve on, given our effort budget. It's definitely the case that we don't want to program in Wx directly. As Daan mentions, he already has a draft Haskell-ised version of the API, whose design has been discussed quite a bit on this list, and which shares a lot in common with Krasimir's approach. I have the impression that the broad design of the Haskell-ised layer are acceptable to pretty much everyone. But I'm sure Daan wouldn't regard them as cast in stone. As a consumer of this work, my earnest hope is that several smart and productive people will be prepared to work together on the design, implementation, and multi-platform porting of a Hakellised WX interface; and on doing a forest of related projects (port Fudgets, make GUI builder...). Although Daan has done great work getting this Wx stuff started, it's too big a job for one person even if he did nothing else (and Daan is far from being in that position). And again as a consumer, I feel much more confident in using something that has a wide support base rather than something that depends critically on one person. There are many very talented people contributing to this discussion (in no particular order, Nick Name, Wolfgang Thaller, Axel Simon, Krasimir Angelov, David Roundy, Wolfgang Jeltsch, Manuel Chakravarty, Daan Leijen, David Sankel, Anthony Courtney, George Russel, Peter Aachten, Adrian Hey, John Meacham, to name only recent contributors). Let's hope that from this mix, enough of a critical mass will emerge to make this really work. Simon

2 1

Statically-typed read-only attributes
by Nick Name 14 Sep '03

14 Sep '03

I have tried to create read-only attributes in htoolkit. It's easy, as any of you will already know: ------------------------------------------ class GetterAttr attr where getterAttr :: attr a b -> a -> IO b instance GetterAttr Attr where getterAttr (Attr getter setter) = getter data RAttr w a = RAttr (w -> IO a) instance GetterAttr RAttr where getterAttr (RAttr getter) = getter -- | Get an attribute get :: (GetterAttr attr) => w -> attr w a -> IO a get w a = getterAttr a w -- | Define a read-only attribute. Takes the name of the attribute as its first argument. readAttr :: (w -> IO a) -> RAttr w a readAttr getter = RAttr getter --- The rest is in Attr.hs------------------------------------- I have managed to compile htk with this modification, however it turns out that there are classes in htk like -- | Widgets that has specified integer position. class Positioned w where -- | The widget position pos :: Attr w Int Now, a programmer finding an instance of this class will think that he can move the object by setting the attribute. But menus are the only instance of this class, wich I changed to pos::Rattr w Int, because menus can't be moved. This raises the problem: what if I have also "instance Positioned Window"? Well, this problem has many solutions, the simplest of wich is *not* to have statically read-only attributes. I would rather try other solutions, however they might complicate the class and type hierarchy. What do you all think about this? Vincenzo

3 2

Re: RE: [GUI] wxGlade
by list＠taesch.com 14 Sep '03

14 Sep '03

> Hi Luc > > > when experimenting with wxHaskell, I was considering some > > basic gui builders, like glade, http://glade.gnome.org/, or > > even the youger http://wxglade.sourceforge.net, that I just > > discovered. > > wxGlade looks quite promising ! (it's almost visual basic :-) > > > these generate either code via xml ressources files, that the > > code generators read and produce code in the language you > > fancy ( in c++, eiffel, perl, python..). > > > > I was considering giving a try for the wxHaskell binding, and > > was interested in hearing some feedback on that idea ... > > As the XML that you will load dynamically is 'untyped', you need > to somehow emit a typed haskell file together with the XML to load > this data safely into Haskell. That would mean that you either need > to extend wxGlade or that you write a typed interpreter for the XML > data in Haskell itself. > well, I expresed myself badly. I did not thought first about dynamically loading an XML file. rather using the xml file that glade produce to store the interface description, and produce the code out of it, statically. that was the approach we follwoed in the eiffel community. glade produce a xml file, then eglade is called, that reads it and produce the "gui" part of your application. all you have to do is insert the function call from widget actions.. > -- Daan. > > btw. I am personally not a big believer of gui interface builders, > especially not with the "layout" combinators that you can make in > Haskell -- I think that writing the layout with combinators is > faster for an expert than building it in a GUI. Well, combinators are great. and if you can automate their generation in a visual manner, that's even more intuitve. for beginners, to start with. for gui learner, to learn the library combinators.. for professional, to accelerate the gui building... from a methaphore viewpoint, the glade thingy just help you build visually your composite widget tree, serialized in XML, then HAglade would read it and produce the code, a syntax tree that match the widget tree in fact. ie XML -> (Abstract syntax) tree -> code. a matter of strategy, in fact... ;-) Luc

1 0

Re: [GUI] Future of Haskell: GUI development
by list＠taesch.com 14 Sep '03

14 Sep '03

I find that very interesting ... doing the thing right or doing the right thing... old debate... IM(NS)HO, the second bigger risk is to get sidetracked, the first being that to have nothing... And if you consider that the Haskell Communitity is full of researcher, that risk cannot be discarded lightheartedly.. if you can achieve that the (few available) people / ressource can deliver a decent GUI, in 6-9-12 month time, that would probably a major achievement for the Haskell community, ... Haskell would then have a much bigger potential audience... which would in turn provide more ressource, which can then focus on nativeness... if that's still an issue... (Btw, Java, for instance, achieve "nativeness" on none of the platforms...) In other words, if you can provide me a treecontrol, a grid and D&D, even partially native, I would feel much cooler than just a "native" hollow hello world ... well, if on top you can get rid of a dependency on a external lib, that's perfect, but that's more of an "infrastructure" thingy ... especially if that lib is OSS... Luc (Just a basic green belt user..) > Wolfgang Jeltsch <wolfgang(a)jeltsch.net> wrote, > > > 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 > _______________________________________________ > GUI mailing list > GUI(a)haskell.org > http://www.haskell.org/mailman/listinfo/gui

1 0