HDTenEightyP/NetNews huggingface dataset:
From: jss@inmet.camb.inmet.com (Jelle Schoen)
Subject: Getting resources of another client
Organization: Intermetrics Inc, Cambridge MA
Date: Mon, 14 Sep 1992 22:37:27 GMT

I hope someone can help me with the following:

I have an application running under the X window system (X11R4) on a Sparc
workstation and this application creates a subprocess which will run
independently under X creating its own windows.  The main application needs
to be able get resources/properties of the windows of the subprocess, such
as the x and y locations.  I like to write these to a file in order for an
user to be able to save the screen layout of the main and subprocess, and
restart them at some later date.  The subprocess is actually a plot utility
so I like to also save the window's content of it.  I have found a way to get
the root window's ID and a list of ID of all the clients currently running
under the X server, and their x and y coordinates.  I have done this using
calls to the procedures XOpenDisplay, XQueryTree, and XGetWindowAttributes.
I have the following questions:

1) Is there a way to uniquely identify the windows of my subprocess, that is
   any resources/properties that'll tell me which window is which?  How
   do I do that?  The ID itself won't do the job since the subprocess
   creates its IDs and the main process doesn't know them at all and I can't
   update the source of the subprocess.

2) Is it possible to save a screen layout?  And a window content?  I have heard
   of the utilities xwininfo for window attributes and xwd for a window's
   screendump but I need something that isn't interactively and they are.

I am new to the X world so any information is appreciated.  Also if I am
going in the wrong direction let me know.  I prefer e-mail but I also
will check the newsgroup.  Thanks,

Jelle Schoen
jss@inmet.camb.inmet.com
Newsgroups: comp.windows.x
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: xterm reverse video garbles display on sun ipx
Organization: McGill Research Centre for Intelligent Machines
Date: Tue, 15 Sep 92 17:03:42 GMT

In article <1992Sep10.064729.12759@funet.fi>, jty@cs.tut.fi (Yli-Nokari Jyrki) writes:

> I have an annoying problem when running sun's /usr/openwin/demo/xterm
> with (at least) adobe courier font: It seems that when a (curses)
> program erases reverse-video text from screen by overwriting it with
> blanks, the lowest line of pixels is not erased.  I guess this is a
> font problem, but how can I fix it?

Yes, it's a font problem.  xterm expects its font to be a
character-cell font, and the font you're using isn't - the glyphs
descend farther than the font extents.  Display glitches are to be
expected.  (xterm demands a charcell font to work right.  It works
mostly right with any monospaced font, but will sometimes leave turds
on the screen.  This is an example.)

How can you fix it?  You'd have to go into the BDF file for the font in
question and edit the offending glyphs....

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.x.open-look
From: noel@chpc.utexas.edu ((user name unknown))
Subject: Needed -- public-domain graph-plotting widget
Organization: The University of Texas System - CHPC
Date: Sun, 13 Sep 92 21:38:33 GMT


The subject line says it all.
Thanks in advance.
-- 
Noel Menezes                            Internet: noel@hermes.chpc.utexas.edu
Research Assistant                      BITNET:   noel@uthermes
Center for High Performance Computing   Phone:    (512) 471-2447
Balcones Resarch Center & UT-Austin     Fax:      (512) 471-2445
Newsgroups: comp.windows.x
From: bob@jupiter.com
Subject: Re: multiple screens (display), single pointing device....
Organization: Jupiter System, Alameda, CA
Distribution: usa
Date: Wed, 2 Sep 1992 01:56:48 GMT


In article <1992Aug31.160605.1569@thyme.jpl.nasa.gov>, kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes:
|> The unasked, and more important question, is can your hardware support the 
|> installation of two or three frame buffers?

Jupiter Systems offers such a beast as an X terminal. We support up to 6 frame
buffers, where the frame buffers may, or may not (up to you) be reported to the
client as different screens. If such a server reports only one
screen, then the server is in what we call Virtual Screen mode.
In virtual screen mode, you can move windows from frame buffer to
frame buffer, and can, of course, have windows straddling frame
buffers.

For more info, contact me.

bob schulman
bob@jupiter.com


Newsgroups: comp.windows.x
From: william@lanai.cs.ucla.edu (William Cheng)
Subject: strange ordering of fonts in the R5 font server...
Followup-To: comp.windows.x
Originator: william@lanai.cs.ucla.edu
Keywords: font server
Organization: UCLA Computer Science Department
Date: Mon, 7 Sep 92 06:10:55 GMT

When I do:  xlsfonts -fn "-*-courier-medium-r-normal--18-*-*-*-*-*-iso8859-1"
I get the following result on my SUN:

-adobe-courier-medium-r-normal--18-0-100-100-m-0-iso8859-1
-adobe-courier-medium-r-normal--18-0-75-75-m-0-iso8859-1
-adobe-courier-medium-r-normal--18-180-75-75-m-110-iso8859-1
-bitstream-courier-medium-r-normal--18-0-0-0-m-0-iso8859-1

The ``native'' 18 point courier-medium-r-normal font is 75dpi.
(If I do: xlsfonts | grep courier-medium-r-normal--18, all I
get is -adobe-courier-medium-r-normal--18-180-75-75-m-110-iso8859-1.)
Consequently, the 100dpi font is ugly because it's scaled.  Is there
any way I can reorder the fonts returned by the font server so that
the font corresponding to the native dpi is chosen first?
-- 
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
Newsgroups: comp.windows.x
From: s8923098@macnab.mqcs.mq.oz.au (Josef WIDJAJA)
Subject: Xlib - C Language X Interface, where?
Keywords: ClipMask gc
Organization: Macquarie University, School of Mathematics, Physics, Computing and Electronics
Date: Fri, 11 Sep 1992 01:04:08 GMT

In article <18n56rINN2df@fbi-news.Informatik.Uni-Dortmund.DE> klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes:
|
|Two quotes from "Xlib - C Language X Interface, MIT X Consortium Standard,
|X Version 11, Release 5" should answer your questions:

Can anyone tell me where I can get this by anon. ftp? I read somwhere
that this should be available in the standard X release from MIT. 
But my local site does not keep this document. My Sys. Admin. could not
help either. I only want this doc, and I don't want to waste bandwith
by ftping the whole X distribution tar file and then extract just one
file from it. Can someone also tell me if a poscript version is available?

I am sorry if this is a FAQ, I haven't seen a FAQ in this newsgroup
yet.

  

--
 _________Josef Widjaja____________  
|  s8923098@mackay.mpce.mq.edu.au  |
|  Macquarie University, Australia | 
|__________________________________|
From: amoss@huji.ac.il (Amos Shapira)
Newsgroups: comp.windows.x
Subject: Re: Questions regarding TVTWM
Date: 8 Sep 92 10:56:59 GMT
Organization: Mail to News Gateway at Wang Labs

mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:

>In article <huber.15.715359892@vax2.gac.edu>, huber@vax2.gac.edu (Tom Huber) writes:

>> I am running TVTWM under X11R4 on a NeXT

>> I was wondering how to set the root window to grey (rather than the
>> default tiled background with TVTWM?  Before loading TVTWM, I can use
>> xsetroot -grey  , however once TVTWM loads it overwrites it with the
>> default background and further calls to xsetroot have no effect.

>of the screen.  IMO the right solution is to fix tvtwm, but the way out
>usually taken is to hack on programs that manipulate the root window
>and add kludges to find the tvtwm-created window that serves as the
>visual background of the screen, and manipulate that window instead.

xv -root will find the right window.

What I would really like to have in tvtwm is that it wouldn't obscure the
real root so no-one should know about it and so I get the same image no matter
what part of the virtual root is visible currently (I was thinking while
writing this [I sometimes do that :)] and though that maybe a transperant
window as the virtual root might do that? What do you think?)

Cheers,
--
--Amos Shapira (Jumper Extraordinaire)
C.S. System Group, Hebrew University, Jerusalem, Israel
amoss@cs.huji.ac.il
From: gildea@expo.lcs.mit.EDU (Stephen Gildea)
Newsgroups: comp.windows.x
Subject: Re: XDM configuration question
Date: 14 Sep 92 17:49:50 GMT
Organization: X Consortium, MIT Laboratory for Computer Science

You can have xdm manage the local display on only some hosts
by using #include in a separate config file.

On the hosts that do not want xdm to manage the local display,
start xdm like this:

xdm -config /usr/lib/X11/xdm/xdm-config-nolocal

The xdm-config-nolocal file looks like this:

DisplayManager.servers:		/dev/null
#include "/usr/lib/X11/xdm/xdm-config"

That is, this config file specifies an empty Xservers file and
then includes the normal config file.

 < Stephen
   MIT X Consortium
Newsgroups: comp.windows.x
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: libXaw.so.5 not found?
Keywords: xdm, lib not found
Organization: McGill Research Centre for Intelligent Machines
Date: Fri, 11 Sep 92 00:49:49 GMT

In article <1992Sep8.151518.27183@ims.com>, tonyf@ims.com (Antonio Freixas) writes:

> But I just learned the following interesting things about X on a
> Sun-4:

> 1) xterm and xload need to be owned by root and have the set-user-id
>    bit set.

Not necessarily.  xload shouldn't need setuid root; setgid kmem should
be enough.  xterm doesn't *need* any privilege at all, normally; it
will generally work without it, though it can't chown the pseudo-tty or
write utmp entries otherwise (unless the system is mis-set-up...).

> 2) Programs run as root will ignore LD_LIBRARY_PATH and will only
>    look in "safe" directories (such as /usr/lib) for dynamic
>    libraries (to avoid an obvious security risk).

Not programs run as root, but rather, setuid programs.  The list of
"safe" directories can be changed, though I'm not sure how (I think
it's done with ldconfig), and I think the built-in library path also
comes into this somewhere.

> 3) When dynamic loading takes place, /usr/lib is not searched;
>    instead, the loader looks at a cached list in /etc/ld.so.cache.

It's not quite that simple.  At run time, *conceptually*, ld.so does a
path search for each library.  ld.so.cache is just a cache to reduce
searching of some commonly-searched directories....

Or such is my understanding.  As tonyf says, "[This information] may
not even be completely correct."...

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.x.intrinsics
From: bernhard@ssd.intel.com (Bernhard Ries)
Subject: Re: Colormap stuff
Keywords: color
Organization: Supercomputer Systems Divison, Intel Corp.
Date: Thu, 10 Sep 1992 08:12:57 GMT

In article <18lvtbINNbrc@bigboote.WPI.EDU>, rtipnis@cs.wpi.edu (Rajeev Tipnis) writes:
|> 	Thanks to all those who sent me mail or followed up to 
|> 	my posting on "how to change the colormap cells on the 
|> 	fly".
|> 
|> 	I am including some code here, which lets the programmer
|> 	figure, how not to touch the color cells of the colormap
|> 	which are getting used by other applications on the same
|> 	display, and use the rest of the colormap. 
|> 	
|> 	Thanks again for all your help.
|> 
|> 
|> SetupMyColormap()
|> { .... }

This is more or less the code I use in my application. However, there seems
to be a problem with some X-window programs that don't free their colorcells
correctly when they exit. For example, if I run ghostscript, the number of
colorcells available for my application is reduced by quite a bit. The only
way to fix this that I know of is to restart the X-window server.

Does anybody know what the reason for this behavior is or if there is any
way to work around it?

- Bernhard.
- 
Bernhard Ries                  Intel Corporation | email:bernhard@esdc.intel.com
European Supercomputer Development Center (ESDC) | phone:       +49-89-90992-408
Dornacher Str. 1, W-8016 Feldkirchen b. M., FRG  | fax:           +49-89-9039142
Newsgroups: comp.windows.x.intrinsics
From: morris@probitas.cs.utas.edu.au (John Morris)
Subject: Available fonts
Keywords: fonts
Organization: University of Tasmania, Australia.
Date: Mon, 14 Sep 1992 01:05:08 GMT

Can some kind soul tell us how we obtain a list
of fonts supported by an X client or server?

John Morris
University of Tasmania

--
John Morris                              morris@probitas.cs.utas.edu.au
Department of Computer Science,          Phone: +61-02-20 2911
University of Tasmania,                  Fax:   +61-02-20 2913
GPO Box 252C, Hobart, Tas 7001, Australia.
Newsgroups: comp.windows.x.intrinsics
From: amoss@huji.ac.il (Amos Shapira)
Subject: Re: Should XtSetValues know to handle NULL Widget ptr?
Organization: Mail to News Gateway at Wang Labs
Date: 11 Sep 92 09:33:22 GMT

dansmith@Autodesk.COM (Daniel Smith) writes:

>In <amoss.715956849@falafel> amoss@huji.ac.il (Amos Shapira) writes:
>	No.  Library routines can be faster if they can assume the programmer
>is handing them something palatable.

Yes, I realise that.

>	Would you expect fputc to work with a NULL FILE pointer?  Try assigning:

Good analogy.

>if ((some_widget = WcFullNameToWidget(widget, "*queryTypeList")) != NULL)
> 	XtSetValues (some_widget, args, XtNumber (args));

>	or better yet:

>if ((some_widget = WcFullNameToWidget(widget, "*queryTypeList")) != NULL)
> 	XtVaSetValues(some_widget,
>			XmNitemCount, DNS_nqtypes,
>			XmNitems, items,
>			NULL);

>	so that you don't have wasted XtSetArg calls...

Now here we have a slight disagreement.  If you are concerned about speed
then I think the first (non-Va) form is better since:

1. XtSetArg is a macro, not a function call, so it's not expensive.

2. What the Va... routines do is to put your arguments into a list and
   call the non-Va routines, hence you have one extra function call.

These should matter only in heavily used loops or such, but since you mentioned
this in the performance context I had to present my view.

>				Daniel

Thanks for your reply,

Cheers,
--
--Amos Shapira (Jumper Extraordinaire)
C.S. System Group, Hebrew University, Jerusalem, Israel
amoss@cs.huji.ac.il
Newsgroups: comp.windows.x.intrinsics
From: pprun@augustit.uswc.uswest.com
Subject: Re: More popup positioning troubles
Organization: US WEST Information Technologies
Date: Tue, 8 Sep 1992 19:24:25 GMT

> ...
>> Almost all of the respondees (is that a word?) told me to set the
>> resources, namely XtNx and XtNy.
> ...
>> No matter if I set the resources before the widget creation
>> call or just before the XtPopup call with an XtSetValues, the shell
>> goes where ever it please (and not always the same place).


Did I forget to post the final answer to my problem?  Probably.
Anyway, I'm the one who started this thread.  The solution was to
set Mwm*clientAutoPlace to False.  After doing this, I can set XtNgeometry
or set XtNx & XtNy or even execute an XtMoveWidget just before the
XtPopup call.  All of the above techniques position popup shells just
fine now.


Pete
pprun@lookout.mnet.uswest.com
From: converse@expo.lcs.mit.edu (Donna Converse)
Newsgroups: comp.windows.x.intrinsics
Subject: Re: Enter/Leave events and Xt
Date: 11 Sep 92 22:15:24 GMT
Article-I.D.: mintaka.1992Sep11.221524.7065
Organization: X Consortium, MIT Laboratory for Computer Science

In article <4017@tivoli.UUCP>, taylor@foraker.tivoli.com (Eric Taylor) writes:
> Suppose I have compress_enterleave set to true on a widget class.
> Suppose I have a window heirarchy as such :
> 
> -------------------
> |                 |
> |   ----------    |
> |   |        |    |
> |   |    A   |    |
> |   |        |    |
> |   ----------    |
> |                 |
> |        B        |
> |                 |
> -------------------
> 
> Suppose the mouse starts in A and moves
> through B so that you get an enter event on B (NotifyInferior)
> and a leave event on B (NotifyAncestor).
> 
> If I am moving the mouse fast enough, will the intrinsics
> discard the enter-leave events if compress_enterleave is set
> to true? 

Based on reading section 7.9.2 of the spec, I'd say yes.

> This would be incorrect behavior since Widget B
> now thinks that the mouse is still inside of it.

I don't understand.  Do you have an example program?


Donna Converse
MIT X Consortium
From: dansmith@Autodesk.COM (Daniel Smith)
Newsgroups: comp.windows.x.intrinsics
Subject: Re: Should XtSetValues know to handle NULL Widget ptr?
Date: 10 Sep 92 18:26:42 GMT
Organization: Autodesk Inc., Sausalito CA, USA

In <amoss.715956849@falafel> amoss@huji.ac.il (Amos Shapira) writes:
> My question: Can I expect Xt* routines to bail out correctly from such blatent
> errors

	No.  Library routines can be faster if they can assume the programmer
is handing them something palatable.

	Would you expect fputc to work with a NULL FILE pointer?  Try assigning:

if ((some_widget = WcFullNameToWidget(widget, "*queryTypeList")) != NULL)
 	XtSetValues (some_widget, args, XtNumber (args));

	or better yet:

if ((some_widget = WcFullNameToWidget(widget, "*queryTypeList")) != NULL)
 	XtVaSetValues(some_widget,
			XmNitemCount, DNS_nqtypes,
			XmNitems, items,
			NULL);

	so that you don't have wasted XtSetArg calls...

				Daniel

-- 
     Daniel Smith, Autodesk, Sausalito, California, (415) 332-2344 x 2580
	      Disclaimer: written by a highly caffeinated mammal
	    dansmith@autodesk.com            dansmith@well.sf.ca.us
From: drand@spinner.osf.org (Douglas Rand)
Newsgroups: comp.windows.x.intrinsics
Subject: Re: Should XtSetValues know to handle NULL Widget ptr?
Date: 9 Sep 92 17:47:31 GMT
	<MELBY.92Sep9030336@dove.yk.Fujitsu.CO.JP>
Organization: Open Software Foundation

In article <MELBY.92Sep9030336@dove.yk.Fujitsu.CO.JP> melby@dove.yk.Fujitsu.CO.JP (John B. Melby) writes:

   >One of the problems is the library "knowing" that the passed
   >parameter is wrong.  This is hard to do generally,  although
   >easy enough for a case like NULL.  But then another function
   >returns -1 or -2 to indicate an error,  or 0 (which may not equal
   >NULL in size or value on some architectures).

   If a function returns an error code, it should be easily distinguishable
   from anything else it returns.  If not, there is something wrong with the
   function.

   In C, 0 _always_ equals NULL, as long as the programmer is handling
   cast operations and argument passing correctly.  (The comp.lang.c
   FAQ explains in detail how NULL is handled.)

   Of course, range checking of function parameters (if overdone) can slow
   down a program considerably.

Well,  you misunderstood me.  I wasn't arguing whether a particular
function's error return was distinguishable.  I was arguing that
you can't automatically feed the result of a function into another
function and have that automatically determine the validity of
the passed parameter.

In C,  NULL is not always 0,  although (unfortunately) there may
be semantics to make (int) NULL == 0.  C (not ANSI C) is not 
automatically going to cast that returned function value across 
the call interface.

Range checking on a pointer will not tell you whether that pointer
is allocated in a genuine, valid arena,  or whether it is a random
number.  This is not a tractable problem.  Even trying access won't
help.  Consider the idiot who returns a pointer to an automatic 
variable from a function.  The called function can't know the
validity of that parameter.

--
Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
Snail:         11 Cambridge Center,  Cambridge,  MA  02142
Disclaimer:    I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
Subject: Re: Icon Modification under MWM vs. OLWM
Organization: University of Maine System
Newsgroups: comp.windows.x.intrinsics
From:    michael@maine.maine.edu (Michael Johnson)
To:      NETNEWS@MAINE
Date:    Sat, 12 Sep 92 17:30:17 EDT

According to the ICCCM, a window manager is under no obligation to pay
attention to changes an application makes to the WM_HINTS property, of
which the icon_pixmap is a member. That is what you are really doing under
the covers.

As it happens, MWM does pay attention out of courtesy. The ICCCM-mandated
way for an application to be able to change its icon is for the application
to create an icon window (as a child of the root). You would then set the
Window ID of this window as the XtNiconWindow resource or your top-level
window. You have to be prepared to handle Expose events on this window. You
must also be prepared to have the window manager resize and/or reparent this
window, just like any other managed top-level window.

One way to do this would be to create a subclass of TransientShell which takes
a pixmap as a resource, and copies this pixmap into its window when an Expose
event is seen. Set the XtNmappedWhenManaged resource of this widget to FALSE,
or create it with XtCreatePopupShell. Make sure you realize the widget and
assign its window to XtNiconWindow *before* you realize your top-level shell.

By the way, another benefit of using an icon window is that your icon can be
in more than two colors.

Michael Johnson, VM Systems Group                     michael@maine.maine.edu
"I will choose the path that's clear. I will choose Free Will." -- Neil Peart
From: melby@dove.yk.Fujitsu.CO.JP (John B. Melby)
Newsgroups: comp.windows.x.intrinsics
Subject: Re: Should XtSetValues know to handle NULL Widget ptr?
Date: 9 Sep 92 03:03:36 GMT
Organization: Open Systems Dept. Div. 2 Sect. 1, FUJITSU LTD.
In-reply-to: drand@spinner.osf.org's message of 9 Sep 92 03:17:15 JST

>One of the problems is the library "knowing" that the passed
>parameter is wrong.  This is hard to do generally,  although
>easy enough for a case like NULL.  But then another function
>returns -1 or -2 to indicate an error,  or 0 (which may not equal
>NULL in size or value on some architectures).

If a function returns an error code, it should be easily distinguishable
from anything else it returns.  If not, there is something wrong with the
function.

In C, 0 _always_ equals NULL, as long as the programmer is handling
cast operations and argument passing correctly.  (The comp.lang.c
FAQ explains in detail how NULL is handled.)

Of course, range checking of function parameters (if overdone) can slow
down a program considerably.

-----
John B. Melby
Fujitsu Limited, Yokohama
melby%yk.fujitsu.co.jp@fai.com