Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!uc!cs.umn.edu!dmshq!com50!pai!erc From: erc@pai.UUCP (Eric Johnson) Newsgroups: comp.windows.x Subject: Re: what's most important to you for R5? Keywords: Easy-to-use International Selections Message-ID: <1336@pai.UUCP> Date: 3 Jul 90 20:47:17 GMT Organization: Boulware Technologies, Inc., Burnsville, MN Lines: 167 In <9006222202.AA17654@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > No, I won't tell you when R5 is, and no, > I won't tell you what we do or > don't have planned for it. Why not? > This is your chance to flame, cajole, and lobby > for what you think the priorities for R5 should be. I don't guarantee I'll > agree or even have time to respond, but I do guarantee I'll listen. > I'm interested in "big" things, not adding another frobnotz resource > to xterm. Examples of big things that were in R4: ICCCM, XLFD, XDMCP, > Compound Text, SHAPE extension, lotsa bitmap fonts, server performance. I hope these are big enough. > Send your thoughts directly to me, or post them on the net if you prefer. I'm both mailing and posting this. The list below is in the order of importance to me. (I've noticed that each release of the X Window System is better and more professional than the last. I make extensive use of X and am very grateful for all the work that has been done, so please take all the suggestions below as constructive suggestions. I intend no flames, so please don't take anything as such.) 1) Make X easier for USERS to use. That is, have less reliance on resource files and other hard-to-understand configurations. X is still a developer's windowing system and isn't quite there yet as an end-user's windowing system. Perhaps a resource file editor with a graphical interface and a LOT of on-line help would improve things? Most users don't have the faintest idea what a widget hierarchy is, so being able to see and modify that won't really help much. We need something that is EASY. 2) More "transparent" support for international users of X. (I understand the Consortium is working in this area.) What I'm looking for are a set of routines that I can use in my programs to draw and read in text that may be formatted in may different national styles. To start with, I'm asking for some form of merger between all the 8-bit and 16-bit string functions, e.g., XTextWidth(), XTextWidth16(), XTextExtents(), XTextExtents16(), XQueryTextExtents(), XQueryTextExtenst16(), XDrawText(), XDrawText16(), XDrawString(), XDrawString16(), XDrawImageString() and XDrawImageString16(). An X programmer shouldn't have to worry so much about the actual formatting of the text. Let's face it, I doubt many X programmers use any of the *16 functions at all. If we are ever going to make software that works in other countries, we need to make the task easier on the software developers. In addition, an analog of XLookupString() would be required for character input. We'd also need functions to convert C strings to and from whatever string encoding is used (compound text, text properties, et. al.?). I'm sure there are a few other areas (Glen Widener of Tektronix mentioned a few last time I saw him). 3) An Xlib #define that states what version of Xlib you are compiling on, e.g., #define X11R4 for Release 4, etc. This would ease the programmer's task where changes are introduced to the X library. #ifdef X11R4 ...new stuff here... #else ..old stuff for compatibility... #endif If such a symbol were built in, then people could standardize on how to handle the changes. 4) Distribution of the X Consortium releases on QIC-formatted 1/4" cartridge tapes, in addition to the current 1/2" mag tapes. In three years, CD-ROM will probably be the format of choice, but for now many users never see 1/2" tapes (except in 1960s science fiction movies). 5) Contrib code that compiles on the new release. Perhaps the contrib tape(s) should be released after the core release (by about a month, say). This way, those who contribute software could make sure their code will work on the new release. This would also cut down on the number of patches sent out right after an X release. I know it would be a pain, but so is having a tape full of programs that if they even compile, chances are don't work. (I'm not trying to flame anyone here, I'm just trying to find a way to allow the contrib authors to update their stuff before it goes out with the new release. My goal is better, more usable software, not complaints.) 6) X11R5 support for UNIX System V 3.2 on 386 machines as part of the core release. There are quite a few of these machines out there (mainly because of the low costs involved), even if real programmers hate Intel architectures. 7) Improved support for selections. Right now, most users of selections are just cutting and pasting text--something that the much-maligned cut buffers did, but only in a way that is 100 times more complex and difficult than the simple cut buffers. The X core software set should make better use of selections to show more of the potential of selections and provide examples of the use of selections (to teach and encourage others). For example, the bitmap client should be able to exchange bitmaps as selections, supporting some form of cut and paste. (Xedit should be willing to support a FILENAME target, too, etc..) If more clients supported selections (or supported selections more thoroughly) then users would gain a lot more in--I hate this word-- interoperability. Much like the UNIX philosophy, each X client could be a small, interoperable program that communicates well with other X clients and does just one thing, but does that thing well. 8) Xt and Xaw toolkit support for both OSF/Motif and OpenLook ClientMessages, Properties and Selections. The idea here is to make Xaw/Xt programes interact better with the two major (two other major :-) X toolkits and window managers. I'm sure the X Consortium doesn't want to choose any sides in these interface wars, but I think we can all agree that OpenLook and OSF/Motif (and Xaw) are the toolkits/interfaces with the most going for them right now. 9) Include M. Ackerman's Answer Garden (or whatever he calls his set of software designed to help answer frequently-asked questions regarding X) as part of the core release. Or anything to help new X programmers, X installers and X users get going. 10) Provide more information on X changes, in advance, even to non-consortium members. The message I heard from you at the X Technical Conference in January was essentially "don't join" the consortium (basically since any new members would have to pay for the two previous years as well, with no added benefit). Add in this don't-join message and the if-you're-not-a-member,-you-lose message, and you put a lot of people in a no-win situation. Would it really hurt to let people know, in advance, what's coming up in the new release? I'm not expecting you to say "I promise that xxxx will be in the next release," but something like "We are working on improving xxxxx or adding yyyyy to the next release" or "People who make extensive use of zzzzz should watch out" would certainly help. 11) Include a mention about running ldconfig, in REALLY BIG TEXT, as part of the documentation on installing X on Suns (if it is still applicable). (This must be one of most-asked questions in comp.windows.x.) Perhaps the make install could use banner to blare out a big message--just to remind folks what else needs to be done. 12) Better performance of ovals (arcs), especially for windows using the SHAPE extension. (Try a 200x200 window that has a shape of many 10x10 rectangles and compare to a window that has a shape of 10x10 ovals. The rectangle-based window does OK, the oval-based window crawls painfully slow.) 13) Many more program examples to help new programmers learn how to program in X, especially X toolkits. 14) 24-bit colour support. (Another frequently-asked question.) Have fun, -Eric -- Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA