cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/10/90)
I would say that the IEEE P1201.1 group *is* now working on a "virtual toolkit API" capable of spanning the current popular GUIs and window systems. A base document created by Marc Rochkind (XVT) was even accepted by the group as a starting point. The document is not the XVT API, but rather is a "next generation" based on lessons learned from XVT, but with lots of stuff from XVT thrown out (e.g. graphics routines) as being outside the scope of the group's charter. Sounds interesting. Can those of us that aren't members of IEEE P1201.1 get hold of copies of the base document? I would be interested to see what sort of things are being talked about. Well, actually the group is currently working under a project authorization to work on an X toolkit API, so the whole thing is kind of outside their current charter. :-) A request for a new project authorization was delayed at the last meeting on a technicality; it's being rewritten and will be resubmitted. I am right in assuming that the revised project authorization in intended to include the development of a common API for OSF/Motif and the OPEN LOOK GUI (and anything else that may be around but making less noise)? This will get a lot of support from X programmers and users if not from the GUI vendors. Some sort of reconciliation is needed between OSF/Motif and OPEN LOOK and, since the two opposing camps appear to lack the will to do this, it obviously has to be imposed by some outside body that is perceived as neutral. An IEEE standards body seems ideal, provided that the vendors can be prevented from gaining enough power to hogtie the committee. Chris Flatters
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/10/90)
Can those of us that aren't members of IEEE P1201.1
get hold of copies of the base document?
Beats me. Anyone can attend the meetings. Maybe even anyone can
subscribe to their mailings (but it does cost money).
I am right in assuming that the revised project authorization in intended
to include the development of a common API for OSF/Motif and the OPEN LOOK
GUI (and anything else that may be around but making less noise)?
My understanding is that it's supposed to deal with all of the following
toolkits, on their respective operating systems: Mac, OLIT, XView, Motif,
tNt, PM, and Windows. But don't expect it to encompass the entirety of
any one GUI or toolkit.
Some sort of reconciliation is needed between OSF/Motif and
OPEN LOOK and, since the two opposing camps appear to lack the will to
do this, it obviously has to be imposed by some outside body that is
perceived as neutral. An IEEE standards body seems ideal, provided that
the vendors can be prevented from gaining enough power to hogtie the
committee.
I don't think you know enough about how standards bodies operate. :-)gjc@mitech.com (09/11/90)
In article <9009101222.AA05082@expo.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: >> In reply to a message with some wishful thinking about >> an IEEE standards group... > I don't think you know enough about how standards bodies operate. :-) An analogy might be useful to visualize things. Standards bodies operate something like the General Assembly of the United Nations, not the Security Council. -gjc
nazgul@alphalpha.com (Kee Hinckley) (09/12/90)
In article <9009092139.AA26152@zia.aoc.nrao.edu> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: >I am right in assuming that the revised project authorization in intended >to include the development of a common API for OSF/Motif and the OPEN LOOK >GUI (and anything else that may be around but making less noise)? This Not so much a "common" API as one which sits above and uses the existing API's as a substrate. >will get a lot of support from X programmers and users if not from the GUI >vendors. Some sort of reconciliation is needed between OSF/Motif and Not from this one. I've got enough problems dealing with the lack of support and bugs in existing APIs. The last thing I need is a partial implementation of the functionality which sits on top of another toolkit. Then I have to worry about support and bugs in TWO toolkits, not to mention bypassing the toplevel one (in a different manner for each underlying API) to get the full functionality that I need. Finally I need something that is running now, not two or three years from now. And I'd appreciate it if I didn't need a separate doc set for each machine (depending on the underlying toolkit of course). Now if someone has a solution that addresses those problems I'd be very interested. >OPEN LOOK and, since the two opposing camps appear to lack the will to >do this, it obviously has to be imposed by some outside body that is >perceived as neutral. An IEEE standards body seems ideal, provided that >the vendors can be prevented from gaining enough power to hogtie the >committee. First of all I wouldn't use the word "P1201" and "neutral" in the same sentence. Secondly, I'm getting a little pissed off at this "vendors" vs. "users" stuff. There are technical reasons why a compromise is not a good idea, not just political ones. But if you try and indicate that you'd rather have one solution or another instead of some hybrid then you are promptly branded as being biased towards one vendor or another and ignored. Frankly I'd rather code my apps to two different toolkits than try and make them work with a limited functionality hybrid. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.