PSCOTT@DECUS.BITNET ("Peter Scott, NASA/JPL") (05/09/89)
One of the main justifications I am required to provide for the powers-that-be for our investment in X is that programs written using it are completely portable, or, at least, if they are not, the non-portable code will not be part of the X code. <FLAME ON> When I first joined this group, I posted a note saying, essentially, "I've read that the X protocol and Xlib are standards, but nothing about the toolkit being a standard. Should I write my programs in Xlib only to ensure portability?" And the replies came back, "No, no, use the toolkit, it's part of the standard, everyone has it". Just went to a seminar on X-Windows here at DECUS and found out that the toolkit is *not* part of any standard, that standardization efforts are being made, but that they will standardize on either Motif, XUI, or something from Unix International, *not* the Athena widgets. Furthermore, attempting to port the MIT toolkit to X implementations that don't have it (for instance, DEC workstations, of which we have a lot and are getting more) is likely to be fraught with difficulties in areas such as file system access. Code is not portable if you have to take a huge amount of source code from the libraries that it calls and port *that* to your target system. Some people who are not being paid to produce results might not consider that a problem. Now I have to recode the Sun-Vaxstation portability demo I was working on using Xlib calls only. I understand that standardizing the protocol and Xlib first was great for vendors, but it is a pain for application programmers (and even worse for users, who still don't have consistent look-and-feel) when they don't have a standard to program by. <FLAME OFF> (Flame not directed at any individuals personally) Peter Scott (pjs@grouch.jpl.nasa.gov) (Do not reply to the originating address of this message, it is only good for this week)
rws@EXPO.LCS.MIT.EDU (05/10/89)
"No, no, use the toolkit, it's part of the standard, everyone has it".
I have no idea exactly what question you asked, or exactly what replies
you got, or whether they were from authoritative sources. Certainly, many
people think of Xt as a "toolkit" of sorts, and that can cause confusion.
Just went to a seminar on X-Windows here at DECUS and found out
I have no idea why you had to wait until then. If you have the R3 from
MIT, there is a STANDARDS file at the top of the tree which clearly states
what is and isn't a Consortium standard (e.g. Xt is, Athena Widgets aren't).
This file is also documented in the Release Notes. If you don't have R3 from
MIT, you haven't done your homework. If you do have R3 and didn't find this
information, you haven't done your homework.
Furthermore, attempting to port the
MIT toolkit to X implementations that don't have it (for instance, DEC
workstations, of which we have a lot and are getting more) is likely to be
fraught with difficulties in areas such as file system access.
I'm not sure what the basis for this remark is. Certainly, we run clients
every day on "DEC workstations", of both the VAX and PMAX variety, using the
Athena Widgets. Our DEC workstations are Ultrix based. If you're moving to
VMS, certainly you'll have some work to do, but it shouldn't be that much
(most of the widgets don't touch OS services).
I understand that standardizing the protocol and Xlib first was
great for vendors, but it is a pain for application programmers (and even
worse for users, who still don't have consistent look-and-feel) when they
don't have a standard to program by.
Then perhaps you should get your organization more involved in standards
efforts.dshr@SUN.COM (David Rosenthal) (05/10/89)
"Don't, don't believe, don't believe the hype." Public Enemy Peter Scott writes: > One of the main justifications I am required to provide for the powers-that-be > for our investment in X is that programs written using it are completely > portable, or, at least, if they are not, the non-portable code will not be > part of the X code. > followed by a (self-admitted) flame about the toolkit. Unfortunately, it is not true that even programs written only using Xlib calls are "are completely portable, or, at least, if they are not, the non-portable code will not be part of the X code." X exposes a number of features of the underlying displays, keyboards, and machines. X client programs, even those written using only Xlib, that do not take proper account of variations between servers including, for example: - The different keysyms available on different keyboards. - The different number of buttons on different mice. - The different types, depths and numbers of Visuals. - The different amounts of memory available to different servers. will not port automatically between servers. This topic is far from trivial - David Lemke and I were able to write an entire Usenix paper on just one of these classes of difference (Visualizing X11 Clients in the Winter '89 Usenix). If Peter has been selling his management the concept that X provides automatic and total portability, he has much more to worry about than the availability of the toolkit. In fact, in most cases the toolkit (whichever toolkit he uses) is actually helping his portability by being properly designed to cope with some of the differences between servers. X makes portability much easier to achieve, but it does not guarantee it. Only you, as the client programmer, can guarantee that. David.