rsalz@bbn.com (Rich Salz) (12/04/89)
From: rsalz@bbn.com (Rich Salz) C and Unix got their start in the early 1970's (K&R has a copyright of 1978, I believe) and attempts to make international standards didn't really happen for nearly a decade later -- the mid 1980's, for the most part. The concepts and techniques had the benefit of years of wide-spread use in which to mature and prove themselves. Now IEEE wants to standardize a window system before most vendors have even started shipping a something based on non-proprietary technology? We are not even talking about a compressed adolesence here, folks -- in most cases the child can't even walk without upright a friendly adult nearby to help keep him pointed in the right direction. I wish the technical people involved in these standards processes had the guts to tell the marketing people to take a flying leap and tell them to come back in a few years when things are ready. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out. Volume-Number: Volume 17, Number 84
srg@quick.COM (Spencer Garrett) (12/04/89)
From: srg@quick.COM (Spencer Garrett) I agree with rich 100%. I figure that when the standards committees start meeting it's time to start looking for the next generation gizmo. I don't *care* how many angels can dance on the head of a pin. (If I did, I'd get a pin and a bunch of angels and ....) Win me over with simplicity and functionality or leave me alone. Volume-Number: Volume 17, Number 85
mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) (12/05/89)
From: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) In article <458@longway.TIC.COM> srg@quick.COM (Spencer Garrett) writes: >From: srg@quick.COM (Spencer Garrett) > >I agree with rich 100%. I figure that when the standards committees >start meeting it's time to start looking for the next generation gizmo. It's not exactly that. As far as windowing standard go, there is definitely the desire to have a common graphical interface so that both users and application developers have a common ground to stand on. However, it is not this desire which is being met by 1201. The users would like a common user interface (UI) so that they don't have to relearn the look and feel aspects for each and every application that comes out. The developers want a common application programming interface (API) so that they don't have to go through all the work to port their code to umpteen windowing systems on umpteen machines in order to make a successful product. There is always the problem of attempting to do too much too early and stnadardization in this area may fall prey to this common problem. The development of graphical user interfaces (GUIs) is relatively new and there are a lot of different ones out there: NeWs, X, Motif, NewWave, NextStep, SunView, Macintosh, Presentation Manager, Windows, etc. The fact that there are so many shows that there is still some shakeout going on in the industry. Lawsuits like Apple's shows how ferocious the competition in this area can be. I would agree that there are some problems with the charter for 1201, however, there are problems with not taking steps to standardize GUIs as well: increased development time for new applications (also read increased expense) and longer learning time for users on new applications. My personal feeling is that 1201 should work on an application level interface so that portable applications can be built that would provide a standardized "look and feel" to the user. Obviously, there is a significant amount of work that still needs to be done in this area, but there are some relatively safe things they can say about things like desktops, windows, menus, etc. Many of the afore mentioned windowing system's user interfaces are quite similar when you take away things like whether they shade their overlapping windows, or whether they have round or square "radio buttons". They generally provide some form of desktop, windows, menues, scroll bars, etc. Most of these ideas originated at Xerox in the 1960's and 1970's making these elements of windowing systems at least as old as Unix. Instead of focusing on either the user interface or the API, 1201 is standardizing the toolkit, which I feel is too low a layer to be working on now, primarily because it does not really address the needs of the two sides that "need" the standard the most: the users and the developers. The toolkit standardization helps the vendors because they can claim conformance to a standard and then layer the toolkit between their own proprietary user interface and API, baffling users and developers alike. It also walks the fine line of "implementation details" that standard bodies usually try so hard to avoid. There are those that would say that a windowing standard will stifle their creativity to develop their own windowing system. However, this can be countered with the argument that instead of directing their creativity to something which has been done a thousand times already (such as windowing systems), they can channel their creativity into something new and truly innovative. I don't neccessarily think that it is too early to start working on a standard. Remember that it takes a long time for a standard to come into being. By merely starting work on a standard it helps to shakeout the industry to find out what is "good" and what is not. There are definitly enough systems to look at out there. I am not sure that X is the best choice, but it is a widely accepted base: the basis for any standard. I would like to see more emphasis placed on both the UI and API aspects of the standard however, so that the standard can help more than the vendors. -- Mark H. Colburn mark@Minnetech.MN.ORG Open Systems Architects, Inc. Volume-Number: Volume 17, Number 89
peter@ficc.uucp (Peter da Silva) (12/06/89)
From: uunet!ficc!peter (Peter da Silva) Regarding a standard API for windows: > I am not sure that X is the best > choice, but it is a widely accepted base: the basis for any standard. I'm pretty sure it isn't. X is not a very clean interface, and it's much too low-level. The standard interface should not require the programmer to manually create and destroy menus, handle expose events, and so on. Look at UNIX: the API was tiny, 35 or so system calls to do everything that other operating systems required hundreds of entry points to do. You just dealt with files... details like disk space allocation, buffer allocation, and so on were hidden from the user. Window systems should be like this. Something like the X toolkits, but without the toolkits' underlying complexity. --- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "If you want PL/I, you know where to find it." -- Dennis Volume-Number: Volume 17, Number 93