naughton@sun.soe.clarkson.EDU.UUCP (11/19/87)
Is there any way to find out when the next versions of the X.V11 tools will
be released? I am anxiously awaiting all of the "neat and nifty" things
from X.10 to surface under V11. e.g. TitleBars, the scrolling xterm icon,
the C shell (sea shell?) icon, etc... etc...
----------------------------
Also has anyone written a bitmap editor a la MacPaint? If they have, I
would like to get it from them; if they haven't I will write one. I have
written several "paint" packages for PC's and think it would be great to
have one under X, but I don't want to start it if it already exists...
I HAVE, however, written a simple program to load Macintosh MacPaint files,
("READMACS" in the PC parlance) and put them in a window... It's pretty neat.
That is... if you like scantily clad women peeking out at you from
behind your xterm widow. (or popping off of your laser printer: It
has a postScript option...)
It has been a hit here at Clarkson, so if the interest is there, I can
send it to xpert or get an anonymous ftp set up here... I have several
Meg of images on-line so ftp would probably be best... We are always
looking for new images so if we get the ftp set up, feel free to "mput *.mac"
those images to us...
----------------------------
Does anyone have a dialog manager done for X11? Basically, more
Mac-Like stuff; Puts up the list of available files, and allows
user to type filename or click on it and page through subdirs, or
click on cancel... etc... (another thing I'll write if it doesn't already
exist)
----------------------------
I have several other project going on, if anyone is an eXpert on them,
let me know...
3D fluid modeling...
Gauraud / Phong Shading...
Contour plotting...
----------------------------
Patrick J. Naughton
23 Pleasant Street, #3
Potsdam, NY 13676
(315) 265-2853
naughton@sun.soe.clarkson.edu
Clarkson Universityswick@ATHENA.MIT.EDU (Ralph R. Swick) (11/20/87)
New/improved versions of X11 tools will make it onto the release tape as we have time, or as other in the X community contribute them to us. At the moment, we are concentrating on real bugfixes (and Xtoolkit) and unfortunately don't have much time left for nifty functional additions. BTW, there is a public-writeable directory 'contrib' on zap.mit.edu where anyone may deposit materials. If you want to contribute something new to the next release, putting it here is one of the more effective means to get it to us. Copyright notices (if any) must be equivalent to the MIT copyright notice for us to place it on the tape. -Ralph
garyo@prometheus.think.com (Gary Oberbrunner) (03/21/89)
I have two questions:
I am running X11R3 with no patches on a color Sun 4/110 OS 4.0 with uwm.
(1) The buttons in the athena Dialog widget are *unbelievably* slow.
Highlighting and de-highlighting are the most noticeably bad, but
refreshing is also a killer. When I expose my 5 x-postit windows, for
instance, they take about 15 seconds to redraw (during which the server
response is nil). Is this normal?
This does not happen on Sun-3s.
Here's a small code sample I snarfed off the net today that demonstrates
the same behavior.
The buttons take ages to refresh and forever to highlight.
Button-press highlighting in the buttons seems to be quick, however.
------------------------------------------------------------
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Dialog.h>
void
main(argc,argv)
char ** argv;
int argc;
{
Widget top, dia;
Arg a[1];
XtSetArg (a[0], XtNvalue, "foo bar baz");
top = XtInitialize ("", "test", (XrmOptionDescRec *)NULL, 0, &argc, argv);
dia = XtCreateManagedWidget ("dialog", dialogWidgetClass, top,
(ArgList) a, (Cardinal) 1);
XtDialogAddButton(dia, "foo", NULL, NULL);
XtDialogAddButton(dia, "bar", NULL, NULL);
XtRealizeWidget(top);
XtMainLoop();
}
------------------------------------------------------------
When I enter a button, first the top highlight border is drawn, then the
right, then the bottom, then the left border. The whole process takes
about two seconds.
===========================================================================
(2) Twm on my second (color) screen doesn't pass keyboard events to
clients. It gets the keyboard events (I put in printfs), and it sets the
focus to the selected window, but the key events still go to twm!
Any ideas? Tests I should try?
--
As always,
Gary
-----------------------------------------------------------------------------
Remember, Truth is not beauty; Gary Oberbrunner
Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo
Knowledge is not wisdom; Love is not music; garyo@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265geb@amber.uucp (Gary E. Barnes) (03/23/89)
I tried sending this by EMAIL none of the paths on the original message work. The question was: > (1) The buttons in the athena Dialog widget are *unbelievably* slow. > Highlighting and de-highlighting are the most noticeably bad, but > refreshing is also a killer. When I expose my 5 x-postit windows, for > instance, they take about 15 seconds to redraw (during which the server > response is nil). Is this normal? I had the same problem with the X11R3 Command widgets. Here is a DIFF between what was shipped on the R3 tapes and our current versions of lib/Xaw/Command.c. All of the changes except the one with my initials on it are from the MIT folks. My change has been submitted to them but hasn't been blessed as yet; as far as I know. That one line change returns us to the speed of R2. Gary amber 8: diff Command.c ../../lib/Xaw/Command.c.orig 2c2 < static char Xrcsid[] = "$XConsortium: Command.c,v 1.46 88/11/01 16:57:33 swick Exp $"; --- > static char Xrcsid[] = "$XConsortium: Command.c,v 1.45 88/10/19 09:39:35 swick Exp $"; 260c260 < Redisplay(w, event, HighlightRegion(cbw)); --- > Redisplay(w, event, HighlightRegion()); 274c274 < Redisplay(w, event, HighlightRegion(cbw)); --- > Redisplay(w, event, HighlightRegion()); 312,319c312 < if (!ComWset && < (ComWhighlighted || event->xany.type != Expose) && /* This line added < * by GEB 12/14/88; < * This is NOT a < * "blessed" bug fix. < * So your milage may < * vary. */ < ComWhighlightThickness > 0) { --- > if (!ComWset && ComWhighlightThickness > 0) { amber 9:
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (06/02/90)
> 2. The power of X window is "network transparent windowing..." right? Well, that's one of its strengths. > So, I tried like: > xhost doItThere > rsh doItThere "setenv DISPLAY showMeHere; do it" > It was ok, but is this right way? It's not unreasonable. > Then what is difference with rlogging to the other machine and > execute it inside the popped up shell window? The major difference is where it places the load. In my experience...suppose machine A is running the X server and machine B is where I want my shell to be. Way 1 A% xterm -e rlogin B Way 2 A% rsh B xterm -display A:0 (No nitpicking please, those are typed `off the top of my head'.) I find that way 1 puts less of a load on B than 2 does. To be more precise, when B is an overloaded or otherwise slow machine, way 1 produces noticeably better response. If you're using a standard rlogin, way 1 has the disadvantage that the rlogin escape character is active. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dce@smsc.sony.com (David Elliott) (06/03/90)
In article <9006021303.AA04433@shamash.McRCIM.McGill.EDU> mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) writes: >Way 1 A% xterm -e rlogin B >If you're using a standard rlogin, way 1 has the disadvantage that the >rlogin escape character is active. It's only a disadvantage if you don't use the advantages provided you by the system. The command % xterm -e rlogin B -e causes the rlogin escape character to be undefined (or more specifically to be defined as NUL). -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."
kwang@SP1.CSRD.UIUC.EDU (Kwang-Keun Yi) (06/04/90)
thanks! -kwang
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (06/04/90)
>> Way 1 A% xterm -e rlogin B >> If you're using a standard rlogin, way 1 has the disadvantage that >> the rlogin escape character is active. > It's only a disadvantage if you don't use the advantages provided you > by the system. > The command > % xterm -e rlogin B -e > causes the rlogin escape character to be undefined (or more > specifically to be defined as NUL). Defined as NUL is not at all the same thing as undefined. (I modified rlogin so that when -e is given with no character like that it does truly cause it to be undefined. This is what I meant by "standard rlogin": one that has not had something of this sort done to it.) I would be most annoyed if I were using this "escape character undefined" trick and running emacs, and happened to type ^J ^@ ^D and got disconnected abruptly when I thought I was simply setting a mark and deleting the next character. (Well, it wouldn't for me, because my EOF character isn't ^D, but that's not the point.) If machine A is fast enough, I might not even be able to tell what happened, because the connection would be closed, rlogin would die, and the window would go away before I saw the message. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu