peter@ficc.uu.net (Peter da Silva) (11/03/88)
In article <10794@ulysses.homer.nj.att.com>, cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: > Personally, my view is this: what the industry needs to rally > behind is one single Look and Feel. This does not mean one > toolkit. I think the industry needs to establish a subset toolkit that does all the basic things (opening a window, getting events, rendering text and graphics, defining menus (in broad terms), poke points (gadgets, radio buttons, what have you), scroll bars, and so on) reasonably well. The equivalent of curses for window systems, if you like. Look-and-feel wars are going to go on as long as the old keyboard wars, with as much chance of being resolved. I don't give a damn what the look and feel is... I just want to write a program and have it run. I have seen references to something called "STDWIN", but don't know what state it's in or how to find out about it. I don't want Open Look on my 68000-based PC. To much screen real-estate is taken up with fluff, and too many machine cycles are going to be needed for it. On the other hand someone with a 68030 and a huge screen is going to find Intuition or GEM stark and boring. But there's no reason a program shouldn't be able to compile and run on all three. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (11/03/88)
In article <2113@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <10794@ulysses.homer.nj.att.com>, I write: > > Personally, my view is this: what the industry needs to rally > > behind is one single Look and Feel. This does not mean one > > toolkit. > > I think the industry needs to establish a subset toolkit that does all > the basic things (opening a window, getting events, rendering text and > graphics, defining menus (in broad terms), poke points (gadgets, radio > buttons, what have you), scroll bars, and so on) reasonably well. The > equivalent of curses for window systems, if you like. You mean like the CORE project? Of course CORE locks you into X (I'm using NeWS, and not just because it's more fun :-), but such a toolkit could be made window system independant (like Interviews). As a programmer, I think your idea is great (and not that difficult to implement, either). As a user, I like all my windows to have the _same_ look and feel. Of course, one would assume that each hardware vendor would implement their own look and feel which the user would get used to quickly, however, in any given day, I use hardware from Sun, AT&T, HP, and Convergent. The ideal solution is to have a core window toolkit with a standard look and feel which is user modifyable (at runtime!). This way, each vendor could supply their own standard runtime modifier script, and the user could have their own personal one (/etc/ui and .uirc?). One of the reasons I run NeWS is that I can do this with PostScript code at runtime, and without needing access to expensive source (although I do have such access :-), only to examples which float around on the net. -- Christopher J. Calabrese AT&T Bell Laboratories att!ulysses!cjc cjc@ulysses.att.com
mnc@m10ux.UUCP (Michael Condict) (11/04/88)
To clarify this discussion, it should be stated explicitly that there are
two independent parts to a windowing system and there are, not suprisingly,
two different reasons for wanting to standardize them. The two parts, of
course, are the programmer interface and the user interface (also known as
the "look and feel", a vague phrase which somehow has an undignified sound,
to me).
The last two articles on this subject said "I don't care about standardizing
the look-and-feel, but I want a standardized programmer interface" and vice
versa. Clearly, one was thinking about easing the programmer's burden and
the other about easing the user's burden. I see no reason not to do both.
This does not obviate the possibility of multiple implementations of such
software, but I think that both interfaces should be standardized.
Perhaps the way to go is that there should be more than one standard for
user interface and more than one programmer interface, and the supplier of
the software for each different programmer interface would ensure that the
programmer can easily ask the software to use one of the standard user
interfaces. This of course leads to the m * n explosion that is well known in
the world of programming language translation. (m = # programmer interfaces,
n = # user interfaces). Following this analogy, the problem could be solved
by a single, highly general "intermediate" interface, that is neither biased
towards a particular programmer interface or towards a particular user
interface. Anyone could supply software that maps a desired programmer
interface to this intermediate interface, and anyone else could supply software
that maps this intermediate interface to one of the standard user interfaces.
It wouldn't suprise me if someone has already done this.
--
Michael Condict {att|allegra}!m10ux!mnc
AT&T Bell Labs (201)582-5911 MH 3B-416
Murray Hill, NJguido@cwi.nl (Guido van Rossum) (11/04/88)
In article <2113@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I think the industry needs to establish a subset toolkit that does all >the basic things (opening a window, getting events, rendering text and >graphics, defining menus (in broad terms), poke points (gadgets, radio >buttons, what have you), scroll bars, and so on) reasonably well. The >equivalent of curses for window systems, if you like. > >Look-and-feel wars are going to go on as long as the old keyboard wars, >with as much chance of being resolved. I don't give a damn what the look >and feel is... I just want to write a program and have it run. > >I have seen references to something called "STDWIN", but don't know what >state it's in or how to find out about it. I agree with Peter. Looks and Feels may come and go, but I don't want to have to rewrite my code as the fashion changes. I am also the author of STDWIN, so I could clarify any questions you have about it. It will certainly do a lot for you regarding insulation from the application's look and feel. How about me posting a summary of its goals, functionality, availability etc. to one of these newsgroups? It's about 400 lines, but worth reading. STDWIN could be of use to users of X11, Macintosh, Atari-ST, or (to some extent) any Unix box with termcap. Please send fan mail to the address below if you want me to post it. Adventurous souls can also go ahead and have a look at the source by anonymous ftp to the machine gatekeeper.dec.com, whose IP address is [128.45.9.52]. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net
peter@ficc.uu.net (Peter da Silva) (11/07/88)
In article <742@m10ux.UUCP>, mnc@m10ux.UUCP (Michael Condict) writes: > Clearly, one was thinking about easing the programmer's burden and > the other about easing the user's burden. I see no reason not to do both. Standardising the programmer's interface does this. It allows the Mac user, used to the way the Mac works, to purchase software that operates under the Mac paradigm. The Sun user purchases the same software and it works under the SunWindows paradigm. He doesn't care that the guy down the hall with the Mac and its wimpy one-button mouse has a slightly different program, and the Mac user definitely doesn't want to waste time trying to keep track of all those buttons and magic areas. > Following this analogy, the problem could be solved > by a single, highly general "intermediate" interface, that is neither biased > towards a particular programmer interface or towards a particular user > interface. This *is* a standard programmer interface. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
mnc@m10ux.UUCP (Michael Condict) (11/08/88)
In article <2153@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: >In article <742@m10ux.UUCP>, mnc@m10ux.UUCP (Michael Condict) writes: >> Clearly, one was thinking about easing the programmer's burden and >> the other about easing the user's burden. I see no reason not to do both. > >Standardising the programmer's interface does this. It allows the Mac user, >used to the way the Mac works, to purchase software that operates under the >Mac paradigm. Standardizing the programmer's interface does not guarantee that any particular user interface will be implemented by the programmer. If the programmer has a powerful enough interface, s/he can make the windows and windowing operations look arbitrarily different from any user interface in use today. The fact that some programmer interfaces may be too limited to accomplish this does not make me wrong. As someone pointed out to me, this is or was a problem on Mac's, i.e. you had to restrict your use of the programming interface to just those operations that would lead to the standard Mac user interface, at least assuming that you wanted anyone to buy your software. As for your second second statement, I don't understand the point. Of course a standard programmer interface means that you can buy software the uses the interface and it is guaranteed to compile, link and execute successfully on your machine. It is NOT guaranteed to operate under the Mac paradigm, however, if part of this paradigm is defined to be a particular user interface. That is, not unless the programmer interface is so restrictive and abstract as to permit only operations that have a reasonable implementation within the bounds of the Mac user interface. As an example, suppose the programmer interface has operations to deal with scroll bars, whereas the target user interface does not have any concept of scroll bars. It is very nice (for the programmer) that the programmer can do these scroll-bar operations at a high level and not worry about the details of their implementation, but what about the poor user who has never seen a scroll bar and doesn't know what it is used for? What about a programmer interface that allows 5-sided windows, with each of the 5-borders having a different, special purpose when clicked with a mouse? And so on. Summary: It is simply not true that the potential set of operations and rules for a windowing system are so well agreed upon that every thing in one such system has a clear analogue in another. Although maybe we should move in that direction. Michael Condict {att|allegra}!m10ux!mnc AT&T Bell Labs (201)582-5911 MH 3B-416 Murray Hill, NJ -- Michael Condict {att|allegra}!m10ux!mnc AT&T Bell Labs (201)582-5911 MH 3B-416 Murray Hill, NJ
peter@ficc.uu.net (Peter da Silva) (11/10/88)
In article <744@m10ux.UUCP>, mnc@m10ux.UUCP (Michael Condict) writes: > Standardizing the programmer's interface does not guarantee that any > particular user interface will be implemented by the programmer. That's true. We don't want the programmer implementing the user interface. > If the programmer has > a powerful enough interface, s/he can make the windows and windowing > operations look arbitrarily different from any user interface in use today. Yes, but if the programmer interface is defined well enough, it will be easier to just let the interface library stick with the defaults. > As someone pointed out to me, this is or was a problem on Mac's, i.e. > you had to restrict your use of the programming interface to just those > operations that would lead to the standard Mac user interface, at least > assuming that you wanted anyone to buy your software. The idea is that this hypothetical programmer's interface will provide all the capabilities needed by a large percentage of the programs, and most of the capabilities needed by the rest. The trick is defining this interface so it does the job right. This is, as a mathemetician might say, an interesting problem. > It is NOT guaranteed to operate under the Mac paradigm, however, > if part of this paradigm is defined to be a particular user interface. That > is, not unless the programmer interface is so restrictive and abstract as to > permit only operations that have a reasonable implementation within the bounds > of the Mac user interface. No, what I'm saying is that the programmer interface will provide a set of capabilities. These capabilities are the greatest common factor between the window systems it adresses, with some aesthetic and design decisions that let the program look reasonably nice on all the systems it supports built in. > As an example, suppose the programmer interface has operations to deal with > scroll bars, whereas the target user interface does not have any concept of > scroll bars. You mean like the AT&T 7300 UI which uses a pair of arrows, or a keyboard- oriented interface that uses cursor keys? Then when the programmer says "put a scroll-bar here" it'll put a couple of arrows on the 7300 and provide some sort of mnemonic visuals on the keyboard system (like, a picture of the keys). Of course, the variety of systems might be wide enough that a scroll-bar is to low-level a model. Maybe a text pane would be a better level of abstraction. But what's your user-who's-never-seen-a-scroll-bar-before going to do if he runs an OpenLook application on his DeskWindows machine? > Summary: It is simply not true that the potential set of operations and rules > for a windowing system are so well agreed upon that every thing in one such > system has a clear analogue in another. Although maybe we should move in that > direction. A certain subset of the screen objects are reasonably well worked out. An interface that supported only 80% of the systems out there would not be a disaster. I think that such an interface can be designed. By the way, I wasn't attempting to hold up either the Mac or X as examples of programmer interfaces to model this on. They are just examples people are likely to have had some experience with. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
domo@riddle.UUCP (Dominic Dunlop) (11/23/88)
[Just when you thought this thread was coming to an end...] A while back, in article <2113@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) wrote: >I think the industry needs to establish a subset toolkit that does all >the basic things (opening a window, getting events, rendering text and >graphics, defining menus (in broad terms), poke points (gadgets, radio >buttons, what have you), scroll bars, and so on) reasonably well. The >equivalent of curses for window systems, if you like. Good analogy, but. The problem with curses is that it has always lagged programmer and user requirements in terms of the terminal facilities to which it is able to provide access. Consequently, programmers have come up with non-standard extensions in order to access these facilities. These extensions are a pain to maintain, both for the author, and for users -- particularly those users who have more than one set of extensions to contend with. Examples are line drawing Introduced last year in 5.3.0 more then ten function keys Introduced last year in 5.3.0 auxiliary port handling Introduced last year in 5.3.0 colour Came in this year with 5.3.1 generalised non-ASCII chars Will arrive next year in 5.4.0 (Revision levels refer to AT&T UNIX releases. I could be wrong about exactly what popped up in 5.3.0, but I'm not too far out.) A standard ``look and feel'' toolkit for bit-mapped windowing environments should be as comprehensive as imaginable from day one, otherwise we're going to see the same sort of grafted-on and unmaintainable crud that we have already seen with curses. What's more, if some widget which is currently unimaginable gains a following in the future, it (or a cleaned-up, generalised version of it) must be incorporated into the toolkit in a timely manner by whoever is responsible (AT&T? Sun? OSF?), rather than five years or more later, as seems to have been the case with curses. -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp