Path: utzoo!yunexus!geac!david From: david@geac.UUCP (David Haynes) Newsgroups: comp.windows.misc Subject: Re: Window Toolkits and Systems for a bunch of systems. Summary: Yes, Really UIMs Keywords: Window Toolkits, Window Systems, Portability Message-ID: <3111@geac.UUCP> Date: 31 Jul 88 11:42:26 GMT Article-I.D.: geac.3111 References: <732@muddcs.Claremont.EDU: <356@uva.UUCP> <3085@geac.UUCP> <4502@mit-vax.LCS.MIT.EDU> Reply-To: david@geac.UUCP (David Haynes) Organization: /usr/lib/news/organisation Lines: 110 In article <4502@mit-vax.LCS.MIT.EDU: jim@expo.lcs.mit.edu (Jim Fulton) writes: :> However, certainly in the case :> of X, I think that they have made an error in their way of implementing :> the Toolkit libraries. :> :> X causes the toolkit libraries to be linked in with the application :> code. This causes large applications which are only portable between :> X servers -- fair enough. : :X (i.e. the X Protocol) has nothing to do with whether or not a toolkit is :linked into an application. Yes, I recognized this and stated in the next paragraph that X did not require you to do this, simply that this was the way it was being used. I also recognize that X `The Protocol' is completely independant of the particular implementation. However, I had hoped that the statement about `implementing the Toolkit libraries' was clear enough in that I was refering to the implementation not the protocol. However, upon reflection, I think that `error in implementation' was a poor choice of words. What I was trying to say was that the X toolkit routines, being presented as linkable subroutines, were temping many people to call them from directly within their client applications and that, this may not be the best choice under my definition of portability. : Also, if one has shared libraries, even :sophisticated applications aren't all that large. Unfortunately, even today, that if is a pretty big one! Yes, I know that all systems will tend toward shared libraries eventually, but, some of us are trying to use the X system today (both protocol and implementations) in `older' environments. :The X Toolkit was designed to take maximum advantage of the X Window System. :People who want window-system independence, or who aren't running X, will :probably want to choose another toolkit (such as Andrew, STDWIN, etc.) or :design their own. It all depends on what one's definition of "portability" is, :or more importantly, on what the requirements of the situation are. Again, we agree. For the article I was using `the ability to move to other windowing systems with minimum effect on the application' as a localized definition of `portability'. :> So, why not add layers of protocols between the application, :> something I will call the "agent" and the window manager? : :Ah, motherhood and apple pie! This "agent" is often called a User Interface :Management Systems and is rapidly becoming one of the hotter topics for :research and development. Lots of opportunities for Cognitive Scientists, :Graphic Artists, and even Software Engineers. :-) I was not willing to use the term IUMs initially since that term was rather over-used and abused in the Office Automation market about 5 years ago. I built IUMs for curses-based screens at that time, but was never really satisfied with them since, in my opinion, they never really hit to the center of the problem. (which I will outline at the end of this) :Providing a good foundation for building UIMS's was one of the design goals of :the X Toolkit. And in this, I think you have succeeded! The fact that I could implement so much of Prism (my UIM environment) with it lends strong credence to the statement. : There are currently several commercially available UIMS's (e.g. :X-Pression, Open Dialogue, XUI, New Wave, etc.) and I expect to see a flurry of :new announcements over the next year. : Jim Fulton : MIT X Consortium Jim, somehow it appears that you have mistaken my comments to be an attack of X (or the X toolkit at any rate). This was not my intention. I am the Canadian X Software Repository moderator and support the X system to its fullest. My comments were more a comment on the way in which the X toolkit was being used by current implementors and how their method of implementation required that their applications would have to be substantially rewritten in order to move to another windowing system. Good software is expensive to write once, let alone for each type of bitmapped windowing system available. Now, to the problem I alluded to: In building the prototype for Prism, it quickly became apparent that, not only was there a need for a separation of the precedural and the presentational aspects of the data (this separation is the role of the UIMs), but another layer of separation was required between the logical (symbolic) and the physical representation of the data being manipulated by the program. For example, Ingres has a textual data element which can store up to 2000 characters (called text I believe), however, in an application, I may have entites called `address' or `comments' which are of type text for ingres but of type `string' for another database. In addition, this logical description of the data is where I would like to place my presentational information such as the fact that a date is three numeric entities in the format dd/mm/yy. Has anyone done any work on this logical entity to physical mapping of data? For want of terminology, I have called the physical mapping the data dictionary (which I believe is the correct term) and the logical mapping to the data dictionary the `data definition'. -david- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Haynes Geac Computers Canada Ltd. Telephone: +1 416 475 0525 350 Steelcase Road West, FAX : +1 416 475 3847 Markham, Ontario, CANADA. L3R 1B3 UUCP : utgpu!geac!david Official Keeper of the Canadian X11 Sources Repository