HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Help with X(t)GrabPointer()...
From: solomon@pa621a.inland.com (Paul J. Solomon)
Date: 8 Sep 92 13:57:32 CDT
Organization: Inland Steel Company, East Chicago, IN
Nntp-Posting-User: solomon

I need to be able to grab the mouse pointer, click on some element in
my application, and return the widget underneath the cursor.  I am
currently using XGrabPointer() and a loop with XCheckTypedEvent() to
pull out the next ButtonPress. 

I seem to be having problems with the pushbutton itself:  after the
XGrabPointer is called, whenever I then choose a pushbutton widget, either
the button's callback gets called, or the button just stays highlighted
after being clicked on (depending on how I process the events).

Does anyone know of a way to *really* ignore pushbutton widgets during
this grab:  all I'm interested in is which widget I click on...


-paul.
-- 
----------------------------------------------------------------------
| Paul J. Solomon            |  "Consequences, Schmonsequences...    |
| solomon@pa881a.inland.com  |       as long as I'm RICH!!!"         |
| Inland Steel Co.           |             -Daffy Duck               |
----------------------------------------------------------------------
From: hwn@cci.dk (Henrik W. Nielsen)
Newsgroups: comp.windows.x
Subject: X11R5 -- HELP !
Date: 8 Sep 92 11:43:35 GMT
Organization: CCI europe, Research and Development



HELP !!!

I have just compiled X11R5 on my Sun IPC (SunOS 4.1.1) using gcc-2.

It compiles without any errors, but when trying to start X, I get the
following error message:

Getting interface configuration: Operation not supported on socket
sunOpenFrameBuffer: Inappropriate ioctl for device

Fatal server error:
no screens found
XIO:  fatal IO error 32 (Broken pipe) on X server "(null)"
      after 0 requests (0 known processed) with 0 events remaining.
      The connection was probably broken by a server shutdown or KillClient.


It's a standard 8-bit color IPC configuration.

Does anyone know what is wrong ? 

Thanks.

HWN.

------------------------------------------------------------------------------
| Henrik Winther Nielsen                                     CCCCCCC  II     |
| Basic Development                                         CC  CCCC         |
| CCI Europe                   Mail:  hwn@cci.dk            CC CC     II     |
| Oester Parkvej 9             Phone: 86295588 (361)        CC  CCCC  II     |
| DK-8270 Hoejbjerg                                          CCCCCCC  II     |
| Denmark                                                    e u r o p e     | 
------------------------------------------------------------------------------
From: dan@gordian.com (Dan Lambright)
Newsgroups: comp.windows.x
Subject: window setup savers
Date: 10 Sep 92 22:41:25 GMT
Organization: Gordian; Costa Mesa, CA


Alot of times I have different window setups in my workstation for 
different projects- for example I have 3 debugging windows,
3 monitoring windows, and 3 input windows, plus an emacs session
for one application.  Each time I change applications I have
to re-setup all of my windows, which is realy time consuming.

I have heard of "session savers" which save your window configuration
in a file (or even as an icon,) that you can pull up or re-run
whenever you want.  Does anyone out there know of a program
of this type available over the public domain?

Dan Lambright
From: taylor@foraker.tivoli.com (Eric Taylor)
Newsgroups: comp.windows.x
Subject: Re: GIF library
Date: 10 Sep 92 18:59:41 GMT
Organization: TIVOLI Systems, Inc.

xloadimage does a pretty good job of it.
It is public domain.

And, BTW, I thought of one other important thing that
Objective C lacks.  Templates.

I did not respond earlier to your message about
	Obj. C vs. C++

Which did you learn first?

I started with Objective C and pretty much
abandoned it.  I took up C++ a year later and
loved it.

What are your main objections to C++?
Newsgroups: comp.windows.x
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: Getting foreground/background colors of a window.
Organization: McGill Research Centre for Intelligent Machines
Date: Sun, 6 Sep 92 06:59:37 GMT

In article <1992Sep2.132746.26532@enea.se>, mla@enea.se (Mats L|fstr|m) writes:

> For reasons of my own, I want to know the foreground and background
> colors used in a window.  But the window isn't created by my
> application, but rather by any other application.  Is there any way
> of getting this information?

Only by inference, by reading back what's in the window and trying to
figure it out.  One problem is that foreground and background may not
be well-defined; consider a GIF file displayer, for example.  Another
problem is telling the difference; consider an xterm with large
quantities of text displayed reversed - how are you to know which part
of the window is "reverse" and which is "normal"?

It's true that every window has a background of some sort.  But this
can be a pixel value, a pixmap, ParentRelative, or None.  In only one
of these cases is it even conceptually well-defined to ask what the
window's background color is, and in any case, you can't even find out
which alternative is in effect for a given window, never mind telling
what the pixel value is or pixmap contents are.  (Not
non-destructively, that is.  By playing games with obscuring portions
of the window in various ways and other things, you may be able to
deduce some things about the window's background.  All such attempts
suffer from races with the window's application redrawing the window's
contents.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.windows.x
Subject: Re: Server modifications to minimise network traffic
Date: 15 Sep 92 17:20:20 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Sep10.123551.5489@wg.estec.nl>, chris@wg.estec.esa.nl (Milquetoast) writes:

> The scenario we have is a closed network with a number of X terminals
> or workstations used as X terminals, with custom applications being
> run on a number of fileservers.  We need to be able to minimise
> network traffic.  One way that has been suggested of doing this is to
> build the bitmaps into the server and then use calls to the server to
> update the screen, rather than having to transmit the bitmaps.

Not entirely unreasonable.  But note that unless the X terminals have
local permanent storage (eg, disk, EEPROM), you'll still have to load
them over the network at least once.  And if you're going to do that,
you might as well just have a client set its close-down mode to
RetainPermament and then create them as ordinary pixmaps, storing their
IDs in a property on the root (say).  Then run this client at start (or
more generally, whenever the property doesn't exist)....

You could also package all your bitmaps up into a special font, which
shares with the above solution the advantage of requiring no server
changes - it uses existing machinery.

> There would only need to be a limited number of bitmaps and there are
> no restrictions on the amount of memory and cpu power we could use.
> So, my questions:

> 1)	Is this technically possible?

Yes.  You can put anything into the server you like, as long as you
follow the "as if" rule: as long as clients can't tell the difference
between what you do and what another, now-dead, client did, you're
fine.

> 2)	Is it desirable?

If it works, if it's the best solution for your environment...but
first, think about alternatives: you may not have to modify the server.

> 3)	Is there any documentation or books that would point me in the
> 	right direction, or do I have to go straight to the source?

I know of only one book on the subject, the Israel/Fortune book.  It
may or may not be useful for what you're doing.  I would tend to go
straight to the source myself, but that's likely just me.

> 3)	Are there other ways of minimising network traffic that we
> 	should also investigate?

(Didn't we already have question 3?)  I'd need more information.  Do
you want to minimize packets sent?  Bytes sent?  Time spent?  Why?

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Xref: sparky comp.windows.x:16557 comp.human-factors:2190
Newsgroups: comp.windows.x,comp.human-factors
From: ematias@dgp.toronto.edu (Edgar Matias)
Subject: Re: GUIs Considered Harmful
Organization: CSRI, University of Toronto
Date: 11 Sep 92 17:29:26 GMT


In article <1992Sep11.150513.2430@lsl.co.uk>
snail@lsl.co.uk writes:
>Well I won't argue with you since you say you have access to the paper. But I
>do find (have also asked colleagues) it hard to beleive that most people type
>faster with their non-dominant hand than their dominant hand.

Yes, it's not what you would expect.  The difference isn't large but it's
there.  BTW, here's the reference to the paper in question:

Provins, K. A., & Glencross, D. J. (1968).  Handwriting,
typewriting and handedness.  _Quarterly_Journal_of
Experimental_Psychology, 20, 282-320.

Edgar
From: 4carroll_j@spcvxb.spc.edu
Newsgroups: comp.windows.x
Subject: XPolyReg.c question
Date: 11 Sep 92 16:48:35 GMT
Organization: St. Peter's College, US


 Hi,

	I am in the process of compiling the X-Windows distribution, and have  a 
 question  about one of the modules XPolyReg.c. In that module there are two 
 definitions that are causing me some difficulties:
 
 #define LARGE_COORDINATE		1000000
 #define SMALL_COORDINATE		-LARGE_COORDINATE
 
	These two constants are  later  assigned  to  integer  varibles.  On  my 
 system, int's are 16-bit values. These int's exist inside a structure named 
 BRESINFO.  The  compiler complains, and generates a warning that says these 
 values have been truncated. Has anyone else encountered  this  problem?  If 
 so, what action have you taken.
 
 Thanks
 Jim C.
 
Newsgroups: comp.windows.x
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: request for X windows performance report
Date: Mon, 14 Sep 92 21:52:19 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: comp.windows.x, comp.unix.bsd





I am currently working with Xfree86 under 386bsd, writing a driver for
an S3 based card Orchid Farenheit 1280 as part of a performance improvement.

My question is simple where are the performance bottlenecks in X?

Amancio Hasty

Newsgroups: comp.windows.x
From: mahan@TGV.COM (Patrick L. Mahan)
Subject: RE: How do I keep a window at the top level period?
Organization: The Internet
Date: Tue, 8 Sep 1992 16:58:35 GMT

#
#I am using the mwm window manager.  How can I get a particluar window, in this
#case xeyes to always be the top level window, ie never buried?
#
#I am using the following in my Mwm file:
#
## Set to Explicit to determine focus by clicking on the window or border
## Set to Pointer to determine focus based on the location of the pointer
#Mwm*keyboardFocusPolicy: Pointer
#
## Policy when the window with focus is minimized or removed
## if focuspolicy is explicit, set to true to give focus to
## the window with previous focus
#Mwm*autoKeyFocus: True
#
## if focuspolicy is explicit, set to true to give a window focus 
## when it is restored from an icon
#Mwm*deiconifyKeyFocus: True
#
## Set to True to raise a window when it is given focus
## Set to False to keep the stacking order the same when a window is given focus
#Mwm*focusAutoRaise: True
#
## if focuspolicy is explicit, 
## set to true to give input focus to a window when it is mapped
#Mwm*startupKeyfocus: True
#


Well that all helps.  However, to keep Xeyes on top of the window stack will
require you to modify the xeyes code.  What is needed, it a event handler,
watching for CirculateNotify events.  At which, the event handler then forces
the application to the top again.  All of the above resources will only work
once xeyes has focus, not when some other window has focus.

Patrick L. Mahan

--- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------

Waking a person unnecessarily should not be considered  - Lazarus Long
a capital crime.  For a first offense, that is            From the Notebooks of
							  Lazarus Long
Newsgroups: comp.windows.x
From: william@lanai.cs.ucla.edu (William Cheng)
Subject: Re: Writing Text to Postscript Files
Organization: UCLA Computer Science Department
Date: Mon, 14 Sep 92 17:14:44 GMT

In article <9209092034.AA22312@msodb..msodb.Kodak.COM> nobody@Kodak.COM writes:
>Hello,
>
>This note is in inquiry of a method for writing text to a postscript
>file.  Is this task possible, or is it just wishful thinking?  Also,
>would it be possible to write text to a raster image?  This will be
>done on a Sun workstation.  Any help would be a plus.

The easiest way is probably to use a tool like tgif, xfig, or idraw.
They are MacDraw-like tools.  They all can generate postscript files.
Tgif and xfig can also generate X11 bitmap files.  I don't know if
xfig/transfig can generate SUN raster files, but you can use the pbmplus
toolkit to convert an X11 bitmap file to a SUN ratser file.

Tgif, xfig, and pbmplus are available for anonymous ftp from the /contrib
directory on export.lcs.mit.edu.  Idraw's executables can be obtained
from the /bin directory on interviews.stanford.edu.
-- 
Bill Cheng // UCLA Computer Science Department // (310) 575-4507
3564-C Boelter Hall // Los Angeles, California 90024 // USA
william@CS.UCLA.EDU      ...!{uunet|ucbvax}!cs.ucla.edu!william
From: nzhang@umiacs.umd.edu (Ning Zhang)
Newsgroups: comp.windows.x,comp.windows.open-look,alt.toolkits.xview
Subject: Re: Help Wanted: XView PANEL_MULTILINE_TEXT problem
Summary: Source code included
Date: 14 Sep 92 21:36:52 GMT
Followup-To: comp.windows.x
Organization: UMIACS, University of Maryland, College Park, MD 20742

I sent a request a few days ago but I did not get a workaround. Here
is a simple program reproducing the problem (tested on 4.1.1 with
Openwin 3.0 FCS and 4.1.3/w Openwin 3.0 patches).


/*
 * Test PANEL_MULTILINE_TEXT bug
 */

#include <xview/xview.h>
#include <xview/frame.h>
#include <xview/panel.h>

Frame  frame;
Panel  panel;

Frame  cmd_frame;
Panel  cmd_panel;

Panel  mlinetxt;
char   mlinetxtbuf[161];

void   test();
void   disp();
void   quit();

main (argc, argv)
int argc;
char *argv[];
{
    xv_init (XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL);

    frame = (Frame)xv_create(NULL, FRAME,
        FRAME_LABEL,    argv[0],
        XV_WIDTH,       200,
        XV_HEIGHT,      100,
        NULL);

    panel = (Panel)xv_create(frame, PANEL, NULL);

    (void) xv_create(panel, PANEL_BUTTON,
        PANEL_LABEL_STRING,  "Display",
        PANEL_NOTIFY_PROC,   disp,
        NULL);

    (void) xv_create(panel, PANEL_BUTTON,
        PANEL_LABEL_STRING,  "Quit",
        PANEL_NOTIFY_PROC,   quit,
        NULL);

    xv_main_loop(frame);
}

void
test()
{
   cmd_frame = xv_create(frame, FRAME_CMD,
        XV_X,		0,
        XV_Y,		0,
        XV_HEIGHT,	100,
        XV_WIDTH,	200,
        XV_LABEL,	"TEST",
        XV_SHOW,	TRUE,
        NULL);

    cmd_panel = xv_get(cmd_frame, FRAME_CMD_PANEL);

    mlinetxt = panel_create_item(cmd_panel, PANEL_MULTILINE_TEXT,
        PANEL_LABEL_X,			10,
        PANEL_LABEL_Y,			10,
        PANEL_VALUE_X,			10,
        PANEL_VALUE_X,			30,
        PANEL_LABEL_STRING,		"DETAIL DESCRPTION",
        PANEL_VALUE,			mlinetxtbuf,
        PANEL_VALUE_DISPLAY_LENGTH,	80,
        PANEL_VALUE_STORED_LENGTH,	320,
        NULL);
}

void
disp()
{
    static int	count = 0;

    printf("disp() count = %d\n", count);

    if (count == 0)
    {
        test();
    }

    count++;

    (void) sprintf(mlinetxtbuf, "Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah %d\n", count);

    xv_set(mlinetxt, PANEL_VALUE, mlinetxtbuf, NULL);
}

void
quit()
{
    exit(0);
}


Does anyone has a workaround for the problem? I contacted Sun Tech Support
but have not got any answer.

Thanks in advence,
-Ning
Xref: sparky comp.windows.x:16465 comp.graphics:9592 comp.windows.x.apps:981 comp.windows.x.motif:6106 comp.unix.aix:9521 comp.sys.dec:4916 comp.sys.sgi:13466 comp.sys.hp:10240 comp.sys.sun.apps:1880 comp.windows.open-look:3782
From: pturner@amb4.ese.ogi.edu (Paul J Turner)
Newsgroups: comp.windows.x,comp.graphics,comp.windows.x.apps,comp.windows.x.motif,comp.unix.aix,comp.sys.dec,comp.sys.sgi,comp.sys.hp,comp.sys.sun.apps,comp.windows.open-look
Subject: New location for ACE/gr (xvgr & xmgr)
Summary: New ftp site for ACE/gr = ftp.ccalmr.ogi.edu
Keywords: XY plotting, graphics
Date: 10 Sep 92 13:20:45 GMT
Article-I.D.: ogicse.42603
Followup-To: comp.windows.x.apps
Distribution: world
Organization: Center for Coastal and Land-Margin Research
Originator: pturner@amb4.ccalmr.ogi.edu


New location for ACE/gr (xvgr and xmgr)

The machine used to distribute the XY-plotting tool ACE/gr
has a new name and IP address. We recently moved into a new
building and our portion of OGI's LAN was split into several 
subnets. The new machine name is

	ftp.ccalmr.ogi.edu (presently amb4.ccalmr.ogi.edu)

with IP address 129.95.72.34. The XView version (xvgr) will be
found in /CCALMR/pub/acegr/xvgr-2.09.tar.Z and the Motif version
(xmgr) in /CCALMR/pub/acegr/xmgr-2.09.tar.Z.

Remember to use a binary file transfer. I am not able to E-mail ACE/gr,
but there are services provided by various Internet sites that allow
ftp by mail. You might try sending mail to ftpmail@decwrl.dec.com
as follows:

Subject: (hit return) Body-of-letter: help (return) quit

I've not tried this, but it should give you instructions on how to use
this service.

About ACE/gr:

ACE/gr is an X based XY plotting tool implemented with a point 'n 
click paradigm.

A few of its features are:

   * Motif and XView versions.
   * Plots up to 10 graphs with 30 data sets per graph.
   * Data read from files and/or pipes.
   * Graph types XY, log-linear, linear-log, log-log, bar, 
	stacked bar charts.

[as 2.09 was announced a short while ago, the longer list of features
is omitted here - ACE/gr is becoming a full-featured plotting tool
except for 3d and realtime plotting - ACE/gr will never do these 
two items]

Comments, suggestions, bug reports to pturner@amb4.ccalmr.ogi.edu (if mail
fails, try pturner@ese.ogi.edu). Due to time constraints, replies will
be few and far between.

--Paul

Paul J Turner - pturner@amb4.ccalmr.ogi.edu
Center for Coastal and Land-Margin Research
Oregon Graduate Institute
Beaverton, OR 97006-1999
Newsgroups: comp.windows.x
From: mike@vort.cuc.ab.ca (Mike Nemeth)
Subject: suddenly no job control under X386!
Distribution: na
Date: Mon, 07 Sep 1992 04:52:22 GMT

system is ISC 3.2.2.1, X11R5 patchlevel 12, generic ET4000 card.

built X11R5 using gcc 2.2, installed it, worked just peachy. last week i
start up X under tcsh (or csh) and get the following...

Warning: no access to tty (Invalid argument).
Thus no job control in this shell.
%

what the *^&% ? this didn't used to happen ! does anybody have any clues?

-- 
Dan Quayle says: Don't do drugs, and don't forget to vot.
Mike Nemeth    ***    VORT Computing    ***    mike@vort.cuc.ab.ca
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x.announce
Subject: PEX 5.1 Protocol Specification
Date: 15 Sep 92 15:34:55 GMT
Distribution: inet

The final PEX 5.1 Protocol specification is now available via anonymous
ftp to export.lcs.mit.edu (18.24.0.12), in the directory /pub/DOCS/PEX/.
Changes made from the Public Review draft are listed in the file
"5.1P_changes" in that directory.
From: Hornig@RIVERSIDE.SCRC.SYMBOLICS.COM (Charles Hornig)
Newsgroups: comp.windows.x.announce
Subject: CLX 5.02
Date: 8 Sep 92 15:01:16 GMT
Article-I.D.: expo.9209081501.AA07351
Distribution: inet

Version 5.02 of CLX (the X library binding for Common Lisp) is now
available on export.lcs.mit.edu in /contrib/CLX.R5.02.tar.Z.  The
differences between this version and the version distribiuted with R5
are described below.  Please report any problems with this version of
CLX to bug-clx@expo.lcs.mit.edu.

- - - - - - - - - -

Changes in CLX 5.02:

Replace LCL:ENVIRONMENT-VALUE with LCL:ENVIRONMENT-VARIABLE.

Fix a declaration in the DEFINE-ERROR macro.

Quote type argument to TYPE-CHECK consistently.


Changes in CLX 5.01:

Support for MIT-MAGIC-COOKIE-1 authorization has been added.

All VALUES declarations have been changed to CLX-VALUES declarations.
VALUES is a CL type name and cannot be used as a declaration name.

All ARRAY-REGISTER declarations have been removed as Genera no longer
needs them.

Many type declarations have been corrected or tightened up now that some
Lisps look at them.

Print functions have been defined for bitmap and pixmap formats.

The DISPLAY-PLIST slot will be initialized to NIL.

When debugging, don't optimize SPEED in the buffer macros.

Make the CARD8<->CHAR and the window manager code work for sparse
character sets (where some codes do not have corresponding characters).

The default gcontext extension set and copy functions will take the
correct number of arguments.

PUT-IMAGE will now work for 24-bit images.

The buffer accessors for MEMBER8, etc., will use the standard mechanisms
for reporting type errors.

Typographical errors in SET-WM-PROPERTIES, SET-STANDARD-COLORMAP, and
POINTER-CONTROL have been fixed.

Symbolics systems will do lazy macroexpansion in the buffer macros.

A variety of changes for Symbolics Minima systems have been made.

Some system-dependent code has been added for CMU Common Lisp.
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x.announce
Subject: X11R5 XTEST extension now available on export
Date: 9 Sep 92 22:10:16 GMT
Distribution: inet

An R5 patch containing the XTEST extension is now available via anonymous ftp
to export.lcs.mit.edu, in the file /pub/XTEST/R5fix-xtest-1.  Instructions for
applying the fix are included in the file.  The XTEST extension is used by the
recently released X Test Suite.  You do not need to (and perhaps should not)
apply this patch unless you specifically need the XTEST extension.
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: To C or not to C...
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Tue, 15 Sep 1992 17:05:33 GMT

In article 26239@mlb.semi.harris.com, chuck@melmac.Harris-ATD.com (Chuck Musciano) writes:
>     *	I write in C++, and release sources in both C++ and C, generated
>     	by cfront.  This makes the compilation easier for everyone, but
>     	make applying patches a nightmare, since a small change to the C++
>     	source may result in horrendous changes in the generated C.

This is a not a viable proposition: the intermediate C code generated by cfront
is not complete in itself.  C++ requires runtime support from libC.a.  Unless
you have a source license for cfront you won't have the source for the run-time
library; if you do have the source USL will probably take a very dim view of
you spreading it around the net.

If you want to do this sort of thing you might try ISE's implementation of Eiffel.
Eiffel is a less popular object-oriented language than C++ but has some advantages
over it (most notably the language is simpler and supports optional garbage
collection). ISE's development environment can spit out C source, complete with
run-time support and makefiles.  

	Chris Flatters
	cflatter@nrao.edu
Xref: sparky comp.windows.x:16500 comp.human-factors:2181