peter@ficc.uu.net (Peter da Silva) (02/13/90)
One thing that occures to me is that this Open Look versus Motif thing
would be easier to deal with under NeWS. It would be reasonable to implement
most of the UI in the server, and have the *user* choose Open Look or
Motif, with NeWS. It's not really reasonable to do this under X.
So if he OL/Motif war goes on long enough for V.4 with the X/NeWS merge to
get out there to a significant number of users, it might turn the X versus
NeWS war around again...
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'jg@max.crl.dec.com (Jim Gettys) (02/13/90)
Huh? I don't see your line of reasoning here.... One might just as well provide two different shared libraries, with the same programming interface. Putting things in the server does not follow as the only way to solve the problem of different "look and feels". The real problem here is that OpenLook and Motif provide different programming interfaces, not where they are implemented....
guy@auspex.auspex.com (Guy Harris) (02/14/90)
>One thing that occures to me is that this Open Look versus Motif thing >would be easier to deal with under NeWS. It would be reasonable to implement >most of the UI in the server, and have the *user* choose Open Look or >Motif, with NeWS. It's not really reasonable to do this under X. Unless: 1) you do it under V.4 or other OSes that support dynamic linking (OSF/1 will do so, right?); 2) the idea of a single API for both Motif and Open Look 1) is possible and 2) gets done; and 3) the APIs are binary compatible; in which case you might be able to install a Motif window manager+toolkit libraries to get Motif behavior, or an Open Look window manager+toolkit libraries to get Open Look behavior, or install them both and let users set LD_LIBRARY_PATH or its moral equivalent to get a choice of behaviors.
peter@ficc.uu.net (Peter da Silva) (02/16/90)
> >One thing that occures to me is that this Open Look versus Motif thing > >would be easier to deal with under NeWS. It would be reasonable to implement > >most of the UI in the server, and have the *user* choose Open Look or > >Motif, with NeWS. It's not really reasonable to do this under X. > Unless: [dynamic linking] + a single API for both Motif and Open Look + > [binary compatible interface] That's a good point. If you can get the APIs together for Motif and Open Look it should be possible to let the user select them. So "unreasonable" isn't a fair description. Is anyone working on this, though? It looks like the "standard" for Motif and OpenLook is pretty much cast in stone. It seems as if NeWS gives you more leeway for getting around shortcomings in individual programs. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
mlandau@bbn.com (Matt Landau) (02/16/90)
peter@ficc.uu.net (Peter da Silva) writes: >> Unless: [dynamic linking] + a single API for both Motif and Open Look + >> [binary compatible interface] >That's a good point. If you can get the APIs together for Motif and Open >Look it should be possible to let the user select them. So "unreasonable" >isn't a fair description. >Is anyone working on this, though? Yes, someone is working on this. There is a project at AT&T called N3 (last time I checked up on it) that's trying to define a single API that will produce either OpenLook or Motif look-and-feel, depending on which library you link with at runtime. Unfortunately, it's an Xt-based programming model (unfortunate if, like me, you don't like the Xt model in the first place), but at least it's an attempt to do the right thing.
toml@ninja.Solbourne.COM (Tom LaStrange) (02/18/90)
>> Unless: [dynamic linking] + a single API for both Motif and Open Look + >> [binary compatible interface] > >That's a good point. If you can get the APIs together for Motif and Open >Look it should be possible to let the user select them. So "unreasonable" >isn't a fair description. > >Is anyone working on this, though? It looks like the "standard" for Motif >and OpenLook is pretty much cast in stone. It seems as if NeWS gives you >more leeway for getting around shortcomings in individual programs. I just started reading this newsgroup today. YES, YES, YES!!!!! If you attended the X Technical Conference in January, you may have seen a talk given by Gary Aitken of Solbourne on just this thing! We have a C++ toolkit called OI (Object Interface) whose interaction and appearence model can be chosen by the user at run-time. You heard it right, RUN-TIME. No need for the user to set LD_LIBRARY_PATH to some different directory. Applications built with OI will get an Open Look look-and-feel by default. The user can take the same binary image and start it with a -motif option or have a "*OI*model: motif" resource set and they get the same application that looks and works like a motif application. It's real and it works. I've been using it for 10 months now it is the easiest toolkit to use that I've encountered. The hello world progam can be coded in less than 10 lines of code. Our window manager (swm) is written on top of the toolkit and can emulate just about any other window manager available. Sorry if this sounds too much like an advertisement, but it really is a nice environment. One set of applications, let the user decide how he/she wants them to look. OI is being distributed by AT&T's Unix Software Operation and an Open Look, pre-motif version should be available mid-1990. Full motif support should be there by the end of 1990. And who knows what other interfaces will end up in it? 3D Open Look? NeXT? We will be giving a tutorial on OI at Xhibition this year. If you want information now, you can contact either of the two people listed below. George Kakatsakis (303) 678-4362 Steve Kowalski (303) 678-4382 -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
nazgul@alphalpha.com (Kee Hinckley) (02/19/90)
In article <:8S1SU7xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >That's a good point. If you can get the APIs together for Motif and Open >Look it should be possible to let the user select them. So "unreasonable" >isn't a fair description. > >Is anyone working on this, though? It looks like the "standard" for Motif >and OpenLook is pretty much cast in stone. It seems as if NeWS gives you >more leeway for getting around shortcomings in individual programs. Yes people are working on this (IEEE P1201 in particular), frankly I wish they would stop. By the time they make a decision the point will be moot and they are only confusing the issue. I'm developing applications now, if someone tells me that the toolkit I'm using right now will be replaced by a "standard" one "real soon now" then my tendency is to go develop applications on a PC where I *know* what the toolkit is going to be. The market place does not need yet-another-toolkit. That's right up there with telling me that Open Look is a standard; but that AT&T machines will support one toolkit, while Sun machines will support two others. I want a toolkit that is vendor-supported on all machines. That's all. The second issue is technical. You can tell me that a merged-toolkit will solve the problems, but I've gone over the AT&T and Motif specs line by line and I claim it won't work. The only way you can make it work is to disallow features in one or both of the toolkits, and majorly cut down on the overall functionality. For esthetic reasons if nothing else (and there are other reasons) the application needs to know what's on the screen, what it looks like, and what the underlying functionality is. What happens to the OL app which tries to put a button in the Motif menu bar? Or the Motif app which accents an Open Look button by turning it red or giving it a big shadow? Each toolkit and application expects functionality that isn't allowed in the other. Oh sure, on an application by application basis I can write something high enough level to work around the issues, but I claim that a toolkit that does that for all applications will be too difficult to write, and too difficult and/or useless to use. Now, if you first merge the L&Fs, and *then* write a new toolkit (or expand an existing one), then you have something, but the L&Fs can't be merged without breaking them, and Motif won't break because one of the things it has going for it is those millions of PCs that have the same behavioral interface. So at most you can extend Motif with some Open Look features - like pushpins and property windows. That's not a merge, that's just evolution. As for NeWS. Great concept, bad timing and bad attitude. X hit the streets with too much power, and Sun was politically in a bad position to get any major acceptance of NeWS. Furthermore they pushed NeWS from the Postscript(tm) view. I went to a tutorial on NeWS at Usenix a year or two ago and walked out in the middle. Why? It was a Postscript tutorial. Sure, if I'm doing a drawing package or a text package then that's great, but I do user interfaces, I want a good highlevel interface, and Postscript is not it. Furthermore, the majority of graphics apps out there are written in fortran and do heavy tricks with color maps and everything else you can imagine to get the performance they need. Those fortran programers are not going to learn Postscript and stencils. Don't get me wrong, the ability to download functions is really neat, the ability to have an interpreted extension language is really nice, I know, I designed a window-system extension language back in '83. It's a great way to get the kind of resource-extension ability you get on the Mac, and then some. But Postscript is not at the right level for that. When it finally comes down to the wire; as an application designer I have to write to what is out there, and that's X and Motif - no question. -kee -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | BBS: 617/641-3722 | | Arlington, MA 02174 | Dumb fax, dial number, | | | nazgul@alphalpha.com | wait for ring, press 3. | BBS line is still dead | +-----------------------------------------------------------------------------+
barnett@crdgw1.crd.ge.com (Bruce Barnett) (02/19/90)
In article <:8S1SU7xds13@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >> Unless: [dynamic linking] + a single API for both Motif and Open Look + >> [binary compatible interface] > >That's a good point. If you can get the APIs together for Motif and Open >Look it should be possible to let the user select them. So "unreasonable" >isn't a fair description. Solbourne has a C++ package that supports both OpenLook or Motif. I saw a flyer from some vendor who has a high level toolkit that supports both Motif and Open Look. I can post a follow-up with the companies's name if people want.(I'm home right now). The problem with this is that it would be difficult to design a well-tuned application that really makes use of the UI. A good application pays attention to layout, common actions, screen management, etc. Assuming several commercial products are available, the best ones will be the ones that really make use of the UI to the fullest extent. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
peter@ficc.uu.net (Peter da Silva) (02/20/90)
My immediate reaction to <1990Feb17.222156.21791@Solbourne.COM> was "what
if you don't like C++?" or "What if you don't *have* C++?", but on reflection
I realise this is just my basic aversion to implementing so much of the
UI at the application level.
Is there any way other than NeWS, then, to move the UI where it belongs...
in the display the user is working on?
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'amanda@mermaid.intercon.com (Amanda Walker) (02/21/90)
In article <1990Feb18.172615.10355@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes: > I designed a window-system extension language back in '83. It's a great way to > get the kind of resource-extension ability you get on the Mac, and then some. > But Postscript is not at the right level for that. > > When it finally comes down to the wire; as an application designer I have > to write to what is out there, and that's X and Motif - no question. I want to address these issues in reverse order :-). As an application designer, it's easier (by some metrics) to write to what is out there, but it is by no means necessary. I can think of at least one company doing applications that has its own toolkit, which provides a uniform API to several kinds of look & feel, on a number of different platforms. It can look like a Mac, or Motif, or whatever. It can run under X, the Mac toolbox (I think), SunWindows, or whatever. This gives them much more leverage for their applications, since they are not constrained to X. They've since standardized on Motif, but since it's part of their toolkit they can provide Motif look & feel on machines which don't have libXm.a... The higher-level your API, the better off you are, I think. Back to extensibility. NeWS and the Macintosh (along with many Lisp machines, of various sorts, to some extent) share a characteristic which X lacks, and which I think is the basis for the positive gut reaction many people have towards them. They include a virtual machine for specifying the details of interacting with the user. In NeWS, this virtual machine is a PostScript engine with tail fins. On the Macintosh, it's a 68000. However, in both cases every user interface element is defined by a frob of code that actually manages the interaction with the user. Xt simulates some of this, but it ends up being much more unwieldy, since the class inheritance and callback mechanisms are not particularly well separated from the application. On NeWS or a Mac, it really doesn't matter much where the code that draws stuff and tracks the mouse is located. Under X, if it's not part of the original protocol, it *has* to be in the application. Maybe it's in a shared library somewhere, but they are still tightly bound together. The more loosely they are bound, the better you can distribute the processing load (and thereby improve performance) and the higher level you can make the API (see above). Now, neither PostScript or a 68000 are really tuned for low-level UI work, but neither is all that bad, either. I'm prejudiced and think that Lisp is the way to go, but I know I'm in a minority here. -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"