harkcom@potato.pa.Yokogawa.CO.JP (Alton Harkcom) (07/11/90)
If there isn't a way to do this already, how about a way to specify coordinate mode like in XDrawLines... -- --harkcom@potato.pa.yokogawa.co.jp
harkcom@potato.pa.Yokogawa.CO.JP (Alton Harkcom) (07/14/90)
Earlier I wrote... =} If there isn't a way to do this already, how about a way to specify =}coordinate mode like in XDrawLines... Pardon my forgetfulness. This applies to XPolygonRegion. I read the manual and know it says that you should specify the points with respect to a region origin, but would it be difficult to add the mode feature so that I can use the same data with a XFillPolygon in CoordModePrevious without having to translate all of my data to create the regions? Sorry for messing up the first post... -- --harkcom@potato.pa.yokogawa.co.jp
thoth@reef.cis.ufl.edu (Gilligan) (08/30/90)
For R5 I'd like other interfaces to many of the toolkit convenience procedures. XtGetSubresources is a wonderful procedure, but to use it you have to have widgets. I want a version that takes a name and class string or a pair of Quark lists and extracts all the data I need. I also want easier interfaces for the resource converters. I'd like to be able to convert a string to an int or a bitmap without using the toolkit. I realize that there are some problems with the mechanisms for extracting stuff like the Screen*, but I'd really like to use XrmParseCommand in some of my simpler utilities and programs. Can anyone point the way toward easy resource extraction in non-Xt programs? Should I construct a fake widget to enable these things? -- /-------------------- "a window is a terrible thing to paste" -me ( My name's not really Gilligan, It's Robert Forsman, without an `e' ) --------------------/
gt1111a@prism.gatech.EDU (Vincent Fox) (05/31/91)
I imagine others have already suggested this, and it may be too late,but: Couldn't the distribution be unified under one tree? It currently wants to write into /usr/bin/X11, /usr/lib/X11, /usr/include/X11, etc. It would be easier on those of us who NFS mount things if the whole things was under /usr/X11. I know R4 can be modified to do this, but it's a real pain. A default of /usr/X11, with a single variable in the Makefile so it could easily be relocated to /usr/local/X11 or some such would be just peachy. OpenWindows (yech!) does this and it's one of the limited number of things I like about it. -- Vincent Fox (That's Mr. Bucko to you)|Georgia Tech, the only place where Friday Georgia Tech, Atlanta GA |is only two working days away from Monday. SR-71: gt1111a@prism.gatech.edu | -- Uttered by David Sonnier during Pony Express:...!gatech!prism!gt1111a| CS3602 lab 5/10/1991 ~ 1730 EDT
treese@crl.dec.com (Win Treese) (05/31/91)
In article <30242@hydra.gatech.EDU> gt1111a@prism.gatech.EDU (Vincent Fox) writes:
Couldn't the distribution be unified under one tree?
It currently wants to write into /usr/bin/X11, /usr/lib/X11, /usr/include/X11,
etc. It would be easier on those of us who NFS mount things if the whole
things was under /usr/X11. I know R4 can be modified to do this, but it's a
real pain.
This is easy to do by putting the appropriate definitions in mit/config/site.def:
XCOMM site: $XConsortium: site.def,v 1.26 91/03/23 14:11:08 rws Exp $
/*****************************************************************************
* *
* SITE-SPECIFIC DEFINITIONS *
* *
* Override any of the defaults in *.tmpl here. Use ifndef so that servers *
* can override you if necessary: *
* *
* #ifndef ABuildParameter *
* #define ABuildParameter myvalue *
* #endif *
* *
* Note on using DESTDIR: If you want to install into a scratch directory *
* but will eventually move the tree back to the root, install with *
* "make install DESTDIR=directory". DESTDIR should not affect compiles. *
* *
*****************************************************************************/
/*****************************************************************************
* *
* Build Parameters *
* *
*****************************************************************************/
#ifdef ATHENA
#ifndef DoInstallExtensionsIntoXlib
#define DoInstallExtensionsIntoXlib YES /* for Makefile hosers */
#endif
#endif
#ifndef HasDESLibrary
#define HasDESLibrary YES /* DES code is built into libXdmcp.a */
#endif
/*
* Installation directories for use at CRL.
*/
#ifndef BinDir
#define BinDir $(DESTDIR)/usr/local/X11/bin
#endif
#ifndef UsrLibDir
#define UsrLibDir $(DESTDIR)/usr/local/X11/lib
#endif
#ifndef ManDirectoryRoot
#define ManDirectoryRoot /usr/local/X11/man
#endif
#ifndef ManSuffix
#define ManSuffix 1
#endif
#ifndef IncRoot
#define IncRoot $(DESTDIR)/usr/local/X11/include
#endif
#ifndef LibraryDefines
#define LibraryDefines -DXFILESEARCHPATHDEFAULT=\"/usr/local/X11/lib/X11/%L/%T/%N%S:/usr/local/X11/lib/X11/%l/%T/%N%S:/usr/local/X11/lib/X11/%T/%N%S:/usr/lib/X11/%L/%T/%N%S:/usr/lib/X11/%l/%T/%N%S:/usr/lib/X11/%T/%N%S\"
#endif
#ifndef ErrorDB
#define ErrorDB "/usr/local/X11/lib/X11/XtErrorDB"
#endif
#ifndef ExtraLoadFlags
#define ExtraLoadFlags -L/usr/local/X11/lib
#endif
#ifndef InstKmemFlags
#define InstKmemFlags -g kmem -m 2755
#endif
Win Treese Cambridge Research Lab
treese@crl.dec.com Digital Equipment Corp.chudnall@ccwf.cc.utexas.edu (Christopher D. Hudnall) (05/31/91)
- - - - - -[Vincent Fox said] | Couldn't the distribution be unified under one tree? It currently | wants to write into /usr/bin/X11, /usr/lib/X11, /usr/include/X11, etc. | It would be easier on those of us who NFS mount things if the whole | things was under /usr/X11. I know R4 can be modified to do this, but | it's a real pain. | | A default of /usr/X11, with a single variable in the Makefile so it could | easily be relocated to /usr/local/X11 or some such would be just peachy. | OpenWindows (yech!) does this and it's one of the limited number of things | I like about it. -- Careful...remember that compilation and linking like to find things under /usr/lib and /usr/include. Even though /usr/X11/bin would be okay (though that has its own problems...), changing the other two would be problematic. Only a really *good* version of xmkmf would make it possible for users to work on new programs without having to make really ugly non-portable Makefiles. -Christopher
dvb@emisle.uucp (David Van Beveren) (06/03/91)
In article <49747@ut-emx.uucp> chudnall@ccwf.cc.utexas.edu (Christopher D. Hudnall) writes: >- - - - - -[Vincent Fox said] >| Couldn't the distribution be unified under one tree? It currently >| >| A default of /usr/X11, with a single variable in the Makefile so it could >| easily be relocated to /usr/local/X11 or some such would be just peachy. > >Careful...remember that compilation and linking like to find things >under /usr/lib and /usr/include. Even though /usr/X11/bin would be >okay (though that has its own problems...), changing the other two >would be problematic. > You know, X is not part of 'vanilla' unix. (Yet). And until it is, putting things in /usr/include, /usr/lib and /usr/bin is uncalled for. This is especially true for things that are hard coded in clients, and there are still a few of those around. Could you imagine a DOS application program that insisted on being on the C: drive in a certain directory. That program would be considered very non-flexible. (aka bad) I know you can put move most of X by editing 20 or so lines in 2 or 3 different parts of the Imake environment. But, most users of X are not X hackers, and this is not clearly documented anywhere, and even if it was, why make it so difficult? Is it the elite attitude of some system programmers "IF it is too difficult for you, then you are just a inferior sysadmin.." that causes this? I am not an X hack, although I have been programming with X for about 3 years steady. I could probably figure out how to do it without too much trouble, but why should it require any effort at all? My advice to MIT is to put X in a completely separate tree. All compilers and OSes in the world have facilities for naming alternate directories for include files and libs (-I, -L, etc.). Well, maybe not all, but close enough to matter. If the OS requires things to go into certain directories, make that part of the .cf files for that OS. But, the default should not be what it is. Its just plain arrogant. Of course, I doubt that this will happen with R5 or ever. -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247
marbru@auto-trol.com (Martin Brunecky) (06/03/91)
In article <1991Jun2.234509.1263@emisle.uucp> dvb@emisle.UUCP (David Van Beveren) writes: > >You know, X is not part of 'vanilla' unix. (Yet). And until it is, putting >things in /usr/include, /usr/lib and /usr/bin is uncalled for. This is >especially true for things that are hard coded in clients, and there are still >a few of those around. Could you imagine a DOS application program that >insisted on being on the C: drive in a certain directory. That program would >be considered very non-flexible. (aka bad) > The whole problem is that Unix as a whole has not realized (yet) that for customers environments, it's philosophy of grouping files "by type" rather than "by package/release" is inadequate. Sure, for hackers it makes life easier to shove all libraries into a single place, all header files into on place: the hacker then only uses one -I or -L (if even that). But an end user does NOT care about hacker's/developers convenience. He wants to clearly seperate individual packages on his systems. He wants to isolate those from the OS upgrades (which often destroy the entire /usr/lib/ and similar). For example, if you want to remove X from your system, how do you identify all it's pieces ? (sure, knowing the MIT tree, not that big task - just look for all the "things" starting with X or /X - but what if the system has some other product which likes "X" on it...). IMHO X should NEVER be considered a part of 'vanilla' unix. It is not a base, essential system component. It is a package running on the top of Unix. Very often, X from different vendors (or different releases of X) may be needed on the same system. Munging X into 'vanilla', hardware vendor provided Unix directory tree is simply a mistake. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru%auto-trol@sunpeaks.central.sun.com (303) 252-2499 (better avoid: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (06/04/91)
Simple setup:
/usr/X11/bin/*
/usr/X11/include/*
/usr/X11/lib/*
/usr/bin/X11 -> /usr/X11/bin
/usr/include/X11 -> /usr/X11/include
/usr/lib/X11 -> /usr/X11/lib
Agree; everything under ONE tree is nice. Also agree that the other path
names can't just be blown away.
Thomas Gilg
tomg@cv.hp.comgstiehl@convex.convex.COM (Greg Stiehl) (06/04/91)
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) writes: > > Simple setup: > > /usr/bin/X11 -> /usr/X11/bin > /usr/include/X11 -> /usr/X11/include > /usr/lib/X11 -> /usr/X11/lib This is exactly how we do it. And you don't *have* to change the imake files to get this, either. Just: # make install DESTDIR=/usr/X11 # mv /usr/X11/usr/bin/X11 /usr/X11/bin # mv /usr/X11/usr/include/X11 /usr/X11/include # mv /usr/X11/usr/lib/X11 /usr/X11/lib # mv /usr/X11/usr/lib/*.a /usr/X11/lib ## clean up # rm -r /usr/X11/usr ## link the directories into /usr # ln -s /usr/X11/bin /usr/bin/X11 # ln -s /usr/X11/include /usr/include/X11 # ln -s /usr/X11/lib /usr/lib/X11 ## and if you don't want to make everyone do a -L/usr/X11/lib # ln -s /usr/X11/lib/*.a /usr/lib If you can help it, I would highly recomend that you *don't* link all the libraries into /usr/lib (the last line). For that matter, I wouldn't do any of the links into /usr. Just force everyone to use -L/usr/X11/lib -I/usr/X11/include. Of course, for those of us who have customers that expect things to always be in the same place... #ifdef WISH This does have one problem. X want to find things (like app-defaults) in /usr/lib/X11. This can be changed at compile time, but (as far as I know) it can't be changed at run time. It would be trivial to add a XLIBDIR environment variable that could also be set to /usr/X11/lib. If fact, the best thing would be to have a XLIBDIRPATH, that could be set to a number of directories (separated by colons). #endif /* WISH */ The really neat thing about this, is that /usr/X11 can be a link to something else. This is really nice for trying new releases. -greg. ---- Greg Stiehl (gstiehl@convex.com) Graphics Software Convex Computer Corp.
cek@wsc-sun.boeing.com (Conrad Kimball) (06/04/91)
In article <1991Jun2.234509.1263@emisle.uucp>, dvb@emisle.uucp (David Van Beveren) writes: |> I know you can put move most of X by editing 20 or so lines in 2 or 3 |> different parts of the Imake environment. But, most users of X are not X |> hackers, and this is not clearly documented anywhere, and even if it was, |> why make it so difficult? Is it the elite attitude of some system programmers |> "IF it is too difficult for you, then you are just a inferior sysadmin.." |> that causes this? I am not an X hack, although I have been programming with X |> for about 3 years steady. I could probably figure out how to do it without |> too much trouble, but why should it require any effort at all? I share this opinion too. For what it's worth, though, I've been installing X in a non-standard location for more than a year now, using the following simple patch. It simply builds X to know it lives in a directory tree rooted somewhere other than /usr. There is still the drawback that this alternate "home" directory must be compiled in from the beginning. Of course, users must also know about this alternate home, so they can include the proper directory in their PATH, and use the proper -I and -L parameters when building their own X software (though this latter problem doesn't arise if they use xmkmf, which *does* know about this alternate home directory). ------------ cut here ------------------------------------------------------ This patch configures the MIT X-Window Version 11 Release 4 tape to have X-Window live in the directory tree rooted in "/home/other/X11/R4/sun4/usr" rather than "/usr". This allows X11R4 to coexist with another version of X-Window that may already be installed on the system. *** mit/config/site.def.orig Sun Dec 17 15:06:24 1989 --- mit/config/site.def Fri Sep 21 12:21:55 1990 *************** *** 144,146 **** --- 144,153 ---- #ifndef SharedLibXext #define SharedLibXext NO /* XXX - haven't made it sharable yet */ #endif + + /* + * Install X11R4 under /home/other/X11/R4/sun4 rather than / + */ + #ifndef DestDir + #define DestDir /home/other/X11/R4/sun4 + #endif ------------ cut here ------------------------------------------------------ -- Conrad Kimball Boeing Computer Services (206) 865-6410 Email: cek@wsc-sun.boeing.com or cek%wsc-sun@atc.boeing.com UUCP: uw-beaver!bcsaic!wsc-sun!cek
tot@frend.fi (Teemu Torma) (06/05/91)
In article <1991Jun04.133705.15431@convex.com> gstiehl@convex.convex.COM (Greg Stiehl) writes:
This does have one problem. X want to find things (like app-defaults) in
/usr/lib/X11. This can be changed at compile time, but (as far as I know)
it can't be changed at run time. It would be trivial to add a XLIBDIR
environment variable that could also be set to /usr/X11/lib. If fact,
the best thing would be to have a XLIBDIRPATH, that could be set to
a number of directories (separated by colons).
There is an environment variable XFILESEARCHPATH. Set it to
XLIBDIR/%T/%N%S and it does the trick.
- tot
--
Teemu Torma
Front End Oy, Espoo, Finland
Internet: tot@frend.firobert@dg.se (Robert Claeson) (06/05/91)
In article <100920323@hpcvlx.cv.hp.com>, tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) writes: |> Simple setup: |> |> /usr/X11/bin/* |> /usr/X11/include/* |> /usr/X11/lib/* |> |> /usr/bin/X11 -> /usr/X11/bin |> /usr/include/X11 -> /usr/X11/include |> /usr/lib/X11 -> /usr/X11/lib |> |> Agree; everything under ONE tree is nice. Also agree that the other path |> names can't just be blown away. I believe that SVR4 as shipped by AT&T has all the X stuff under /usr/x/*. -- Robert Claeson Just because I am writing this doesn't mean that my employer agrees with me.
dce@smsc.sony.com (David Elliott) (06/05/91)
In article <TOT.91Jun4222710@merc.frend.fi>, tot@frend.fi (Teemu Torma) writes: |> In article <1991Jun04.133705.15431@convex.com> gstiehl@convex.convex.COM (Greg Stiehl) writes: |> |> This does have one problem. X want to find things (like app-defaults) in |> /usr/lib/X11. This can be changed at compile time, but (as far as I know) |> it can't be changed at run time. It would be trivial to add a XLIBDIR |> environment variable that could also be set to /usr/X11/lib. If fact, |> the best thing would be to have a XLIBDIRPATH, that could be set to |> a number of directories (separated by colons). |> |> There is an environment variable XFILESEARCHPATH. Set it to |> XLIBDIR/%T/%N%S and it does the trick. The default for XFILESEARCHPATH is /usr/lib/X11/%L/%T/%N%S:/usr/lib/X11/%l/%T/%N%S:/usr/lib/X11/%T/%N%S Teemu's trick works fine if you only support one locale, though. In addition, there's a variable called XUSERFILESEARCHPATH, which defaults to a really messy string which is slightly messier if you have XAPPLRESDIR set. Still, having to set these environment variables is a real mess for an end-user, and we don't always have control over the environment. At best, an application programmer can concatenate things onto the ends of these variables to try to get things right, but even that is a mess. As for other files that are used by the program, the best way to handle these is through the use of resources. This allows for debugging (set the resource to the source directory) and for special installations. It's very easy to do once you get the hang of it. One thing I would like to see is something along the lines of a {class}.local file which would be merged with the contents of the app-defaults file (and take precedence). That way, I can use the distributed app-defaults file provided by the software vendor without modification, but still add in system-specific information (kind of like site.def in the X config directory). -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."Art is never fair" - paa
aw@jello.bae.bellcore.com (Andrew Wason) (06/06/91)
In article <TOT.91Jun4222710@merc.frend.fi>, tot@frend.fi (Teemu Torma) writes: > In article <1991Jun04.133705.15431@convex.com> gstiehl@convex.convex.COM (Greg Stiehl) writes: > > This does have one problem. X want to find things (like app-defaults) in > /usr/lib/X11. This can be changed at compile time, but (as far as I know) > it can't be changed at run time. It would be trivial to add a XLIBDIR > environment variable that could also be set to /usr/X11/lib. If fact, > the best thing would be to have a XLIBDIRPATH, that could be set to > a number of directories (separated by colons). > > There is an environment variable XFILESEARCHPATH. Set it to > XLIBDIR/%T/%N%S and it does the trick. That solves the problem for app-defaults files, but there are other pathnames hardcoded in libX/libXt (e.g. /usr/lib/X11/XErrorDB, /usr/lib/X11/XtErrorDB, /usr/lib/X11/XKeysymDB). These can be changed at compile time, but I am not aware of any environment variables to change them at runtime. Andrew _______________________________________________________________________________ Andrew Wason Bell Communications Research aw@bae.bellcore.com Piscataway, NJ bellcore!bae!aw
dgreen@hilo.cs.ucla.edu (Dan R. Greening) (06/08/91)
In article <1855@wsc-sun.BOEING.COM> cek@wsc-sun.boeing.com (Conrad Kimball) writes: >For what it's worth, though, I've been installing >X in a non-standard location for more than a year now, using the following >simple patch. It simply builds X to know it lives in a directory tree rooted >somewhere other than /usr. There is still the drawback that this alternate >"home" directory must be compiled in from the beginning. Of course, users >must also know about this alternate home, so they can include the proper >directory in their PATH, and use the proper -I and -L parameters when building >their own X software (though this latter problem doesn't arise if they use >xmkmf, which *does* know about this alternate home directory). [patch which only changes mit/config/site.def] This patch is slightly incomplete. I wrote an extensive patch to compile X11R4 libraries and clients on RS6000s, some of which relocates X11 to /usr/local/bin/X11 and friends. We needed to do this to allow both X11R3 and X11R4 to coexist on the RS6000. I wouldn't call someone an inferior sysadmin for not wanting to do it. Figuring out the ins-and-outs of imake isn't exactly in the mainstream of system administration. In any event, X11 clients will not be able to fetch bitmaps out of /usr/local/include/X11/bitmaps unless you fix Xt's Imakefile. I would recommend that you take a look at my changes for hints if you want to relocate X. They are in ibm-rs6000.fix1 and ibm-rs6000.fix2 on export. Regards, -- ____ \ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd \/ dgreen@cs.ucla.edu (408) 973-8081 x313 Cupertino, CA 95014