khera@juliet.cs.duke.edu (Vick Khera) (07/05/90)
I would like to see the following in the next release of X11:
1. a better mechanism than xhost for security. a per-user list would
be perfect, allowing the list to be used as a kerberos access
control list if kerberos was available. if not available, then it
could be used similarly to the current host list. i am attempting
to implement something like this presently.
2. remove the need to install X in /usr/*/X11. some of us have to
keep other versions around for various reasons, and forcing the
location is inconvenient at best. the directory should be
completely configuration file dependent. i have had to directly
modify several source files to change the location, as well as
specify it in the config files. along the same lines, in the
makedepend program, the gcc-include directory should not be
hard-coded, but also specified in a config file. not everyone
installs gcc in /usr/local (we install it in /usr/gnu.)
at the very least, these changes should be documented with the
installation notes, not just as an errata sheet that everyone may
not get.
3. there should be some way to determine which release a particular
vendor's X implementation is based on. for example, i write a
client that must run on a release 4 server. how can i tell if a
particular vendor's X server supports release 4 or not? i can't
very well have a table of all vendor names and release numbers to
check against.
vick.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vick Khera (919) 660-6528 Department of Computer Science
ARPA: khera@cs.duke.edu Duke University
UUCP: ..!{mcnc,decvax}!duke!khera Durham, NC 27706ssdken@watson.Claremont.EDU (Ken Nelson) (07/06/90)
I would like to see an interactive Interface Developer that uses the standard supplied widgets. Part of the reason we like and use X is because it is free. Buying some of the commercial interface developers really isn't an option for us. Something that allows me to draw the interface and then generate appropriate C code would be nice. It would be a lot easier to put X wrappers around the many existing software packages for Unix (like msg, ftp, vi, jove, etc...) Ken Nelson
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/07/90)
> I would like to see the following in the next release of X11: > 3. there should be some way to determine which release a particular > vendor's X implementation is based on. And if it's not based upon an MIT release, or if it's a blend of more than one? > for example, i write a client that must run on a release 4 server. What are you doing that depends on the server being an R4 server? More likely you're depending on the existence of a feature which arrived in the MIT server with R4, like the SHAPE extension. You should be testing for the presence of the feature rather than for the generic release number. (This is a common problem with software releases, particularly with OS features. People configure "for BSD" or "for SV" when what should really be done is is to configure "has/hasn't symlinks", "has/hasn't 14-character filename limit", etc; there are enough half-breed systems[%] out there that the latter is much more useful.) [%] Intended as descriptive rather than pejorative. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
erc@pai.UUCP (Eric Johnson) (07/10/90)
In article <9007070539.AA16621@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: > > I would like to see the following in the next release of X11: > > > 3. there should be some way to determine which release a particular > > vendor's X implementation is based on. > > And if it's not based upon an MIT release, or if it's a blend of more > than one? > > > for example, i write a client that must run on a release 4 server. > > What are you doing that depends on the server being an R4 server? More > likely you're depending on the existence of a feature which arrived in > the MIT server with R4, like the SHAPE extension. You should be > testing for the presence of the feature rather than for the generic > release number. (This is a common problem with software releases, > particularly with OS features. People configure "for BSD" or "for SV" > when what should really be done is is to configure "has/hasn't > symlinks", "has/hasn't 14-character filename limit", etc; there are > enough half-breed systems[%] out there that the latter is much more > useful.) > > [%] Intended as descriptive rather than pejorative. > > der Mouse > > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu I agree in general with your comments about checking for a specific feature (especially since a great many X terminals out there are at Release 3+ -- which means something different for each vendor). But... I need to know, at compile time, whether I'm compiling on an R4 or R3-based system. R4 added a number of new Xlib calls, especially in the window manager interaction area. Since I want to write well-behaved X programs, I need to follow the rules. But, the rules changed in R4. What can you do? Look at functions like like XAllocSizeHints() (which did not exist in R3). And, do you call XSetWMNormalHints() or XSetNormalHints() ? It depends. The hard part here is that an R4 window manager will expect the extra data in these hints, while an older one won't. Some of the hints have no meaning in R4 (or ICCCM 1.0)--they were declared obsolete-- while some hints seem to have a different meaning under R3-based systems (and w.m.'s). I you have a really good means of testing for the presence of an R4 Xlib, please let me know. This is a tough problem. And, no matter what, you lose (unfortunately). Another fun problem is the question "what kind of keyboard am I using?" I know that KeySyms are supposed to make this stuff easy and portable, but just take a look at the HP-specific KeySyms on the 9000/300 (with that awful keyboard) or the Sun Type 4 keyboard (look hard at the keypad, especially the PageUp/PageDown keys and you'll know what I mean). Unfortunately, I don't live in an ideal world. I need to make software run on various systems and I need to make it run now. I need to use the special keys on HP and Sun keyboards and if anyone has a grand scheme to make this easy, please tell me. 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