HDTenEightyP/NetNews huggingface dataset:
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Subject: Re: GUIs Considered Harmful
Organization: Oceanroutes Canada Inc.
Date: Tue, 25 Aug 1992 16:31:02 GMT

Peter da Silva writes: 
> 
> johnm@cajal.uoregon.edu (John Martin) writes:
> > For kicks sometime, take a person who is used to a CLI and put them on a Mac.
> > I guarantee that they will not be able to do *anything* useful until they have
> > either read the manual or experimented a lot.
> 
> To put it bluntly, this is complete balderdash. Take me, for example. I'd been
> using CLI based systems for 10 years when the Xerox Star office system came
> out, and I was able to use it within minutes. GOOD GUIs *are* easier to use.
> BAD GUIs suck dirty canal water.
> 
> The Mac GUI is a moderately good one. It used to be quite good (though not up
> to the quality of the Star), but it's grown a *lot* of chrome in the past 6 or
> so years.

Being a *power* CLI user, I found it very frustrating initially
learning the Mac.  There are so many *tricks* that let you do things
faster and slicker than the *obvious* click-em-n-drag-em-one-at-a-time
method, but the only way to find out about them was via brain dump
from a Mac expert (boring for him, humiliating for me :).

The manuals seemed to go to great lengths on things like how to
tell a mouse from a monitor and what to do when a button saying
*push me* appears, but nothing at all on the *good stuff*.  Or so
it seemed from a *quick read* :).

Apple was claiming to take power away from the high-priests in
the computer center and give it to the user, but I was left with
the taste of watered-down wine and the sense that a new priest-hood
was springing up (and I wasn't in it :( ).

But after all, any complex system *has* to be learned.  NEWS, Motif, and
MS-Windows were much easier to learn after having semi-mastered the
Mac.  The main problem I have with GUI's now is the subtle differences 
between those four (I've never tried OpenWindows). ... Terry
Newsgroups: comp.windows.x
From: amir@matis.UUCP (Amir Katz)
Subject: SUMMARY: Help! I can't rebuild X11R5
X-Unparsable-Date: Mon, 31 Aug 92 11: 36:08 EET DST
Reply-To: matis!matis.ingr.COM!amir
Organization: SEE Technologies Ltd.
Date: Mon, 31 Aug 1992 14:29:34 GMT

A few days ago I complained that when I build the full X11R5 release, I get
the following error (just an example)

making all in ./extensions/test...
rm -f shapetest
cc -o shapetest shapetest.o -L/usr/lang/SC1.0  -pipe
   -L../.././extensions/lib -lXext  -L../.././lib/X -lX11 -L/usr/lib    
ld: /usr/lib/libXt.so.4.10: rd_shsb: can't open shared library /usr/lib/libXt.so.4.10
Compilation failed
gmake[3]: *** [shapetest] Error 4

I found out that the shared libraries were built with other libs tied to
them, for example:

  ld -o libXext.so.4.10 -assert pure-text [objects] -L../../lib/Xt -lXt etc.

This is because my sun.cf config file had the SunPost411FCSld flag set to
YES. I did that, because I thought that if the patch applies to SunOS 4.1,
it will be rolled into later versions of the OS and I'll stil need to set
this variable. I was wrong, of course.

I fixed that, and some other unrelated problems, and now everything is
dandy.

Sorry for the waster bandwidth.
-- 
/* ----------------------------------------------------------- */
/*  Amir J. Katz             |   amir@matis.ingr.COM           */
/*  System Specialist        |   Voice:  +972 52-584684        */
/*  SEE Technologies Ltd.    |   Fax:    +972 52-543917        */
/* ............ Solaris 2.0 - The Final Frontier ? ........... */
Newsgroups: comp.windows.x
From: rrb@seas.smu.edu (Robert R. Bailey)
Subject: Xview and XGetImage problem
Organization: School of Engineering and applied science; S.M.U.; Dallas, Tx
Date: Sat, 29 Aug 1992 02:35:05 GMT

I am working with a 7-bit gray scale image and an overlay of several colors
using XView on a Sun SPARC.  After displaying the image and generating the
overlay, I can't seem to read the resulting image back so that I can write
it out to a rasterfile.

The following is a summary of how I display the image:
  dsply = (Display *) xv_get( canvas, XV_DISPLAY);
  win = (Drawable) xv_get( canvas_point_window( canvas), XV_XID);
  set color map;
  xi = XCreateImage( dsply, default_visual, 8, ZPixmap, 0, data,
    width, height, 8, width);
  XPutImage( dsply, win, gc, xi, 0,0,0,0, width, height);

Now, I draw on top of the image:
  XDrawLine( dsply, win, gc, x,y,x,y); 
  etc.;

I can scroll around and draw some more.
Now I want to take the resulting modified image and write it to a rasterfile.
(If I can get it to an XImage, I can to it.)  I tried:
  new_xi = XGetImage( dsply, win, 0,0, width,height, AllPlanes, ZPixmap);

But this does not work.  I can only get that part of the image that is
currently displayed in the window, which is smaller than the whole
(1024 X 1024) image.

How do I get the whole image?

Thanks for any suggestions.

Bob Bailey
rrb@seas.smu.edu
-- 
From: Bob Bailey = rrb@seas.smu.edu
From: tjones@moose.cs.indiana.edu (terry jones)
Newsgroups: comp.windows.x
Subject: Problem with dialog widget values in Xaw & Xaw3d.
Date: 31 Aug 92 02:06:11 GMT
Organization: Indiana University, Bloomington

[SPARCstation IPX, X11R5, /bin/cc compiled.]


I am having some odd behavior when trying to set values in Xaw 
dialog widgets. I am doing this with

        static void
        set_dialog_value(w, value)
        Widget w;
        String value;
        {
            Arg arg;
        
            XtSetArg(arg, "value", value);
            XtSetValues(w, arg, 1);
    
            return;
        }


which works fine. 

With 9 dialog boxes (each with a label, a value (assigned with the above), 
and no buttons), things are fine.

When I add a 10th dialog widget and give it a label, it too displays
fine.

When I add a value to this widget (even ""), the values in most of the
rest of the dialog widgets are suddenly empty (at least they are 
displayed that way). This happens with Xaw3d too, though the set of
disrupted values is different.

Worse is to come... I have checked all the values I am passing around
and they all seem fine. I don't *think* I have any memory problems. The
problem I just described is not specific to the particular 10th dialog
widget. I can pick some set of 9, which will work, but then turning on the
10th one's (whichever this happens to be) value reproduces the problem.

If I add
        printf("dialog widget has value '%s'\n", XawDialogGetValueString(w));
to the above function after the XtSetValues() call, the correct strings
are printed for all ten widgets.

In case it matters, the dialog boxes live (with two command widgets) in
a form widget in a popup topLevelShell in the shell returned by 
XtAppInitialize.


I am a complete X novice, so I suspect the problem is mine, but of
course wonder if this is not some sort of memory problem on the other
side of the fence.

I'll try to make a small file that reproduces the problem.

In the meantime, any suggestions would be appreciated.
Terry Jones.


P.S. Thanks to those who helped with the resources problem I posted
     the other day. Things now seem to work as advertised.
Newsgroups: comp.windows.x
From: baem@cbnewsh.cb.att.com (brian.ae.meekings)
Subject: Home-grown window manager problem
Organization: AT&T
Distribution: na
Date: Thu, 27 Aug 1992 14:07:43 GMT
Keywords: window manager, XKillClient

We're using a home-grown widget set and window manager on a large
(~750,000 lines) project. There are currently no plans to upgrade
to a more standard platform. When we try to run off-the-shelf
applications under our window manager, they work most of the time,
except for one major annoyance - if we pop up a window (a menu, say),
and then exit that window, the whole application dies, instead of
just the window.
I'm not really familiar with window manager code, but it looks like
our window manager is calling XKillClient, just like olvwm does.
Does anybody have any ideas what the problem might be - if I know
what I'm looking for, I might be able to go in and fix the window
manager.

Brian Meekings
baem@mink.att.com
From: matt@tfs.com (Matthew Hom)
Newsgroups: comp.windows.x
Subject: Escape and Tab keys to modal dialog?
Keywords: motif dialog translations
Date: 26 Aug 92 00:08:34 GMT
Followup-To: poster
Distribution: comp.windows.x.intrinsics comp.windows.x.motif
Organization: TRW Financial Systems

I'm using Wcl and Motif in my X Window keying application. If anyone
can shed any light on this, I'd appreciate it. Thanks.

Our customer has requested a change in key assignments for the keying
application. One of the changes involves mapping the Escape key and
the Tab key. I've been using the key accelerator in the pulldown menus
as a convenient mechanism for doing this. The customer also wants
alternative keys to cause the same action (i.e. F9 and Shift+9). I use
translation tables to augment certain widgets by mapping these
alternative key sequences to activate callbacks for the corresponding
buttons in the pulldown menu.

Everything works fine except when my application modal dialogs are managed.
I augment the translations of the dialog to map certain key sequences
to my callbacks. The key sequences work for most keys except for Tab
and Escape. How come? Are these being consumed by the dialog? I tried
to override the translations for the dialog or list widget but I loose
to much functionality in the list widget (arrow keys, CR, etc.). 

*ListDialog*Translations: #augment\n\
Ctrl<Key>Q:     TfsActionActivateCallbacks( *QuitBtn ) \n \
Alt<Key>Left:   WcUnmanageACT( *ListDialog ) TfsActionPrevImage() \n\
Alt<Key>Right:  WcUnmanageACT( *ListDialog ) TfsActionNextImage() \n\
<Key>Tab:       TfsActionActivateCallbacks( *OopsBtn ) \n\
<Key>Escape:    WcUnmanageACT( *ListDialog ) TfsActionActivateCallbacks( *PassBtn ) \n\
<Key>:          TfsActionSelectListItem( *Number*Field1 )

The widget hierarchy for this dialog is"

	Form Dialog Widget
		List Widget

Is there a resource that I can set to allow Tab and Escape to get through
to my action procedures? I tried to augment the translations on the parent
of the ListDialog (ListDialog_popup) as well, but that has no effect. 

Please send responses to matt@tfs.com.

-- 
+-----------------------------------------------------------------------+
| These are my opinions and are not necessarily those of my employer.   |
+-----------------------------------------------------------------------+
| Matt Hom				matt@tfs.com			|
| TRW Financial Systems			(310)590-7510			|
| 200 Oceangate, Suite 1000						|
| Long Beach, CA 90802-4336						|
+-----------------------------------------------------------------------+
From: hori@okds1.osaka-kyoiku.ac.jp (hori)
Newsgroups: comp.windows.x
Subject: xterm clearscreen erases -sl; how to stop this?
Keywords: xterm vi scrolled lines
Date: 28 Aug 92 23:41:16 GMT
Reply-To: ben@crl.mei.co.jp
Organization: Osaka Kyoiku University

I like to use the -sl option in xterm, to keep a lot of lines of history
available to see.  But when I use vi (or emacs or any other command that
clears the screen), I lose the lines that were "cleared" from the
screen.

Is there any option to have those lines pushed up off the top of the
screen before the screen in cleared?  Maybe a termcap entry that should
be changed?

-Ben


Newsgroups: comp.windows.x
From: ware@organ.cis.ohio-state.edu (Peter Ware)
Subject: Re: What would this window obscure?
Originator: ware@organ.cis.ohio-state.edu
Organization: Ohio State Computer Science
	<1992Sep3.154113.10359@cam-orl.co.uk>
Distribution: comp
Date: Thu, 3 Sep 1992 18:55:01 GMT

In article <1992Sep3.154113.10359@cam-orl.co.uk> thg@cam-orl.co.uk
(Tim Glauert) writes:

   ...
   Actually, it isn't, since the server has a lot of freedom about
   exacty which areas it returns in an expose event. It is allowed to
   generate expose events which cover obscured parts of a window and
   it is allowed to generate expose events on areas which are already
   visible. It is legal within the protocol specification for the
   server to send a single expose event covering the whole of a window
   whenever any part of it is uncovered.
   ...

Pardon the technitrivia, but are you sure the server is allowed to
generate expose events for visible regions?  This would make it
impossible for an application using a graphics function like XOR to
function properly.

If you meant that it can generate an Expose event but must clear it to
the background then that sounds reasonable.  In fact, I know the MIT server
already does this if an operation causes more then 25 regions to be
exposed -- they get combined into one region and cleared to the background.

--pete
--
Pete Ware / Ohio State University /
           ware@cis.ohio-state.edu
           (614) 538-0965
Too bad the Nike slogan isn't "Just Do It Right" instead of "Just Do It"
Xref: sparky comp.windows.x:15712 comp.windows.x.motif:5858 comp.unix.sysv386:13680
From: kentkar@shambala.uucp (Kent Karrer)
Newsgroups: comp.windows.x,comp.windows.x.motif,comp.unix.sysv386
Subject: Need help compiling X source with ISC 3.0
Date: 27 Aug 92 05:19:26 GMT
Organization: The Conscious Interlude

I've had Interactive's X11R4 and Motif Development system since the end of
last year. I have been trying unsuccessfully since then to compile X source
games and etc that occassionally filter through various source groups. I
have RTFM many times but I have yet to successfully compile something that
will work with X and Motif on my system. The only gotcha that I came across
is a line in the release notes indicating to manually add -lnsl_s to the
end of the final link of the program. I'm not really sure what this means
but I have tried using it various ways without success. The docs are no
help in any way.

Will someone please enlighten me? 
-- 
[ A GREAT DEAL OF CHAOS IN THE WORLD occurs because people don't appreciate ]
[                      themselves. -- Chogyam Trungpa                       ]
[               "SHAMBHALA - The Sacred Path of the Warrior"                ]
[____uunet!seaeast!shambala!kentkar  /or/  uunet!polari!shambala!kentkar____]
Newsgroups: comp.windows.x
From: pmartz@dsd.es.com (Paul Martz)
Subject: Re: 256 grayscale levels with standard colormap
Reply-To: pmartz@dsd.es.com (Paul Martz)
Organization: Evans & Sutherland Computer Corp., Salt Lake City, UT
Date: Thu, 3 Sep 92 22:04:24 GMT

In article <1992Sep3.195418.6065@discus.technion.ac.il>, izeek@techunix.technion.ac.il (Ilan Aisic) writes:
> In article <1992Sep2.040959.16164@walter.cray.com> vincent@cadillac.cray.com (Vincent LE BARAZER) writes:
> > My first step was to Create a new colormap, allocate 256 levels of gray
> >pixels ( red = green = blue ), and install this colormap .
> >
> > ... but other X clients running on the same server do not like this new
> >colormap !
> 
> If you want to use a virtual colormap for your window, you will
> get the "colormap flashing" whenever you move your pointer into and out of
> your window (in an 8 planes server).  [ ... ]

Using "virtual colormaps" is not the cause of colormap flashing.
Colormap flashing is caused by the fact that some hardware platforms
only have one 256-entry colormap available.  Many graphics adaptors
are available which have several hardware colormaps. On these
adaptors, you can run many clients which each want to own 256 colors,
and rarely encounter colormap flashing.

I think the original poster needs to ask himself, "Is this really a
problem?" After all, the window manager will normally reinstall the
client's colormaps based on focus. But if it really is a problem, the
best solution is to acquire hardware with an adequate number of
hardware colormaps to support the clients which must own colormaps
simultaneously.
-- 

   -paul	pmartz@dsd.es.com
		Evans & Sutherland
From: ardai@zax.eda.teradyne.com (Michael Ardai)
Newsgroups: comp.windows.x
Subject: Remote Xwindows from sun to decstation and Lucida
Date: 27 Aug 92 17:17:12 GMT
Organization: Teradyne, Inc. Boston MA
Originator: ardai@zax


I am trying to run xvnews and have it display on a decstation (or a vaxstation)
and it keeps dying with problems locating the Lucida font (which we don't have
on the decstation.  The sun is running Openwin 3, and the decstationand 
vaxstations are running decwindows.  Any ideas what I should do?  I have 
already tried adding 
XVnews.textfont:      3
XVnews.listfont:      3
to the .Xdefaults on both the decstation and the sun without any help.

Thanks in advance.
/mike
-- 
\|/  Michael L. Ardai  N1IST   Teradyne EDA 
--- -------------------------------------------------------------------------
/|\  ardai@maven.dnet.teradyne.com
From: rjw@merlin.cvs.rochester.edu (Robert Wilson)
Newsgroups: comp.windows.x
Subject: X ftp programs
Date: 3 Sep 92 18:27:41 GMT
Organization: University of Rochester, Rochester NY

I don't seem to be having much luck with getting X ftp programs to compile.

I got my hands on Ftptool4.3, but it needs XView.

I downloaded xftp, but it needs widgets with prefix "Xw" (no, not "Xaw"),
which I've never even _heard of_ before.

One machine I have has the Athena widgets.  Another has Motif.  Any
recommendations for ftp programs for either of these toolkits?

-Robert
 rjw@cvs.rochester.edu
Newsgroups: comp.windows.x
From: anthony@kurango.cit.gu.edu.au (Anthony Thyssen)
Subject: Re: Problems with stray xterm client processes...
Organization: Griffith University, Brisbane, Australia.
Date: Tue, 1 Sep 92 07:22:31 GMT

espiritu@cgi.com (Rex Espiritu) writes:
| This problem arises when a user logs out of one of our Sun SPARCstations
| where they had "xterm" clients running when they logged out.
|
| What happens then is the "xterm" clients of another user (on the same
| machine) seems to then start sharing the same pseudo device that the
| other user had.  The second user can do a "whoami" and they will get a
| response of the other user.  It seems that every other command is
| executed under the other users "uid".

Yes we have been experancing the same problem. However we also discovered
that if a X11 R5 xterm is killed using a ``delete window'' signal from the
window manager any process (other than the shell itself) that was running
under that xterm is also left behind, to the detrement of anyone that
picks up the old pty later.

If a ``kill window'' signal is used however, the xterm cleans up properly.
Under revision 4 the xterm ignores the ``delete window'' and only exits on
a kill window or exit of the client shell, so no problem was experanced.

I have reported this a number of times but have yet to recieve even a
recept of the report.


  Anthony Thyssen - (CIT, Griffith University)       anthony@cit.gu.edu.au
------------------------------------------------------------------------------
   Judgment comes from experience: experience comes from poor judgment.
------------------------------------------------------------------------------
Newsgroups: comp.windows.x
From: fmhv@minerva.inesc.pt (Fernando Manuel Vasconcelos)
Subject: Re: 256 grayscale levels with standard colormap
Organization: INESC, Lisboa, Portugal
Date: Fri, 4 Sep 1992 07:27:13 GMT

In article <1992Sep3.220424.26925@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:

>I think the original poster needs to ask himself, "Is this really a
>problem?" After all, the window manager will normally reinstall the
>client's colormaps based on focus. But if it really is a problem, the
>best solution is to acquire hardware with an adequate number of
>hardware colormaps to support the clients which must own colormaps
>simultaneously.
>-- 
>
>   -paul	pmartz@dsd.es.com
>		Evans & Sutherland


Right. The small detail being that you need the dolars to get them ... :-)
-- 
Fernando Manuel Hourtiguet de Vasconcelos ( INESC ) 
Email:  fmhv@inesc.inesc.pt  Phone: +351 (1) 3100216 Fax: +351(1)525843 
Adress: Rua Alves Redol No 9, sala 208 Apartado 10105 
	1017 Lisboa CODEX - Portugal 
Newsgroups: comp.windows.x
From: gary@vitellocmc.ca (Gary Braida)
Subject: SUMMARY:  Converting Sun 3/60 to X terminal
Reply-To: gary@scorpio.ic.cmc.ca
Organization: Canadian Microelectronics Corporation
Distribution: can
Date: Thu, 3 Sep 1992 15:06:20 GMT

Thanks to all who resonded to my posting a fews weeks ago regarding
converting Sun 3/60's to X terminals.  The method of choice seems to
be a configuration using Xkernel.  Xkernel is readily available from
a number of ftp sites.  I scooped the 4LAZY.sun3.tar.Z version of
Xkernel from sol.ctr.columbia.edu.  I haven't tried it out yet and don't
plan on experimenting with it for a few months but the Xkernel users who
responded to my posting seemed pleased with their configurations.

Again, thanks to those who replied.

Regards   

-- 

Gary Braida             |     Canadian       |       ******  *******  ******
email:  braida@cmc.ca   |  Microelectronics  |      *       *  *  *  *
phone:  (613) 545-2914  |    Corporation     |     ******  *     *  ******
Newsgroups: comp.windows.x
From: daniel@cassidy.EuroPARC.Xerox.COM (Ian Daniel)
Newsgroups: comp.windows.x
Subject: Sun Type 5 Keyboard
Date: 28 Aug 92 09:25:53 GMT
Organization: Rank Xerox


Hi,


	We recently took delivery of 2 Sun IPX machines, and they have the "New" type 5 keyboard.....funny, looks like a PC keyboard to me....?

	Anyway, I would really like to be able to use the machine with X11R5, and can't because the keys are mapped differently to the "old" type 4 keyboard. I found nothing in the fixes for R5, so if anyone has any ideas on how to get around the problems , and get at least most of the functionality I'd appreciate it. Also, these are UK type 5s' just to make it even worse!!!



Thanks,


Ian (what was wrong with the type 4!!!???) Daniel.
Newsgroups: comp.windows.x
From: pands@cix.compulink.co.uk (P & S Ltd - Accounts Dept)
Subject: Information please
Reply-To: pands@cix.compulink.co.uk
Date: Wed, 26 Aug 1992 09:21:13 +0000

Does anyone out there in the big wide world know of an X-emulator which
runs on a DOS box but *replaces DOS*?  A strange request I know,  but
there's this company with an enormous investment in DOS boxes,  and they're
heading towards Unix and X.  Running X on the desktop isn't practical as
the users won't be technically aware enough to handle it (even the new
SVR4.2 is out I'm afraid).

I know about X emulators which sit on top of DOS and/or Windows,  but I'm
looking for one which doesn't need either.

TIA

Paul

--------------------------------< Who 'zat >-------------------------------
      Paul Wilson, P-and-S Ltd, P O Box 54, Macclesfield, SK10 5EH, UK
        [Email: pands@cix.compulink.co.uk]   [Phone: +44 625 502224]
---------------------------------------------------------------------------
Newsgroups: comp.windows.x
From: deveau@oceanroutes.ns.ca ("Terry J. Deveau")
Subject: Re: who needs those silly ampersands anyway?
Organization: Oceanroutes Canada Inc.
Date: Mon, 31 Aug 1992 15:34:52 GMT

huho@banruc60.bitnet writes:

> I'm writing an application using the Athena widgets (R5) and I'm a bit puzzled
> about one of the examples in contrib/examples/Xaw.
> The example I'm refering to is xtext.c. The following  lines are used to
> obtain the string from an asciiTextWidget named text.
> 
>    Arg args[1];
>     String str;
> 
>     XtSetArg(args[0], XtNstring, &str);
>     XtGetValues(text, args, ONE);
> 
> My question is :
> Is it necessary to use &str as an argument to XtSetarg? str is of type String,
> ,so it's already a pointer. Wouldn't  str without the & be sufficient?
> 
Yes it is necessary.  This is a C question not an X question.  Pointers
are not generic in C.  Pointers to one type of variable are different
from pointers to another type of variable.  ANSI C generates an error
message when your suggestion is attempted.  More significantly, leaving
off the & in the function call will result in the current contents of
the str variable (which is garbage because you haven't initialized it)
being used as the memory address in which to deposit the XtGetValues
result (which in this case is a String pointer).  Writing to a garbage
address generally produces a Segment Violation (unless you are very
unlucky). ... Terry
Newsgroups: comp.windows.x