HDTenEightyP/NetNews huggingface dataset:
From: davis@b11.b11.ingr.com (Chris Davis)
Newsgroups: fj.mail-lists.x-window
Subject: Processing priority of XtAdinput, XEvents and XtAddInput
Date: 28 Jul 92 16:36:51 GMT
Distribution: fj
Organization: Intergraph Corp. Huntsville, AL

Date: 28 Jul 92 13:11:30 GMT
Message-Id: <1992Jul28.131130.29006@b11.b11.ingr.com>
Newsgroups: comp.windows.x

Can someone explain how input from devices added with XtAddInput and
events types added with XtAddEventHandler are processed?

We have an application that uses both methods and the input devices added
with XtAddInput seem to get processed with a higher precedence.

Please reply to me directly if possible.

--

Christopher C. Davis
Intergraph OSF/Motif Integration
davis@nuwave.b11.ingr.COM
From: mek@hydrox.enet.dec.com (Mark Klamerus)
Newsgroups: fj.mail-lists.x-window
Subject: pc xterm
Date: 24 Jul 92 12:03:36 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: 23 Jul 92 20:27:59 GMT
Message-Id: <9207232027.AA28290@enet-gw.pa.dec.com>
Newsgroups: comp.windows.x


	I'm sure someone's done this.

	I'm looking for an xterm which understand the ANSI and DOS
	extensions for terminal characters.  I would like to use this
	for dialing up bulletin boards and getting all the colors and
	characters they use.

	Does anyone have the sources for an xterm supporting all these?

	thanks,

	Mark
From: gt0963d@prism.gatech.edu (Deeptendu Majumder)
Newsgroups: fj.mail-lists.x-window
Subject: Research Notebook Followup
Date: 27 Jul 92 18:29:32 GMT
Distribution: fj
Organization: The Dream Chasers Syndicate

Date: 27 Jul 92 13:44:02 GMT
Message-Id: <64431@hydra.gatech.EDU>
Newsgroups: comp.windows.x,comp.windows.x.apps


here is a summary of responses I have received. Bottom line: no
free lunch :-). I was looking for a tool to help me with my
dissertation work. Nobody is going to give me the money needed for
some of these powerful tools. I have been suggested to use WAIS and
I am going to look into it. I have used XWAIS but I did not know
that it may configurable for personal uses.

========================================================================
Lotus Agenda
=========================================================================

Virtual Notebook System (VNS) from frofront group (I have there		
			name and number)
CimLink which is designed for a manufacturing notebook
Interleaf's new product
FrameMaker with extensions - I have these extensions and
			we have hooked Tcl to framemaker.  This allows
 			you to customize it and write your own linkage 
			methods.
Rapport from Clarity
Slate from BBN
Asterx from Applix

The last three products are office suites on unix

Microsoft Office with visual basic on a pc.
Wordperfect office on windows.

====================================================================
Virtual Notebook System:

The product is sold commercially by The ForeFront Group, Inc. for users
outside of our research group at Baylor.  Send email to sales@ffg.com
if you are interested in literature and pricing.


In any event, FFG can be reached via telephone at 713-790-9051, M-F, 8-5.

Hmmm.  Let's see, I think it's **** for each end-user license (think of
it as a library card allowing you to enter any branch of a metropolitan
library system), and something on the lines of **** for a server license
(akin to the charge to create the library and staff it with a librarian).
A given user can simultaneously access many libraries, and a given server
can serve many networked users and support many notebooks.  (Incidentally,
the software server does not require a dedicated hardware server; many
can run on a given machine).

I'm sure there is a modest educational discount, 15% seems familiar.

=========================================================================

d.

-- 
------
"Like a harsh neon streaking  through the velvet darkness 
the whetted knife of Life tore its path through her Dreams"
From: blevins@orgel.informatik.uni-stuttgart.de (Brian Blevins)
Newsgroups: fj.mail-lists.x-window
Subject: The future of X?
Date: 30 Jul 92 22:18:54 GMT
Distribution: fj
Organization: Informatik, Univ. Stuttgart. W.Germany

Date: 30 Jul 92 17:00:55 GMT
Message-Id: <BLEVINS.92Jul30190055@orgel.informatik.uni-stuttgart.de>
Newsgroups: comp.windows.x

Hi,

After writing some Xlib code, reading this group for a while, and browsing
through the latest FAQs I could find, I'm still left with a couple of
questions and a meta-question concerning the future of X.

First, the meta-question:

Where can one (is it possible to) find out what research/advancement
of the protocol is occurring without having to subscribe to the journals?
Being a student, I'm not part of an organization that is likely to
join the X Consortium any time soon and the technical conference next
year is very likely to be out of my price range (as well as being next
year).
(I'm already considering the Journal option, and was thinking more along
the lines of FTP here.)  


Ok, now the normal questions:

1. What information (functionality, proposals, etc.) is available about
   the next release (X11R6?) ?

2. Will there or should I ask "could there" be a next version (X12R0?) ?
   I know, given the size of the current market, producing anything
   not X11 compatible would seem silly...

3. Can motion video and audio be incorporated into X11 or will they
   require a risky attempt to create an X12?  (Actually, one could
   argue that the hardware for video and audio either aren't available
   or aren't standardized enough to even consider incorporating
   these new functions into the standard protocol, but I don't
   believe it.  That's what drivers are for.)


So, that's probably too long already... E-mail me if you like, but
these seem like great post subjects to me.

Thanks for the bandwidth and the information!

Brian,
the expatriot Wramblin Wreck

W. Brian Blevins                  | blevins@orgel.informatik.uni-stuttgart.de 
Institute for Parallel and Dist.  | telephone: +49-711-682886
High-performance Computing        | address: Pfaffenwaldring 42D/3.1
Informatik Institute              |          D-7000 Stuttgart 80
                                  |          (Germany)
------------------------------------------------------------------------------
These are my opinions, wholly my opinions, and probably nothing but my opinions...

--
Brian,
the expatriot Wramblin Wreck

W. Brian Blevins                  | blevins@orgel.informatik.uni-stuttgart.de 
Institute for Parallel and Dist.  | telephone: +49-711-682886
High-performance Computing        | address: Pfaffenwaldring 42D/3.1
Informatik Institute              |          D-7000 Stuttgart 80
                                  |          (Germany)
"Computer Science is merely the post-Turing decline in formal systems theory."
------------------------------------------------------------------------------
These are my opinions, wholly my opinions, and probably nothing but my opinions...
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Kills from Window Manager
Date: 25 Jul 92 17:31:29 GMT
Distribution: fj
Organization: Jet Propulsion Laboratory, Pasadena, CA

Date: Fri, 24 Jul 92 22:16:34 GMT
Message-Id: <1992Jul24.221634.29882@thyme.jpl.nasa.gov>
Newsgroups: comp.windows.x

In article mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>In article oj@pictel.com (Oliver Jones) writes:
>> In article mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>>> operations, if any, I see no reason why it should bother
>>> participating in WM_DELETE_WINDOW. ...  Do you see any such reason?
>
>> Yes.  If the wm uses XKillClient to get rid of the application, then
>> the application's route to oblivion is through its XIO error handler.
>> [...this produces a possibly disturbing error message...]
>
>So install an I/O error handler that exits quietly instead of printing
>a noisy complaint first.  (Or implement WM_DELETE_WINDOW, but the
>
>> If you're using Athena, it takes less than a dozen lines of code to
>
>Even in bare Xlib, the I/O error handler solution takes only two lines,

IMHO, (which nobody asked for, but I'll offer it anyway) applications that 
don't participate in WM_DELETE_WINDOW are about on par with programs written 
as follows:

void main () { ... }

Yes, programs written with either error can and generally do work, but
in my experience, these errors generally indicate that the programmer
doesn't understand some of the finer details of C and/or X.

Furthermore, writing your own IOErrorHandler function to trap the single 
error seems nearly equivalent to not checking return values from sytem
calls.  You might get by 99&44/100% of the time, but why risk it?

Now, in looking at my preceding comments, I realize that someone might 
consider my comments to be mildly inflammatory.  But let me assure you 
that they are *not* intended that way.

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.
From: montjoy@thor.ece.uc.edu (Robert Montjoy)
Newsgroups: fj.mail-lists.x-window
Subject: 24-Bit Video for SPARC
Date: 22 Jul 92 09:55:14 GMT
Distribution: fj
Organization: University of Cincinnati, ECE Dept

Date: Tue, 21 Jul 1992 16:29:57 GMT
Message-Id: <1992Jul21.162957.26872@babbage.ece.uc.edu>
Newsgroups: comp.windows.x,comp.sys.sun.hardware


Hi.

We are looking for a 24-Bit Sbus Video Card for a Sparc IPX. This 
card should work with the SUN monitor. This card can only take up
2 Sbus slots(preferably 1).  The price should be in the $ 3000
range.

We have gotten information on the following cards:

	Manu		Card Name
			
	RasterOps 	Sparc TC Card
	VITec 		RasterFLEX 32
	Parallax 	Xvideo 

RasterOps will not work with the current SUN Monitors. They say
the only support 66-HZ monitors. The new SUN monitors are 76-HZ.

Parallax will support all SUN monitors. 

I am not sure about VITec.

Anyhow, has anyone used any of these cards? What is your opinion
of the card? 

Can any one recommend another card? 

Thanks.

-- 
Rob Montjoy                   		- Rob.Montjoy@UC.Edu
Computer Engineer    	      		- montjoy@ucbeh.BITNET
University of Cincinnati      		- montjoy@babbage.ece.uc.edu
Electrical and Computer Engineering	- uunet!uceng!rmontjoy

-- Standards are illusions of many faces.
From: bob@snuffy.dracut.ma.us (Bob Smith)
Newsgroups: fj.mail-lists.x-window
Subject: Re: problem installing X on a SUN
Date: 29 Jul 92 12:20:01 GMT
Distribution: fj
Organization: Somewhere in Dracut Mass

Date: 29 Jul 92 03:56:21 GMT
Message-Id: <1992Jul29.035621.2789@snuffy.dracut.ma.us>
Newsgroups: comp.windows.x

synchem@sbcs.sunysb.edu (Synchem proj acct) writes:

> s4-75g.2 cd clients/xterm
> s4-75g.3 make
> rm -f charproc.o
> cc -c -O -pipe   -I../../.       charproc.c

> /: write failed, file system is full
> compiler(iropt) error:	write_irfile: No space left on device
>  
> *** Error code 1
> make: Fatal error: Command failed for target `charproc.o'

> Note that the file system containing the X11R5 is not really full.  As
> ...

The c compiler uses /tmp to store temporary files, that's what's happening
to your root file system.  You can change this behavior is you add the option
-temp=/usr/tmp or some other temp directory that it can have free run of to
the same place where -pipe is...  Which leads me to a confusion, I thought
-pipe would prevent /tmp from growing, although I've never used that option,
apparently it doesn't...

-- 
 \ Bob Smith               \ mx: bob@snuffy.dracut.ma.us
  \ 1215 Pawtucket Blvd. #4 \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
   \ Lowell, MA. 01854       \ office && voice mail: +1 508 670-6712
From: kevin@sherman.pas.rochester.edu (kevin mcfadden)
Newsgroups: fj.mail-lists.x-window
Subject: Re: What is Devguide?
Date: 26 Jul 92 08:56:09 GMT
Distribution: fj
Organization: University of Rochester

Date: 25 Jul 92 16:46:06 GMT
Message-Id: <1992Jul25.164606.27345@galileo.cc.rochester.edu>
Newsgroups: comp.windows.x

In article <5392@dsacg3.dsac.dla.mil> nfs1675@dsacg3.dsac.dla.mil (Michael S Figg) writes:
>
>Can anybody tell me what devguide is? I have seen it in reference to X but
>don't know if it is directly related. (Wouldn't it be Xdevguide if it was?).
>
>Thanks, Mike
>
>
>-- 
>Perl doesn't mind a little pluralism-a perl   | Michael Figg  DSAC-FSD
>script is correct if it's halfway readable    | DLA Systems Automation Center
>and gets the job done before your boss fires  | Cols, Ohio mfigg@dsac.dla.mil
>you. -- Wall and Schwartz ("Programming Perl")| CIS: 73777,360    

Mike,

	What is devGuide you ask?  Just last week I started to make use of it
and it is pretty damn useful.  It is program that allows you to design 
a visual interface for use under X windows (or atleast openwindows). 

	When started up, the program displays a small window that has all
the different things that can be used in an user interface.  There are
pop up windows (the ones with pins in the upper left corner), cmdtool-like
windows, pulldown menus, buttons, etc....  All you have to do is create a 
window and then put the stuff you want inside it.  After placing something in
the window you would define its properties such as labeling text fields,
title of buttons, how long a text field, choices for menus, etc...  After that
is all done you get to make connections between items.  Connections are
used to tell the windowing system what to do when you press a button or 
make a menu choice.  For example I press a button and a window pops up or 
I enter a command in a text field and then something happens.

	The program is really well done but it does have its drawbacks.  I have
not yet found a way to change the font!  This is extremely annoying.  Even
more annoying is that I have not yet found a way to remove the
increment/decrement buttons on numeric fields (the buttons that allow you to
increase the numeric value up or down with out having to type something).

	Anyway, the program is extremely useful and any programs I write in
the future will probably make use of it.  Another drawback occurs when you
are writing the program for a group of people to use, like a detector manager
for taking data during testing and observing runs which I am writing.  Everyone
cannot agree how they want it to look! AARRGGHH.

	But all in all I recommend the program.


Kevin
From: campbell@redsox.bsw.com (Larry Campbell)
Newsgroups: fj.mail-lists.x-window
Subject: Re: X: User simplicity vs code complexity (vs language limitations)
Date: 27 Jul 92 02:13:11 GMT
Distribution: fj
Organization: The Boston Software Works, Inc.

Date: 26 Jul 92 22:19:24 GMT
Message-Id: <1992Jul26.221924.29209@redsox.bsw.com>
Newsgroups: comp.windows.x


In article <1992Jul24.145008.1028@ERA.COM>, feit@ERA.COM (Mark Feit) writes:
> 
> Yes, and there are reasons for things like that.  Those two particular
> functions serve different purposes, and a thorough reading of the
> manual pages for both will reveal that.  The reason for most of the
> other function pairs (i.e., XDrawLine/XDrawLines) is to keep traffic
> between the client and server to a minimum.  The former is for those
> cases where you only need ONE.

Although I agree with your overall point, this particular example
(XDrawLine(s)) doesn't support it.  That these are two routines, rather
than one, is due to limitations in the programming language (C) rather
than a necessary optimization of network traffic.

Omitting constant arguments for clarity, in Lisp (Scheme) you could say
something like this:

	(x:draw-lines (big-computation))	; draw complex figure

just as easily as

	(x:draw-lines '((x1 . y1) (x2 . y2)))	; draw single line

There's no need for a separate "x:draw-line" routine.  C programmers
want to have such a routine because an XDrawLines that can accept
a dynamically computed (potentially large) list of points:

	big_computation(&pointer_to_list, &length_of_list);
	XDrawLines(pointer_to_list, length_of_list)

becomes cumbersome if you want to just draw a single line:

	XPoint points[2];
	points[0].x = x1;
	points[0].y = y1;
	points[1].x = x2;
	points[1].y = y2;
	XDrawPoints(points, 2);

But this is a problem with C, not a problem with X, and there are
many such examples.
-- 
Larry Campbell             The Boston Software Works, Inc., 120 Fulton Street
campbell@redsox.bsw.com    Boston, Massachusetts 02109 (USA)
From: raney@teal.csn.org (Scott Raney)
Newsgroups: fj.mail-lists.x-window
Subject: Re: benchmark for xserver
Date: 21 Jul 92 12:09:52 GMT
Distribution: fj
Organization: Colorado SuperNet, Inc.

Date: Tue, 21 Jul 1992 03:02:31 GMT
Message-Id: <raney.711687751@teal>
Newsgroups: comp.windows.x

roell@informatik.tu-muenchen.de (Thomas Roell) writes:

>Again there is a hair. xengine is one of the most rediculus benchmarks
>I've ever seen. You have to look into the source how they do the
>annimation. You are right that they use there a bunch of requests that
>really would tell you something, if they had done it right. In fact
>all of the real drawing requests go into pixmaps, and not into the
>video-memory. Thus you face to basic facts:

>	1) xengine is only a CPU benchmark, since almost ewverybody
>           uses the generic cfb code from MIT to draw into pixmaps.
>           And even worse, since almost every application draws
>	   directly to a window the pixmapcode is often shrunk down to
>	   the basics and thus slow.

>	2) The only graphical operation that really involves the
>	   graphics board is downloading the already rendered image.
>           The problem here is that most fast graphics boards are
>           semi-intelligent, and the bottleneck there is the
>	   transmission of these pixmaps from CPU to graphics board.
>	   Thus even if your highend board is visibly much faster that
>           a dumb PC VGA the latter one will perform these tests much
>           faster.

In order to do double-buffered animation, you *have* to draw into
offscreen memory (or count on non-portable server extensions).  The
"bottleneck" that you describe is a result of poor hardware design,
and is not an inherent limitation.  I would strongly recommend *not*
buying any graphics controller that can't draw into offscreen memory:
you'll be sorry eventually if you do.

If all you do is circuit layout, then by all means use a graphics
controller.  Otherwise, you'll be a lot better off spending your money
on a faster CPU.  The days of XOR rubberbanding are numbered, and
opaque feedback requires double buffering.

The conclusion? xengine *is* a useful benchmark, IMHO.

>Give these facts I would say that xengine as a benchmark is unusable.


>- Thomas
>--
>-------------------------------------------------------------------------------
>Das Reh springt hoch, 				e-mail: roell@sgcs.com
>das Reh springt weit,				#include <sys/pizza.h>
>was soll es tun, es hat ja Zeit ...

-- 
***********************************************************************
* Scott Raney  303-447-3936            Remember: the better you look, *
* raney@metacard.com                   the more you'll see -- Lidia   *
***********************************************************************
From: josh@spss.com (Joshua Barr)
Newsgroups: fj.mail-lists.x-window
Subject: Is there a practical limit to app-defaults?
Date: 21 Jul 92 20:38:48 GMT
Distribution: fj
Organization: SPSS Inc.

Date: 21 Jul 92 13:43:05 GMT
Message-Id: <Jul21.134420.41136@spss.com>
Newsgroups: comp.windows.x.motif,comp.windows.x

I have a large application whose interface is coded in UIL. I am
considering putting all my labelString resources into my application's
app-defaults file to simplify internationalization/customization,
but am daunted by the strain this will put on launch performance and 
server memory requirements. A conservative estimate is that I have 
15,000 strings. Does anyone have experience with this large an app-defaults 
file or know of alternatives to shipping multiple UID files?


--
Joshua Barr, Interface Designer
SPSS, Inc.
444 N. Michigan Avenue
Chicago, Illinois   60610

josh@spss.com
From: ratinox@splinter.coe.northeastern.edu (Richard Pieri/Stainless Steel Rat)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Using `xv` in conjunction with `tvtwm` for backgrounds
Date: 26 Jul 92 11:23:36 GMT
Distribution: fj
Organization: 3WA, Boston Office. Or Nu Meta Chi. Take your pick.

Date: 26 Jul 92 00:50:45 GMT
Message-Id: <RATINOX.92Jul25205045@splinter.coe.northeastern.edu>
Newsgroups: comp.windows.x.apps,comp.windows.x

>>>>> On 24 Jul 92 20:00:06 GMT, naren@cs.UAlberta.CA (Narendra Ravi) said:

NR> Has anyone managed to use xv instead of xloadimage for loading pixmaps in
NR> tvtwm?

No, it won't work. Unless you can find a way to compile in "xv -root" into
the tvtwm binaries (which I have to date been unable) instead of "xloadimage."

--Rat

||||| | | | |  |  |  |   |   |    |    |    |   |   |  |  |  |  | | | | | |||||
                                                   __        ___ 
Richard Pieri, Northeastern's Stainless Steel Rat/   | /| / /   | The Worlds
Internet: ratinox@meceng.coe.northeastern.edu   /__  |/ |/ / /| | Welfare Works
    UUCP: ...!northeastern.edu!splinter!ratinox/   | /| / / / | | Association:
  BITNET: UA_RLP@NUHUB{.BITNET}               /__  |/ |/ / /  | | I will solve
  USNail: 14 Westdale RD  Holbrook, MA 02343 /   | /| / / /___| | any problem
 ICBMnet: 42 deg 1 min N, 71 deg 0 min W    /    |/ |/ /_//_____| for you.
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Double Click in a window (Motif Drawing Area)
Date: 25 Jul 92 09:39:19 GMT
Distribution: fj
Organization: McGill Research Centre for Intelligent Machines

Date: Fri, 24 Jul 92 18:37:23 GMT
Message-Id: <1992Jul24.183723.583@thunder.mcrcim.mcgill.edu>
Newsgroups: comp.windows.x

In article <50599@dime.cs.umass.edu>, nikoulis@venice.pilgrim.umass.edu (Panos Nikoulis) writes:

> Is there a way to detect a double click mouse event in a window

Not reliably.  The protocol does not contain enough support to allow
this to be done right.  (It needs some sort of timeout event.)

> Currently, I am using time functions to make it "wait" for a time
> equal to the double click interval and detect a second ButtonPress
> after the first one (inside the Drawing Area callback).

Some toolkits/widget sets contain code that does this for you.  It'll
work as well as your code does, presumably, but will suffer from the
same basic problem: it can lose big in the presence of network hiccups
(it can fail both ways: it can mistake a double click for two single
clicks, and it can mistake two single clicks for a double click).

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu