- GUI - Haskell.org

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

wxGlade
by list＠taesch.com 14 Sep '03

14 Sep '03

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. 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 ...

2 1

KDE application model
by Nick Name 28 Aug '03

28 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