wf08+@andrew.cmu.edu (William Frank) (07/13/90)
Gee.. All I want for R5 is for the server to pass on expose events to clients that have backing store on, if the event was sent with SendEvent. Thus ATK could still use backing store and the window manager could redraw ATK applications (via SendEvent). Hence I would not have to hit Cntl-L everytime some thing gets drawn wrong. If I tell it I want it to redraw, I WANT it to redraw! -William Frank wf08@andrew.cmu.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/13/90)
All I want for R5 is for the server to pass on expose events to clients
that have backing store on, if the event was sent with SendEvent.
There's no reason why it shouldn't today. Perhaps you could elaborate
on what exactly you are doing (what mask you are passing to XSendEvent,
what mask the client has selected with) so that someone could understand
where the problem is. Perhaps you are just confused.montnaro@milkweed.crd.ge.com (Skip Montanaro) (07/18/90)
How about getting rid of Imake and using GNU make instead for R5? I've never gotten Imake to work properly, and always wind up translating Imakefiles into GNUmakefiles. -- Skip (montanaro@crdgw1.ge.com)
bin@primate.wisc.edu (Brain in Neutral) (07/18/90)
From article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, by montnaro@milkweed.crd.ge.com (Skip Montanaro): > > How about getting rid of Imake and using GNU make instead for R5? I've never > gotten Imake to work properly, and always wind up translating Imakefiles > into GNUmakefiles. Ahh .... no. Please don't. Imake is wonderful. It would, though, be nice if there were more documentation about how to overcome some of the more common errors likely to crop up during the configuration process (e.g., your Makefile gets hosed). Or more comments in the configuration files. Sometimes they're mighty cryptic. Or is it just me? I really like imake a lot, but found I have to invest quite a bit of time trying to understand it before I was able to take it and use it for my own projects. Is this unusual? Paul DuBois Internet: dubois@primate.wisc.edu UUCP: rhesus!dubois CompuServe: >INTERNET:dubois@primate.wisc.edu FAX: 608/263-4031
baur@venice.SEDD.TRW.COM (Steven L. Baur) (07/18/90)
From article <2767@uakari.primate.wisc.edu>, by bin@primate.wisc.edu (Brain in Neutral): > From article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, by montnaro@milkweed.crd.ge.com (Skip Montanaro): >> How about getting rid of Imake and using GNU make instead for R5? I've never >> gotten Imake to work properly, and always wind up translating Imakefiles >> into GNUmakefiles. > Ahh .... no. Please don't. Imake is wonderful. It would be nice too, if those vendors out there who distribute binary-only versions of X would include sufficient files to be able to make Imake work at all. (I won't name any names, you know who you are). I have had *wonderful* results with Imake on a SUN3/OS4.03->4.1 with all-MIT sources, and don't see any particular need to make it go away. I wish though that there wasn't so much (apparent to me, a novice X administrator) dependence upon the X source hierarchy. After installation of the mit area of X, it should be possible to avoid having to use the MIT source hierarchy as part of the Imake process. I mean, I have set up my symbolic links to /usr/bin/X11, etc. Why do "contrib"uted programs have to rely on the core X source tree? X11R4 is wonderful, thanks MIT and the X Consortium. -- steve baur@venice.SEDD.TRW.COM
stolcke@icsib12.Berkeley.EDU (Andreas Stolcke) (07/18/90)
In article <675@venice.SEDD.TRW.COM> baur@venice.SEDD.TRW.COM (Steven L. Baur) writes: >dependence upon the X source hierarchy. After installation of the mit area >of X, it should be possible to avoid having to use the MIT source hierarchy >as part of the Imake process. I mean, I have set up my symbolic links to >/usr/bin/X11, etc. Why do "contrib"uted programs have to rely on the core X >source tree? They don't. Once you installed /usr/bin/X11/xmkmf and the stuff in /usr/lib/X11/config, just type 'xmkmf' and a Makefile will be built that uses only the installed headers and libs. (In fact, it is annoying to see all those Imakefiles with INCLUDES = ... around where in most cases it's completely redundant). I agree that Imake is a Good Thing. I'm wondering however why the numerous bugs in the Imake configuration files in R4 tape (mostly reported in this newsgroup) have never been fixed by any of the official MIT fixes. That's one of the reasons why some people are still having a hard time with Imake, I believe. ---- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
jf@ap.co.umist.ac.uk (John Forrest) (07/18/90)
In article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, montnaro@milkweed.crd.ge.com (Skip Montanaro) writes: |> |> How about getting rid of Imake and using GNU make instead for R5? I've never |> gotten Imake to work properly, and always wind up translating Imakefiles |> into GNUmakefiles. |> |> -- |> Skip (montanaro@crdgw1.ge.com) If you have never got Imake to work that is your problem, because I would expect that almost everyone else has. Imake is indespensible for handling different compilers and operating systems - we usually get out X source after it has been on a Sun system in the next building, and about all you can do with the Makefiles from there is "make Makefiles". The difference between their gcc orientated makefiles and our Apollo cc ones is considerable. I hope nobody takes this suggestion seriously. John Forrest Dept of Computation UMIST
rlh2@ukc.ac.uk (Richard Hesketh) (07/18/90)
In article <675@venice.SEDD.TRW.COM> baur@venice.SEDD.TRW.COM (Steven L. Baur) writes: >I have had *wonderful* results with Imake on a SUN3/OS4.03->4.1 with all-MIT >sources, and don't see any particular need to make it go away. I wish though >that there wasn't so much (apparent to me, a novice X administrator) >dependence upon the X source hierarchy. After installation of the mit area >of X, it should be possible to avoid having to use the MIT source hierarchy >as part of the Imake process. I mean, I have set up my symbolic links to >/usr/bin/X11, etc. Why do "contrib"uted programs have to rely on the core X >source tree? Have you tried using "xmkmf" a little script added by the standard installation process that makes using Imakefiles even easier ? .. the comment for this bourne script says .. # generate a Makefile from an Imakefile from inside or outside the sources! The normal installation process places a copy of all the configuration files needed by imake into the lib directory that has been specified in the mit/config/site.def file. I use xmkmf to create makefiles for all the software that comes over on comp.sources.x (including my own 8-) and it works perfectly. Richard
crouch@crunchie.axion.bt.co.uk (Chris Rouch) (07/18/90)
In article <2767@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: |> From article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, by montnaro@milkweed.crd.ge.com (Skip Montanaro): |> > |> > How about getting rid of Imake and using GNU make instead for R5? I've never |> > gotten Imake to work properly, and always wind up translating Imakefiles |> > into GNUmakefiles. |> |> Ahh .... no. Please don't. Imake is wonderful. It would, though, |> be nice if there were more documentation about how to overcome some |> of the more common errors likely to crop up during the configuration |> process (e.g., your Makefile gets hosed). Or more comments in the |> configuration files. Sometimes they're mighty cryptic. |> |> Or is it just me? I really like imake a lot, but found I have to invest |> quite a bit of time trying to understand it before I was able to take |> it and use it for my own projects. Is this unusual? |> I agree. It takes a fair bit of effort to sus imake out, but once done I found it relatively simple to create new Imakefiles for my own stuff. I would like to see more *well commented* examples, to take some of the trial and error out. But improve it, don't scrap it. Chris ----------------------------------------------------------------------------- Chris Rouch crouch@axion.bt.co.uk RT3131, BTRL, Martlesham Heath, Ipswich, England. +44 473 646093 We came, we saw, we lost on penalties.
dce@smsc.sony.com (David Elliott) (07/18/90)
In article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, montnaro@milkweed.crd.ge.com (Skip Montanaro) writes: |> |> How about getting rid of Imake and using GNU make instead for R5? I've never |> gotten Imake to work properly, and always wind up translating Imakefiles |> into GNUmakefiles. Maybe you should describe the problems so that we can work to fix them. I have used imake with various versions of System V and BSD imake without any problems. The few times I have used it with GNU make, I had problems and ended up going back to System V make, so as far as I can see, the problem isn't with imake. The biggest problem with imake seems to be that people don't take the time to learn it. It's actually very well-designed and works great when people use it. In the case of X, the folks at MIT have done a good job of keeping the X Imakefiles up to date, so there are lots of reasonable examples to look at. The only real objection I can see with going with GNU make is that it's not as freely-distributable as X is (did I get it right this time, Joe? ;-). Also, will GNU make handle the same problems as imake does? (The person that put gnu-make on our system doesn't believe in making man pages available #$@%!) I like being able to take a program from the net and build it on both BSD (without the X source tree) and System V.4 (with the X source tree) and have things build first time. ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."Damn! I'm running out of integers!"
bin@primate.wisc.edu (Brain in Neutral) (07/18/90)
From article <5130@harrier.ukc.ac.uk>, by rlh2@ukc.ac.uk (Richard Hesketh): > The normal installation process places a copy of all the configuration > files needed by imake into the lib directory that has been specified in the > mit/config/site.def file. ??? site.def in my distribution doesn't specify anything of the sort. It's ConfigDir in Imake.tmpl. It can be overridden in site.def, but that may be a local modification at your site. Paul DuBois dubois@primate.wisc.edu
marcs@servio.UUCP (Marc San Soucie) (07/19/90)
Paul DuBois writes: > Skip Montanaro writes: > > How about getting rid of Imake and using GNU make instead for R5? I've never > > gotten Imake to work properly, and always wind up translating Imakefiles > > into GNUmakefiles. > > Ahh .... no. Please don't. Imake is wonderful. It would, though, > be nice if there were more documentation about how to overcome some > of the more common errors likely to crop up during the configuration > process (e.g., your Makefile gets hosed). Or more comments in the > configuration files. Sometimes they're mighty cryptic. > > Or is it just me? I really like imake a lot, but found I have to invest > quite a bit of time trying to understand it before I was able to take > it and use it for my own projects. Is this unusual? Far from unusual. It appears to be policy. With all due respect to its author and the context in which it was developed, 'imake' is still a very rough prototype of the tool that it wants to become, and is rather hideously documented to boot. To my mind, there is nothing more aggravating than unbundling a 'shar' archive from comp.sources.x and receiving along with the sources a lone 'Imakefile' for building the thing. Like, so what? Sure, I can mess around with the 'config' directory from my fortunately still available R4 distribution tree. Sure, I can pull down a copy of imake and Imake.tmpl and site.def and Xxx.cf. Sure, I can poke through the source in imake.c and discover that I have to use some whammo options in order to get the thing to find Imake.tmpl in the first place. Sure, I can spend 45 minutes doing what a makefile would have done in 1/10 second. The problem with imake is that it doesn't make the problem simpler. It just solves the problem. It's like doing quadratic polynomial expansions on a $3.95 K-Mart calculator, when a more elegant higher-order solution would take less time and aggravation. How about rethinking the manner in which imake or its eventual replacement (you folks can't really believe someone won't come up with something more elegant eventually) presents itself. A more obviously target-oriented syntax, for instance. Cleaner delineations of the system-depdendent and independent keyword areas. Documentation that explains, rather than presents. As someone said, it's all well and good that so many of us learn all these cosmic techniques for making software, but imake is one that doesn't pay much back for the time invested. Marc San Soucie Portland, Oregon marcs@slc.com P.S. Anybody care to fork me a copy of the GNUmake man page? Do I have to write Lisp to run it? Is it going to take fourteen minutes to load itself from a cascading hierarchy of directories full of obscure command files?
montnaro@spyder.crd.ge.com (Skip Montanaro) (07/19/90)
Thanks to Bill Kucharski (kucharsk@solbourne.com) for straightening me out on Imake. I had given up on R3 Imake, and never went back to try it (at least not in conjunction with xmkmf) under R4. I retract my wish for Imake to be replaced by GNU make in the X distribution. -- Skip (montanaro@crdgw1.ge.com)
jwright@cfht.hawaii.edu (Jim Wright) (07/19/90)
dce@smsc.sony.com (David Elliott) writes: >The biggest problem with imake seems to be that people don't take the >time to learn it. As far as I can tell, imake is not distributed by our vendor (HP). Our other vendor didn't even give us X11 (Sun). We had to ftp everything from MIT. I have never found any documentation. I was lucky enough to stumble upon something that usually works. Often I get the message "can't find imake.template". What's wrong with imake.tmpl? X11R3 on HP/UX 7.0 X11R3 & X11R4 on SunOS 3.?, 4.0.3 & 4.1 -- Jim Wright jwright@quonset.cfht.hawaii.edu Canada-France-Hawaii Telescope Corp.
bin@primate.wisc.edu (Brain in Neutral) (07/19/90)
From article <jwright.648365808@quonset>, by jwright@cfht.hawaii.edu (Jim Wright): > As far as I can tell, imake is not distributed by our vendor (HP). > Our other vendor didn't even give us X11 (Sun). We had to ftp > everything from MIT. I have never found any documentation. I was If you ftp'd everything from MIT you should have gotten the mit/config/README file, and the source for "Configuration Management in the X Window System" (by Jim Fulton), at least. The former must be read to be able to actually use the stuff, the latter is an overview of the goals that MIT was trying to accomplish with imake. It's also a must-read, though for different reasons. There is also the imake man page source in mit/config/imake.man. > lucky enough to stumble upon something that usually works. Often > I get the message "can't find imake.template". What's wrong with > imake.tmpl? This sounds like a mismatch between R3 tools and R4 tools. imake.template is used in R3, Imake.tmpl in R4, I believe. The difference in structure of the configuration files between the two versions is significant, the latter being much more highly developed and configurable than the former. Paul DuBois dubois@primate.wisc.edu
don@zardoz.coral.COM (Don Dewar) (07/19/90)
) ) In article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, ) montnaro@milkweed.crd.ge.com (Skip Montanaro) writes: ) |> ) |> How about getting rid of Imake and using GNU make instead for R5? I've never ) |> gotten Imake to work properly, and always wind up translating Imakefiles ) |> into GNUmakefiles. ) ) Maybe you should describe the problems so that we can work to fix them. ) ) ... ) ) The biggest problem with imake seems to be that people don't take the ) time to learn it. It's actually very well-designed and works great ) when people use it. In the case of X, the folks at MIT have done a ) good job of keeping the X Imakefiles up to date, so there are lots of ) reasonable examples to look at. . . The only problem with learning imake is that no one can find any documentation. No matter how many examples exist, no one could possibly figure out every feature from them. In addition, some people don't have all day to try to fetter out the mysteries of imake. Many people have reqested imake documentation, but I have never seen an answer posted. If you want to spread the use of imake, some documentation is what you need. ) The only real objection I can see with going with GNU make is that it's ) not as freely-distributable as X is (did I get it right this time, Joe? ;-). ) I did not know that anything GNU was not freely distributable. Is this true? Or are you referring to the few conditions that come along with the right to distribute. +---------+ | Coral | |@@@@@*@**| |@@*@@**@@| Don Dewar |*@@**@@@@| Coral Network Corporation, Marlborough, MA |@***@@@@@| Internet: don@coral.com |@@**@@@@@| Phone: (508) 460-6010 |*********| Fax: (508) 481-6258 |Networks | +---------+
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/20/90)
Many people have reqested imake documentation, but I have never seen an
answer posted.
I've seen several answers posted by people: mit/config/README,
mit/config/imake.man, mit/doc/config/usenixws/paper.ms, mit/RELNOTES.ms.
It may well be that the documentation is insufficient. Several
people have indicated that they have slogged through imake and
now understand it. Perhaps they'd be willing to contribute
some documentation ...
I did not know that anything GNU was not freely distributable. Is
this true? Or are you referring to the few conditions that come along
with the right to distribute.
The conditions attached to FSF source are unacceptable to us for
inclusion in an X distribution.datri@convex.com (Anthony A. Datri) (07/20/90)
>I use xmkmf to create makefiles for all the software that comes over on >comp.sources.x (including my own 8-) and it works perfectly. I use xmkmf with great success as well. The biggest problem I have is when authors embed silly directories, like FREDSLIBDIR = "/usr/barney/willy/SoMeLiBdIr" --
meo@rsiatl.UUCP (Miles ONeal) (07/21/90)
jf@ap.co.umist.ac.uk (John Forrest) writes: |If you have never got Imake to work that is your problem, because I |would expect that almost everyone else has. Imake is indespensible for |handling different compilers and operating systems - we usually get out |X source after it has been on a Sun system in the next building, and |about all you can do with the Makefiles from there is "make Makefiles". |The difference between their gcc orientated makefiles and our Apollo cc |ones is considerable. I hope nobody takes this suggestion seriously. Actually, there are alternatives - I just don't like them as well. I have written portable, easily-configurable Makefiles in the past- but to REALLY make life easy, you need certain standard conventions as to where things are (just like Imake, hmmm), and it helps a LOT to have standard environment variables and a few shell scripts for login, setup, etc. OSF has a "build" environment, which depends even MORE heavily on file tree layouts, environement variables, and such. It's also even more "magical" in how it works than imake (although there is supposed to be doc, now, at last). Net result - I haven't seen anything freely available that's better than Imake. Kind of like X - it's not perfect, and sometimes it drives me up the wall, but it's heads and shoulders above anything else I've seen. -Miles
mbl@lri.lri.fr (Lafon) (07/27/90)
We have developped two generations of graphical libraries on top of several window systems, including X10 and X11. These libraries have been used in various applications (iconic shell, animation, drawing tool, interface builder). So based on this experience, here is our wish list for R5 : - outline fonts (already asked for) - downloadable fonts (already asked for) - load pixmaps by name - support for input devices and hard cursors - regions in the server - 'translucence' value in the GC - load pixmaps by name Downloading huge pixmaps (eg. root background) over the connection is slow. Creating a pixmap from a name as this is done now for fonts avoids this (with a pixmap path similar to the font path). Combined with downloadable fonts, this makes a complete set of primitives: dowload font / pixmap load font / pixmap by name - support for input devices and hard cursors: This is already more or less in the 'input extension'. However it lacks support for cursor tracking: if I have a tablet whose focus is a window, I'd like the server to maintain a cursor for it. Doing this in the client is expensive and cannot be transparent to the application, unless overlay planes are supported. On the other hand, it looks quite easy to have multiple cursors in the server. Furthermore, it would be great to have several hard cursor feedback types in the server, like rubber-band/rubber-box/cross-hair etc. Lots of clients track mouse moves only for dragging around a rectangle. Semantically, a rubber-band is very similar to a cursor pattern, and thus should be available at the very low level of the graphics system. Moreover, some machines have hardware support for such things. - regions in the server: Regions are currently managed inside Xlib. With regions in the server, we could have a much nicer handling of expose events: only one expose event would be sent, with a rectangle corresponding to the bounding rectangle of the region, and the region ID of the actual region to repaint (that regin would be in the server). The client can retrieve the region by a request to the server. More likely, it will set that region ID in the GC and will start redrawing. Today, the client has to get a bunch of expose events, build the region, set the GC clip member to it, and then redraw. This involves two passing of the region (server->client in the expose events, and client->server in the GC). Moreover, if the client uses several GC's, it has to set the clip region as many times. An alternative would be to have a clip region by window (in addition to the clip region of the GC). In a graphic library we are developping, we have found by profiling that having the clip region in the GC and repeatedly transferring it over the net was the major performance flaw. - 'translucence' value in the GC: Drawing with a non opaque color on a drawable requires a lot of traffic between a client and a server. Typically, it requires the client to keep a copy of the lookup table, and all the calculations of the color values should be done in the application. This would be much easier to do inside the server. A 'translucence' field in the GC (varying from 0 to 1) would enable this: Drawing over a drawable would result in averaging the RGB values of the painted bits, the averaging being weighted by the value of the 'translucence'. - As a last goodie, we'd like the CopyPlane primitive to take a bitmap mask (this did exist in X10, and was invaluable for drawing icons). Drawing an icon properly in X11 involves 3 Copy operations! We also miss the transparent windows of X10 (versus input-only windows in X11). ___ 0 Michel Beaudouin-Lafon uucp : mbl@lri.lri.fr / \ / LRI - Bat 490 bitnet: mbl@FRLRI61.bitnet / __/ / Universite de Paris-Sud voice : +33 (1) 69 41 69 10 /__ \/ F-91405 ORSAY Cedex +33 (1) 69 41 66 29
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (07/28/90)
The R5 Xtoolkit should give warnings when an invalid resource is accessed. I don't care about the IMPLEMENTATION issues involved in doing this. From a PROGRAMMERS PERSPECTIVE, it is completely unreasonable for a widget to remain silent when you set the wrong resource (either at creation time, or during XtSetValues())... It is similarly unreasonable to not give errors upon XtGetValues() of an invalid resource. From an END-USERS PERSPECTIVE, it is unreasonable for no errors to be reported when a user sets the wrong resource in an .Xdefaults, app-default or xrdb file. How many times have you had to deal with a clueless user who claims your program is buggy because they mispelled a resource name and therefore the program didn't work right? I know about the IMPLEMENTATION issues involved in doing such error reporting. How many end-users want to have the internals of the Xtoolkit and X resources mechanisms explained to them in response to the problems outlined above? User: "there's a problem with ... the patient died" Programmer: "bla bla constraint resource bla bla subclassing quack quack quack 'foo*resname' bla bla resource classes bla bla very flexible bla bla bla quack quack quack..." User: "Oh, now I see, well, then I guess its ok" ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
rlh2@ukc.ac.uk (Richard Hesketh) (07/28/90)
In article <5677@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > >The R5 Xtoolkit should give warnings when an invalid resource is accessed. > While we are on the subject of warning generation in Xt; I would very much like to see atleast one error message to be changed to a warning message instead (and thus not causing the application to die). The error I am thinking of is ... "Widget blah has zero width and/or height" This hurts my user interface builder; when a widget is to be created and does not calculate a default window size, I would like to be graciously informed of this via a Warning which I can ignore (I don't mind if the window is given a 1x1 size). I just don't want my builder falling over from a silly Error that can be dealt with simply. The hand-waving and arm bending I have to do to stop this Error and yet still allow widgets to calculate their own default sizes is nasty. Thanks for listening, I'll get back to my documentation (yuk) now 8-). Richard
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (07/29/90)
In article <5196@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >While we are on the subject of warning generation in Xt; I would very >much like to see atleast one error message to be changed to a warning message >instead (and thus not causing the application to die). >The error I am thinking of is ... > > "Widget blah has zero width and/or height" > >This hurts my user interface builder; when a widget is to be created and >does not calculate a default window size, I would like to be graciously >informed of this via a Warning which I can ignore (I don't mind if the window >is given a 1x1 size). I just don't want my builder falling over from a >silly Error that can be dealt with simply. Here's how I handle "overriding" Xt warnings in WINTERP. In WINTERP Xtoolkit warnings & fatal errors don't cause the program to exit; rather it returns control to the interpreter's debugging loop (by calling xlfail()) so you can figure out and fix what when wrong and then continue on with programming. From winterp/src-server/winterp.c: ------------------------------------------------------------------------------ main(...) { ... /* * Setup Xtoolkit warning and error handlers so that errors inside * the Xtoolkit will call xlerror(). */ XtSetErrorHandler(Winterp_Xtoolkit_Error_Handler); XtSetWarningHandler(Winterp_Xtoolkit_Warning_Handler); ... } /******************************************************************************* * This handles fatal errors from the Xtoolkit. According to the Xtoolkit * docs, such a handler should terminate the application. In this case, * however, we suggest to the user that the application be terminated, but * don't actually do it. This may allow the user to figure out what went * wrong by poking around inside the lisp environment. * * This is set up in main() via XtSetErrorHandler(). Note that the default * error handler is _XtDefaultError(). ******************************************************************************/ static XtErrorMsgHandler Winterp_Xtoolkit_Error_Handler(message) String message; { sprintf(temptext, "X Toolkit Fatal Error -- PLEASE QUIT AND RESTART THIS APPLICATION -- %s\n", message); xlfail(temptext); } /******************************************************************************* * This handles nonfatal errors from the Xtoolkit. * * This is set up in main() via XtSetWarningHandler(). Note that the default * error handler is _XtDefaultWarning(). ******************************************************************************/ static XtErrorMsgHandler Winterp_Xtoolkit_Warning_Handler(message) String message; { sprintf(temptext, "X Toolkit Warning: %s\n", message); xlfail(temptext); } ------------------------------------------------------------------------------ PS: One WINTERP improvement I want to add is to override X protocol errors Is this possible? Is this safe to do?? I need to RTFM on this before I decide to add such a feature to WINTERP, and do it in my copious spare time. Why do I want this... well, for example, doing (send widget :unmap) on an unrealized widget exits WINTERP and generates the annoying message > X Protocol error detected by server: not a valid window ID > Failed request major op code 10 (X_UnmapWindow) > Failed request minor op code 0 (if applicable) > ResourceID 0x0 in failed request (if applicable) > Serial number of failed request 2103 > Current serial number in output stream 2104 And I'd much rather just fix the code and re-interpret it rather than have to restart WINTERP. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
mouse@LARRY.MCRCIM.MCGILL.EDU (07/29/90)
> The R5 Xtoolkit should give warnings when an invalid resource is > accessed. > From an END-USER[']S PERSPECTIVE, it is unreasonable for no errors to > be reported when a user sets the wrong resource in an .Xdefaults, > app-default or xrdb file. Unfortunately for your position, it is impossible to fix. Your argument actually supports a different interface for end-users to use for customizing programs. The major problem with this sort of reporting is that *the widget doesn't know* what resources are valid. A window manager may well look for resources that the widget has never heard of, to pick one simple example. (I do agree that a different interface is needed. Editing .Xdefaults files is an inappropriate way for computer-naive users to customize programs, fine though it may be for programmer types.) (I can't comment about your PROGRAMMERS[sic] PERSPECTIVE, because I don't know the semantics of the routines you name, so I can't guess whether similar problems apply.) > User: "there's a problem with ... the patient died" > Programmer: "bla bla constraint resource bla [...]..." Try instead Programmer: "You used a tool without understanding it, and you accidentally misused it. What's the problem?" I'm entirely serious. Nobody should use a tool without understanding it unless they are prepared to accept the results of its malfunctioning due to that lack of understanding. (This applies to power saws, cars, and scalpels just as much as computers.) In most circumstances, the potential results of possible misuse of computers are limited to things like loss of time and waste of paper. Cars, for example. People are killed by the thousands on the highways due to lack of understanding of their cars. But nobody considers this as due to a lack of user-friendliness by the cars. Instead, those who drive consider the risk acceptable (or I assume they do; with the news of accidents always present, they can hardly be unaware of the risk.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rlh2@ukc.ac.uk (Richard Hesketh) (07/29/90)
In article <5679@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: >In article <5196@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh), I write: >>While we are on the subject of warning generation in Xt; I would very >>much like to see atleast one error message to be changed to a warning message >>instead (and thus not causing the application to die). >Here's how I handle "overriding" Xt warnings in WINTERP. In WINTERP >Xtoolkit warnings & fatal errors don't cause the program to exit; rather it >returns control to the interpreter's debugging loop (by calling xlfail()) >so you can figure out and fix what when wrong and then continue on with >programming. > XtSetErrorHandler(Winterp_Xtoolkit_Error_Handler); > XtSetWarningHandler(Winterp_Xtoolkit_Warning_Handler); I already have an error widget which does this for me, it intercepts and displays both Xt Warning and Xlib Protocol errors in a suitable scrolling text widget with clear and hide buttons. It can also popup and beep at me 8-). > * This handles fatal errors from the Xtoolkit. According to the Xtoolkit > * docs, such a handler should terminate the application. I would very much rather like to follow the spec. on this one and let the application die, as I have *no control* over what the Intrinsics are doing, (i.e. fiddling with memory and pointers). However on further investigation I see that the one error I don't like could be handled with the *current* implementation of the Intrinsics by replacing the XtCreateWindow() routine with one that causes the window to inherit its parents dimensions. >PS: One WINTERP improvement I want to add is to override X protocol errors >Is this possible? Is this safe to do?? I need to RTFM on this before I >decide to add such a feature to WINTERP, and do it in my copious spare >time. This is very easy via the use of XSetErrorHandler() which is better than the Xt Warning equivalent. You can capture all the BadWindow, BadMatch etc. errors and cope with them. In R4 this function now returns the previous error handler (my one claim to fame 8-) so that you can quickly set and unset error handlers and thus enable "wrappers" to be placed around X requests. The handler is passed the display and a pointer to an XErrorEvent structure which describes the error in enough detail to be able to recover from it (i.e. type of request and type of error; XCreateWindow & BadMatch). Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682
wf08+@ANDREW.CMU.EDU (William Frank) (07/31/90)
> Excerpts from mail: 13-Jul-90 Re: R5 wishlist Bob Scheifler@expo.lcs.m > (417) > All I want for R5 is for the server to pass on expose events to > clients > that have backing store on, if the event was sent with SendEvent. > There's no reason why it shouldn't today. Perhaps you could elaborate > on what exactly you are doing (what mask you are passing to XSendEvent, > what mask the client has selected with) so that someone could understand > where the problem is. Perhaps you are just confused. Sorry that I am responding so late. Yes, I was very confused. I stupidly made the assumption that window managers and xrefresh used XSendEvent on all the visible windows. Unfortunately, this is not the case. So, I've rewritten xrefresh to do this. Of course, I had to keep around the previous method it used to redraw the screen, to deal with programs that throw away Send Events (such as xterm). After about a week or two of testing I hope to post a patch. Thanks for your help. -William Frank
mikeo@sae.UUCP (Michael Ovington) (08/04/90)
From the frequently asked questions list: >... writing a generic String to Pixmap converter is impossible, since >there is no accepted convention for a file format for pixmaps. Therefore, >neither the X Toolkit or the Athena widget set define a String to Pixmap >converter; because there is no converter you cannot specify this value as a >resource. I would R5 to include a 'blessed' pixmap format so that you can: 1. use pixmaps in resources specifications. 2. use pixmaps portably without having to port a bunch of pixmap loading code as we move an application from machine to machine. I don't care which format is chosen (gif, xpm, tiff, xwd etc. There are LOTS out there.), but standardizing on one will make it much easier for application builders to include color and greyscale images in their applications. Ideally, dithering (for monochrome) and colormap compression (for displays that can't display as many colors as the image contains) should be supported, but if the core distribution supports loading the pixmap and providing colormap information, the rest can be done at the widget/application level. ________________________________________________________________________________ Michael S. Ovington Software A&E (703) 276-7910 1600 Wilson Blvd, Suite 500 uunet!sae!mikeo Arlington, VA 22209 mikeo@sae.com ________________________________________________________________________________
roger@hpnmdla.HP.COM (Roger Petersen) (08/07/90)
In comp.windows.x, mikeo@sae.UUCP (Michael Ovington) writes: > I don't care which format is chosen (gif, xpm, tiff, xwd etc. There are > LOTS out there.), but standardizing on one will make it much easier for > application builders to include color and greyscale images in their > applications. The "cool" thing about TIFF is that it isn't a single standard... it's a whole bunch of unknown "standards" wrapped up under one name. Aaack! If you want standard, don't pick TIFF. -------------------------------------------- By the way, don't you want/need a format that has a convenient ASCII representation (ala bitmap format)? Roger
rick@pcrat.uucp (Rick Richardson) (08/10/90)
The call for features in R5 has been put out. We're stuck running
R3 here, so based on that I'll put in my two cents. You'll find
that my opinions stem from a developers creature-comforts standpoint,
rather than trying to invent an earth-shattering-new-feature.
- Everything we do involves images in some form or another.
Anything that speeds up handling of images, or makes it
simpler to use them is welcome.
- Despite the warts and all of TIFF, I think that the
fact that it is extensible (which can also be considered
a wart) makes it the format of choice. The availablity
and quality of Sam Leffler's PD TIFF library is a
compelling reason to choose TIFF as the native image
format for X. A merging of Jef Poskanzer's excellent
image processing algorithms from PBM, combined with
Sam's TIFF library, and command line/batch language/
library call capability to do multiple image processing
steps within the same program (avoiding the overhead of
pipe communication for large images) would go a long way
towards making this a useful standard.
- I realize there is some discussion concerning bitmaps
going on. In my experience, it is sometimes useful
to put an image into bitmap (Pixmap) format. Unfortunately,
as near as I can tell, Pixmap's (unlike XImage's) do not
allow image bit/byte ordering to be specified to conform
to the typical msb-first image representation, so you
have to ram an image in msb-first format through a mirroring
loop (data[y][x] = mirror[data[y][x]]).
- It is doubtful that there will ever be a binary standard
for Xlib and Xt shared libraries under SVR3.2 or even SVR4
in the 386/486 marketplace. For this reason, software
developers will be forced into producing platform specific
binaries compiled against shared libraries from each of the
'major' UNIX/X11 vendors, plus a non-shared (cover-your-ass)
version for the johnny-come-lately UNIX vendors, if they
want to reach the widest possible audience. For this reason,
anything that reduces the size of a program using Xlib and
Xt will be welcome. This goes double for Xm, should any
OSF people read this.
- The X resource manager *could* be useful as a generic
method for specifying user preferences for *all* UNIX
programs (as opposed to environment variables and/or
program defined 'config' files). Some consideration
should be made for making it separate and able to stand
on its own (perhaps it already can; I haven't tried this).
- One of the reasons (I suspect) that we are running X3 is
that vendors have a significant investment in stablizing
the server/library products they sell. On top of that,
I think because Motif required Xt changes in R3, vendors
stayed with R3 rather than rock the boat. I'd like to
see R5 released with a stability/confidence level such
that vendors will beat a path to its door. Coordination
with the OSF is imperative, and I'm happy to see that
this is now occurring.*
And now, what you've all been waiting for (drum roll, please):
Obligatory-long-posting-humorous-but-irrelavant-ending-comment:
One has to wonder, given the acceptance of OSF's Motif,
and the lack of acceptance of OSF/1, if the OSF should
be called the Look And Feel Foundation. And, shouldn't
UNIX International be renamed to the Foundation for UNIX
Nurturing?
That would be FUN and LAFFs. (Groan)
-Rick
--
Rick Richardson - PC Research, Inc., uunet!pcrat!rick, (201) 389-8963markham@cadence.cadence.com (Jeff Markham) (09/11/90)
I've been meaning to answer this request for a while ..
and I hope its not too late :
What I think would be good in R5
1). Paul Jensen (of Digital Equipment) has drafted a
protocol extension proposal which he has called
the WormHole extension. Apart from the cool name,
it sets forth a series of protocol extensions that
are designed to take advantage of new "smart" framebuffers
being offered by DEC and Sun (not jointly of course).
The part that appeals to me the most is the ability to
send multiple (simple) polygons in one protocol request.
I don't know if anyone else is having performance problems
with XFillPolygon .. but we sure are. Another neat thing
it provides for is to send the foreground color along with
the shape. I appeal to each of you to support this
protocol extension and help it get into R5 .. 'cause its
a good one.
2). Another good thing to look at would be adding some policies
to the ICCCM about how selections and selection formats
get handled. Specifically, it would be great if there were
a bank of format converters registered that an application
could call in order so that it could accept a selection. An
example would be .. some application posts a selection in format
"X Window Dump" .. and another application can only accept
PostScript(tm) ... If that application could request a conversion
service to invoke the appropriate converter .. then life would
be alot easier for application writers. I think all the sub
systems are in place to support something like this .. certainly
the ICCCM is specific about posting selections with a format
atom.
That's my two cents worth,
Thanks,
Jeff Markham
markham@cadence.comdlc@c3.lanl.gov (Dale Carstensen) (03/16/91)
|> In article <19910301203957.6.BARMAR@OCCAM.THINK.COM> barmar@think.COM (Barry Margolin) writes: |> |> > I'd |> > like to be able to move my X clients from one display to another (for |> > instance, if I had a home X terminal I'd want to bring my windows home |> > with me), or reboot my workstation without having to kill all the remote |> > X clients (saving local clients across reboots is outside the scope of |> > X). X clients communicate with their server via a "display" abstract |> > data type; this object hides the details of the communication protocol, |> > allowing the same clients to work over TCP, DECnet, shared memory, etc. |> > Thus, it should be possible for them to disconnect themselves from the |> > transport mechanism completely, and later open a new transport |> > connection and use that. I started a short discussion on "client recovery" a few months ago that was a more limited version of this capability. This sounds even better to me. Will it be done?
dvb@emisle.uucp (David Van Beveren) (03/18/91)
In article <17895@lanl.gov> dlc@c3.lanl.gov (Dale Carstensen) writes: > >|> In article <19910301203957.6.BARMAR@OCCAM.THINK.COM> barmar@think.COM (Barry Margolin) writes: >|> >|> > I'd >|> > like to be able to move my X clients from one display to another (for >|> > instance, if I had a home X terminal I'd want to bring my windows home >|> > with me), or reboot my workstation without having to kill all the remote >|> > X clients (saving local clients across reboots is outside the scope of >|> > X). X clients communicate with their server via a "display" abstract >|> > data type; this object hides the details of the communication protocol, >|> > allowing the same clients to work over TCP, DECnet, shared memory, etc. >|> > Thus, it should be possible for them to disconnect themselves from the >|> > transport mechanism completely, and later open a new transport >|> > connection and use that. How about the ability to move widgets from one display to another. This would imply that all descendants would be moved as well. Obviously right now I could destroy a widget, and create a new one under a different context which is on a different display, but re-parenting an existing widget to a context on a different display would be nicer. An example of a use of this: I have an X program which is a server for a graphics engine. Only one client can have the server at as time. When a client's request for service is acknowledged (communication is via sockets), a blank graphics palatte is drawn on the client's display, which was passed as part of the request. The server maintains a cache of open displays. If a display not in the cache is requested, an XOpenDisplay occurs, and an application context is created for that display. Now, Currently I have to destroy the palette on the last used display, and create a new one on the new display. If I could move the palette instead, things would be simpler. (The palette is a set of sliders, scrollbars, menus, etc around a drawing area. It contains about 30 widgets altogether.) The ability to move windows from one display to another could also be useful in some situations. -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247
scottm@spiderman.spider.co.uk (Scott Mackie) (03/18/91)
In article <1991Mar17.234456.456@emisle.uucp>, dvb@emisle.uucp (David Van Beveren) writes: |> In article <17895@lanl.gov> dlc@c3.lanl.gov (Dale Carstensen) writes: |> > |> >|> In article <19910301203957.6.BARMAR@OCCAM.THINK.COM> barmar@think.COM (Barry Margolin) writes: |> >|> |> >|> > I'd |> >|> > like to be able to move my X clients from one display to another (for |> >|> > instance, if I had a home X terminal I'd want to bring my windows home |> >|> > with me), or reboot my workstation without having to kill all the remote |> >|> > X clients (saving local clients across reboots is outside the scope of |> >|> > X). X clients communicate with their server via a "display" abstract |> >|> > data type; this object hides the details of the communication protocol, |> >|> > allowing the same clients to work over TCP, DECnet, shared memory, etc. |> >|> > Thus, it should be possible for them to disconnect themselves from the |> >|> > transport mechanism completely, and later open a new transport |> >|> > connection and use that. |> |> |> The ability to move windows from one display to another could also be useful |> in some situations. Certainly! ;-) This is one of the areas where X has been deficient for a while. A fairly useful application of this would be much as Barry Margolin describes. To be able to iconify down your entire list of active clients and redirect them to another X display would be a real boon to distributed working. Changing between X displays is something I do quite a lot even within the office and it's a real pain having to close everything down and start it all up again. On a slightly different thread, being able to iconify all your clients into one icon and lock that icon's uniconify action would be fairly cool too. Locking a display up with xlock has always been a fairly antisocial (IMHO ;-) thing to do, but being able to kick back to the xdm propmt to allow other people to use the workstation (while still having the locked icon somewhere on the screen) is a bit more friendly..... Any comments? Scott.......... -- Spider Systems Ltd Net: scottm@spider.co.uk Spider Park, Stanwell Street YellNet: +44 31 554 9424 Edinburgh, Scotland #include <disclaimer.h>