- GUI - Haskell.org

Urgent business assistance
by Ola Abiola 22 Aug '03

22 Aug '03

Monsieur/Madam, Tout d�abord, je voudrais solliciter votre ultime confidence pour cette proposition. C�est par la vertu de la nature de la transaction qu�il est n�cessaire d��tre confidentiel et plus discret. J�ai obtenu votre adresse dans l�annuaire de votre pays . Je suis Mr. Ola ABIOLA, le fils du chef BASHORUN MKO ABIOLA qui �tait mort en d�tention politique le 7 juillet 1998. Mon p�re avait contest� l��lection pr�sidentielle au Nigeria du 12 juin 1993 qu�il avait gagn� mais annul�e. Il �tait emp�ch� du fauteuil pr�sidentiel par l�ancienne association du nord dans le pays connue populairement comme<<KADUNA MAFIA>>. Cette assoc iation regroupe les anciens chefs d�Etats militaire et la derni�re junte militaire G�n�ral SANI ABACHA qui est mort le 8 juin 1998. Ils ont jur� de ne pas abdiquer le fauteuil pr�sidentiel � un sudiste, revendiquant que le fauteuil est pour les natifs du nord. Pour se d�barrasser de mon p�re, ils raisonnaient que mon p�re avait d�pens� de l�argent pour gagner le mandat du public, d�o� l�annulation de l��lection . La situation s�est empyr�e la veille du 12 juin, Ier anniversaire(11 juin 1994) lorsque mon p�re s�est d�clar� pr�sident de la R�publique F�d�rale du Nigeria. Pour cette raison, la junte d�clare que mon p�re est recherch�. Il fut arr�t � et il n��tait pas ni jug� ni lib�r� jusqu�� sa mort. En outre, ma m�re ALHADJA KUDIRAT ABIOLA qui luttait pour la lib�ration de mon p�re fut assassin� par des inconnus arm�s le 4 juin 1996. Il faut noter qu�avant la mort de ma m�re, elle avait d�pos�e une somme de 35.300.000 US$(trente cinq million trois c ent mille) de dollars Am�ricains aupr�s d�une compagnie de s�curit� et ceci appartenait � mon p�re. Mon p�re �tait un polygame et depuis sa mort il y a des probl�mes � cause du partage de sa richesse et mes fr�res(de m�re diff�rente) faisaient tout pour s�asseoir sur les biens de mon p�re, d�o� ma d�cision de transf�rer ce fonds � un �tranger qui m�aidera pour son investissement dans une affaire lucrative � mon profit et � celui de mon petit fr�re, comme de m�me p�re et de m�me m�re et qui arrangera au ssi ma r�sidence dans son pays. Notez bien que ma famille n�est pas au courant de cette transaction, c�est uniquement vous et la compagnie de s�curit� et assurez-vous que cette transaction ne sera jamais sue par ma grande famille et les gens du Nigeria. J�ai d�cid� d�ex�cuter cette aff aire ici � Lom�-Togo d�o� ma r�sidence temporaire, pour des raisons de s�curit�s. Soyez inform� que toutes les modalit�s n�cessaire pour le transfert de ce fonds ont �t� parfaites et la transaction est � 100% de hors risque. D�ailleurs, les militaires sont rentr�s dans les casernes et le Nigeria a maintenant un gouvernement d�mocratiq ue. Vous �tes libres de m�informer dans votre r�ponse � cette lettre votre commission en pourcentage sur le montant total pour votre assistance. Notez tout de m�me que les 5% de la somme totale reste pour les d�penses pouvant �tre contract�es pour le pro cessus de la transaction. Contactez- moi et je vous donnerez l�image compl�te de ce projet. Dans l�attente de votre r�ponse rapide, veuillez agr�er l�__expression de mes sentiments les plus sincers. Ola ABIOLA

1 0

Re: [GUI] CGA Proposal
by Axel Simon 22 Aug '03

22 Aug '03

On Thursday, Aug 21, 2003, at 10:35 Europe/Paris, Krasimir Angelov wrote: > >>> newControlApp :: ApplicationName >>> -> ApplicationVersion >>> -> DocumentInterface -- mdi hint >>> -> [Prop ControlApp] >>> -> IO ControlApp >> Ops, no DocumentInterface parameter for ControlApp. >> The point is >> that ControlApp are not centered around documents >> and that there >> is only one main window. > > The current HToolkit implementation still doesn't > support abstraction for documents, but the > DocumentInterface is necessary. Maybe the type should > be renamed to ApplicationInterface. The interface > specifies a way in which the windows are created. For > example the SDI permits only zero or one created > windows while the MDI permits many openned windows. I think this is a misconception. SDI and MDI are just ways to present multiple documents. If you open another document in an SDI application, you get a new window. An example of this is the Internet Explorer where each web document is displayed in a separate window. I consider the SDI/MDI distinction to be about presentation, nothing else. > >> Wow, I haven't thought about making the distinction >> between control and document based application on >> the fly. Maybe that's the way to go. I wonder if it >> is >> more difficult to understand. > > The advantage of this approach is that in that way the > programmer doesn't need to be responsible for the > creation of predefined menus. How is this different from the setup where the programmer specifies the type of application in the beginning? > >> BTW, your "DocumentTemplate" shouldn't contain >> callbacks. Callbacks should be installed by >> calling functions "onBlah :: (data -> IO ret) -> >> GUIElement -> IO >> CallbackId" >> so that they can be detached with the CallbackId if >> needs be. > > I don't understand this. > We discussed on this list that the programmer needs to be able to disconnect callbacks. Thus giving the callback functions as attributes set [onClicked := putStrLn "I'm clicked", onCllicked := putStrLn "Here, too"] doesn't work since there is no way to disconnect just the second callback. The same holds for supplying callbacks in your DocumentTemplate data structure. >>> --- Axel Simon <A.Simon(a)kent.ac.uk> wrote: > >>> Ok. But this leaves open the question for primary >>> window. Why the programmer need to explicitly >> create >>> it? The MacOS applications doesn't have primary >>> window. I think that the primary window should be >>> internal for the library implementation and should >>> exist only under Windows and GNOME. That means >> that >>> the 'newPrimaryWindow' function should be removed. >> >> How is the CGA under Windows and GNOME supposed to >> know which window will take the menu bar in case the >> user uses the ControlApp variant? > > In both ControlApp and DocumentApp the library is > responsible to create the primary window and only it > knows the primary window handle. The menus are always > placed in the primary window. Well, then I guess you have some magic function by which the user can actually access the primary window and fill it with content. It seems that you tend to automate a lot. IMHO the programmer should be in charge of what happens and how it happens. If too much happens by magic, it will be hard to learn how to use the GUI API and where to change things if they don't fit the programmer's idea of presentation. I think the programmer should initiate everything. If (s)he wishes to apply magic and create everything in one step, (s)he should call a function for that. Otherwise (s)he should call functions to create the individual user items bit by bit. >> Not quite. IORefs do not use existential types. >> I think it is possible and cleaner not to model any >> state. At least this will leave the organization of >> the application's state space up to the programmer. >> I don't feel too strongly about this. > > I think that the documents model which I propose is > the most simple way to handle documents. The > programmer is always free to use other state > representations. Hm, maybe, maybe not. I will raise the state issue next week. Cheers, Axel.

1 0

CGA Proposal
by Axel Simon 21 Aug '03

21 Aug '03

Good morning, sorry for the delay, but the internet is kind of unreliable these days. I attach my proposal for the basic framework of the CGA. It seems that the three platforms Windows, Gnome and Mac, can be modelled by choosing between a control application and a document based application. In the former case there is one primary window (no multiplicity) and in the second case there are as many document windows as needed. Beyond that, for both setups there are Toolboxes (map to toolbars on Windows and to little windows on the other platforms) and Utility windows (anything else one might need). I haven't talked about Dialogs yet. I didn't find a style guide for Athena/X. David, could you point something out to me? Critics and comment appreciated, Axel. __________________________________________________________________________ Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter, Adressverifizierung, digitale Unterschrift: http://freemail.web.de

5 12

Re: [GUI] CGA Proposal
by Krasimir Angelov 21 Aug '03

21 Aug '03

--- Axel Simon <A.Simon(a)kent.ac.uk> wrote: > The question is whether people would consider GUIs > written > with MFC as the native user interface. Do C# and > Visual Basic > build on MFC or are they restricted to plain Win32? The Microsoft Office and most of others Microsoft and third party software products are written using MFC. I think that the answer to your first question is True. The .NET and Visual Basic uses its own GUI libraries which are independent of MFC. The trouble here is that MFC is written in C++ and only for C++. This makes difficult to use it from VB or .NET. But yet the .NET and VB are both based on comctl32.dll and provides many extensions like dockable toolbars. The same is true for VCL and CLX in Delphi. > Another example where you are quite deliberate is > when > you specify the About dialog box for which no common > dialog exists on Gnome or Windows. I don't want to > be > too picky about that since the programmer does not > have to use > them, but I am picky if the user has to use them (as > is > the case with toolbars). The About dialog for Gnome is implemented in libgnomeui and it is recomended to use it. > > The > > standard menus in Windows cannot display bitmaps > but > > there exists many MFC extension which provides the > > this feature (Stingray, Dundas and other > toolkits). > > Yes, and there is an extension to support resizable > dialogs. > But that all is a breach, I think. The bitmap menus are not provided from MFC and comctl32.dll but many applications uses bitmap menus. Examples: Microsoft Office, Micosoft Visual Studio, Internet Explorer, Windows Explorer ... Are they violate the platform guidelines? > What do you mean by bitmap menus? I assume those are > menu items with a smaller version of the tool bar > icons to the > left of them, right?! Exactly. Maybe the name is not too expressive. Do you have better name? Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Re: [GUI] CGA Proposal
by Nick Name 18 Aug '03

18 Aug '03

Il 09:21, domenica 17 agosto 2003, hai scritto: > Sure, that would be great! Now is the time. Is there a document like > "Human Interface Guidelines" for KDE? We should check such a document > to make sure that we don't violate KDE's requirement. Yes, I got it, I printed it, but can't find any time here to read it against the recent CGA "specifications". After the 24th, as I said, I am going to help that way. > I omitted the > Athena/Xt back-end for now as well, since I couldn't find any > documentation about user interface guidelines (David?). We surely need > to look at that, too. Maybe it's so different that we will have a "basic CGA" wich works also onto Xt, a "restricted CGA" wich also works on ncurses or similar libraries (I am not joking at all, there are many uses for that), and an "enhanced CGA" wich works only onto higher level interfaces like gnome and kde. When I think about this, I guess that we have to find a comfortable way to choose what toolkit to use at runtime. Bye Vincenzo

1 0

CGA Proposal
by Axel Simon 14 Aug '03

14 Aug '03

__________________________________________________________________________ Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter, Adressverifizierung, digitale Unterschrift: http://freemail.web.de

1 0

ANNOUNCE: Specification for abstract user interface for Windows, GNOME and Aqua
by Krasimir Angelov 12 Aug '03

12 Aug '03

GUI Task Force people I am pleased to announce that on HToolkit web site is placed the first draft of the specification for the future development of HToolkit. The paper is focused on the possibility to develop abstract GUI API which will be able to ensure the native look & feel on both Windows, GNOME and Aqua platforms. The specification is not close and will be extended and/or particularized in the future. I hope that the ideas explained in the paper will also be helpful for the Common GUI API specification. The source of the paper is available in PDF and LaTeX format from the following locations: http://htoolkit.sourceforge.net/doc/specification.pdf http://htoolkit.sourceforge.net/doc/specification.tex All the best, Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 5

Re: HToolkit binary compatibility
by Krasimir Angelov 10 Aug '03

10 Aug '03

Hello Wolfgang --- Wolfgang Jeltsch <wolfgang(a)jeltsch.net> wrote: > at the moment, the different C backends of HToolkit > use different types for, > e.g., windows handles. In my opinion it would be > better if the same type > (e.g. char *) would be used with all backends and > conversions between the > common type (char *) and the native type (e.g., > GtkWidget * or HWND) would be > made internally. The HWND type is defined as (void *) in the windef.h header. Is there any hardware platform where different pointer types have different internal representations? Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 2

RE: [GUI] GUI meeting at ICFP?
by Simon Peyton-Jones 26 Jul '03

26 Jul '03

| on my side). In hintsight this was a very negative | development as it encouraged people to follow their own | convictions and implement their ideas in the hope that their | approach is adopted by the masses. I don't think that the recent work on GUI implementation is a negative development at all. Its great! It gives new information about what works and what doesn't, and it adds to the raw material from which something common can be forged. However, I want to articulate once more what I think we are trying to achieve. * I am Joe Programmer. * I want to write a Haskell program with a GUI. * What do I do? Fact: A GUI interface is big, so it's hard to change my program from one GUI library to another. Therefore: my absolutely top priority is to use a library that I believe will continue to exist, and be supported, at least on the platforms I care about. Next priorities are: - readily available to people who want to modify my source code - available for more than one Haskell implementation Bottom of the list is: - functionality - native look and feel Priority 1 advises strongly against a GUI library supported by one person alone, no matter how talented. As Joe Programmer, I'm very, very keen to use a library that is cherished, developed, and supported by many people. They may each do different tasks, but multi-party buy-in gives me confidence that it's not going to go away when (say) Daan or Krasimir gets hired by a Wall Street finance house. Priority 1 also argues in favour of a Haskell GUI library that is, in turn, built on top of a non-Haskell GUI library which is itself multi-platform, being actively developed, and likely to persist. We don't have enough effort to re-implement this stuff! (As I understand it, this is one of the attractions of the Wx approach.) An internal goal (irrelevant to Joe Programmer) is that the Haskell-GUI-library design should be high-level enough that it can be implemented on top of more than one underlying non-Haskell GUI library. That is a worthy goal, but the discussion I have seen has made me conclude that it is simply too difficult to meet. Let's abandon it! Joe doesn't care. I think it'd be fine to pick *one* library (Wx, Motif, X11, Tk, whatever) and allow that to influence the design of what gets exposed to the Haskell programmer. Apart from anything else, it makes life easier by taking a lot of design decisions (for better or worse) out of our hands. Once an underlying library is chosen, many things get fixed. I'm not against sexy, interesting designs built by one person -- far from it -- but I desperately want One Thing that is multiply supported, even if the One Thing is not very sexy. So I beg the members of the GUI task force to put aside considerations of doing the Best Thing, and concentrate your *joint* efforts on doing One Thing. That entails compromise (e.g. picking one non-Haskell library to build on), but it needn't conflict with parallel individual efforts. What I fear, though, is that the key players become so committed to their particular approach that we never get One Thing. Instead we get Many Things, each supported by one person. And that is just no good for Joe Programmer. (The pre-Haskell situation was many languages each supported by one group, and that was no good either; hence Haskell.) This is a big issue: it's really holding up Haskell. Simon

6 10

ENQUIRY
by MR. DAVID LARSON 25 Jul '03

25 Jul '03

FROM: MR. DAVID LARSON ANTHONY EZE & CO. SIR, SUBJECT: TRUST NEED YOUR KIND RESPONSE TO THE FOLLOWING REQUEST: I HAVE A MANDATE TO SOURCE FOR A FINANCIAL MANAGEMENT PERSONNEL ASIDE AFRICA, BE IT YOUR PROFFESSION OR NOT, ITS NATURE DOES NOT COUNT, BUT ONLY HONESTY IS NEEDED AT ITS PEAK AND WANTED AS MOST PRIORTY TO ACTUALIZE THIS EXPECTED GOAL. HAS CLOSE LINK WITH THE PERSONNELS IN THE CORRIDORS OF POWER IN MY COUNTRY HAS BEEN DELEGATED TO SOURCE FOR A COMPETENT ASSOCIATE OUTSIDE AFRICA IF YOU ARE WORTHY OF BEEN TRUSTED WITH HUGE CAPITAL FOR ESTABLISHMENT IN YOUR COUNTRY CONTACT ME FOR FULL PERSONAL SECRETIVE INFORMATION OR DETIALS FOR COMMENCEMENT AND TERMS OF REWARD FOR YOUR EXPERTED INTEREST AND CONTRIBUTION. THE VOLUME OF CAPITAL WILL BE DISCLOSED TO YOU ON MY RECEIPT OF YOUR RETURN CORRESPONDENCE INDICATING YOUR WILLINGNESS TO PER-TAKE. KINDLY RESPOND TO THIS MAIL INCLUDING YOUR PERSONAL CONTACT DATA'S FOR FULL DISCLOSURE OF PROCEEDURES. JUST WAITING FOR YOUR REVERT THANKS MR. DAVID LARSON

1 0