August 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

KDE application model
by Nick Name 29 Aug '03

29 Aug '03

I'm always in a hurry (as often young people do ;)). Here are relevant quotes (relevant against latest specs) from the kde HIG. ------------------------ Application model in KDE ------------------------ The kde2 HIG, wich should be also valid for kde3, is located at http://developer.kde.org/documentation/standards/kde/style/basics/index.html * The title of new windows wich are still not associated to a document is unspecified in the HIG. * The title of document windows is "document name - application name". Showing or not the file extension and the document path is unspecified. * The title of the control window of "controlled SDI" (see later) application should be "- Control". It is unclear (but I guess it is so) if the title should be "Control - application name". * There are three models for document-centric applications in kde: pure SDI, cooperative SDI and controlled SDI. In the first model, the application might also create new windows (with an entry in the file menu), but each windows should behave as a separate application. The second model extends pure SDI with an exception: all the windows share common attributes (the configuration of the application) and changing an attribute from a windows should act on all the open windows. In pure SDI this is forbidden. The third model is for applications like image viewers, where the number of open windows could be higher than the number of available windows. In that case there can be a main windows wich controls all the other. I guess this is mainly to justify office suites control windows or a gimp-like design. A consideration about SDI/MDI: even if the kde HIG explicitly deprecate the use of any kind of MDI model, in fact there are application wich are just more comfortable with that model (think about tabbed browsing in a web browser), so it should not be denied to create tabbed or paned windows in kde. OTOH, it should be possible to adopt what kde calls "cooperative SDI"(see later) in gnome, even if the default for multiple documents is a tabbed view. This is the case when you write e.g. a web browser in gnome: you can open a document in another window, and both windows should behave as if they were separate applications, but they should share the configuration in any moment. Besides, the KDE SDI model should behave as if any window had a separate unix process, even if all windows might have been internally created by the same process. In that case, I think that there should be no "Quit the whole application" button. This is the case in konqueror. Should it also be the case in an eventual "cooperative SDI" for gnome? I think so. ------------------------------------- Pure SDI in KDE / quotes from the HIG ------------------------------------- "If a Pure SDI application is iconified, its document window and any other windows it has opened, such as help windows, dialogs, toolbars and so on, should be iconified with it. The window manager should present just one icon, which should bring back all the windows when activated." Note that this does NOT mean that iconifying a document window should iconify ALL document windows, because any document window should behave LIKE A SEPARATE APPLICATION. "A drag and drop operation into a document window should perform an Open on the dragged document in that window." This means that kde's idea of SDI is completely different from that of Aqua. IMPORTANT: Does this mean that kde really uses only a form of MDI in wich each document is on a separate window? Is this definition enough to forget about "controlled SDI" and "cooperative SDI" in CGA and just implement all kde's application with the MDI model, demanding to the programmer the task of deciding if it is "cooperative" or "pure"? "Whenever a Pure SDI application is started, it should, if possible, check for an already running copy of itself. If such a copy is found, it should be that copy which performs a New action, thus making a new application appear. This guideline is so that large programs, such a Wordprocessors, don't simply run in multiple copies of themselves and hog all the user's memory." "There should be one instance of an extra window, such as a toolbar, per window, as required by the user. Two application windows must not be allowed to share one toolbar, even if this is technically possible because of the way the application has been implemented." "under the SDI mode, applications are separate; and changing something in one of them may not in any way affect what happens in another". This is the main distinction between cooperative and pure SDI. --------------- Cooperative SDI --------------- "Each window still contains exactly one document, and each document still represents one instance of the application. There is still a menu on each window, and the menu items work as described for the Pure SDI model. However, each application window is aware of the other windows that are running the same application, and this awareness may be utilised by the application. An application may have another menu on its menubar, labelled 'Windows'. If present, this should be the rightmost entry (except for Help). The menu will contain a list of the other documents currently open in other windows; selecting one from the list will raise the appropriate window. The Windows menu may also contain a Close all option. This option should be located at the bottom and be separated from the items above it. It should close all the listed documents and their windows." -------------- Controlled SDI -------------- "suppose an application is launched with a command like "Kapp *.jpg", and there are 2000 JPEG files in the working directory. Under Pure SDI or Co-operating SDI, where one document has one window, 2000 windows would open. This would be a bad thing. The solution to this problem is to have some sort of controlling window, often containing a list of the files which are open and ready for use. New document windows are created in order to work with these files as required." "It is vitally important to understand that the controlling window does not contain or in any way restrict the movement of the document windows. This is not an MDI interface; it is an SDI interface that uses a controlling mechanism." "The control window should have a menu laid out according to the normal guidelines. This menu will probably not be the same as the menus on the document windows. The File menu will have a New entry, but no Open. The Quit option of the control window closes all the document windows (after any necessary save prompts) and exits the entire application. " "The Windows menu entries introduced in the Co-operating SDI model, should be available on the control window File menu as well as the document windows. Document windows should have the same menu items that they would have in the Co-operating SDI model. The contents of the control window are not laid down by these guidelines" "The top entry in the Window menu of each window should be the control window" Bye Vincenzo

1 1

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 13 Aug '03

13 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 11 Aug '03

11 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