HDTenEightyP/NetNews huggingface dataset:
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: How to press CAPSLOCK ?
Date: 12 Sep 92 00:45:09 GMT
Distribution: fj
Organization: McGill Research Centre for Intelligent Machines

Date: Fri, 11 Sep 92 02:44:58 GMT
Message-Id: <1992Sep11.024458.15114@thunder.mcrcim.mcgill.edu>
Newsgroups: comp.windows.x

In article <151710002@hpuerca.atl.hp.com>, rlr@hpuerca.atl.hp.com (Ricky Ralston) writes:

> How can I logically press the Caps Lock key.

(I assume that's a question, in spite of the non-question punctuation.)

> I need the functionality of having a widget keyboard.  (ie. When I
> press the button labeled "Caps" the Caps Lock toggles - just like it
> was pressed from the "real" keyboard.)

What you want is not normally possible.  It would take an extension,
and as far as I know the extension doesn't exist - though it's just
occurred to me that the input synthesis extension (whatever it's
called) might be able to do it.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Wanted: Disabling Window Decorations
Date: 11 Sep 92 23:36:14 GMT
Distribution: fj
Organization: McGill Research Centre for Intelligent Machines

Date: Fri, 11 Sep 92 02:06:46 GMT
Message-Id: <1992Sep11.020646.13542@thunder.mcrcim.mcgill.edu>
Newsgroups: comp.windows.x.motif,comp.windows.x

In article <1992Sep8.204843.5424@Rapnet.Sanders.Lockheed.Com>, cupak@rapnet.sanders.lockheed.com (John J Cupak Jr CCP) writes:

> How do I create a popup dialog box without the "decorations"?

> I don't want the user to be able to resize, minimize, maximize, move,
> or use the menu to close the dialog box.

The only sure way is to make it override-redirect.  (Well, that's not
quite *absolutely* sure, but any window manager that meddles with
override-redirect windows is just plain broken.  If you *must* be
*absolutely* sure, grab the server before doing anything else, make it
an override-redirect window, and don't ungrab the server 'till you're
done.)  Anything else is WM-dependent; some window managers make this
easier than others.  You can try making it a transient (see the ICCCM's
description of WM_TRANSIENT_FOR); this will sometimes make the window
manager give it lighter treatment...or perhaps not.  It's up to the WM
and the user.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: tmcconne@sedona.intel.com (Tom McConnell~)
Newsgroups: fj.mail-lists.x-window
Subject: legal issues with motif on RS/6000
Date: 12 Sep 92 18:52:17 GMT
Distribution: fj
Organization: Intel Corporation

Date: 11 Sep 92 22:21:17 GMT
Message-Id: <1992Sep11.222117.23887@ichips.intel.com>
Newsgroups: comp.unix.aix,comp.windows.x


  Howdy.

  I have been wondering, what are the legal implications of porting
motif applications using the motif libraries that came with the
RS/6000?

  My current understanding is that I can port anything I like, as long
as I do not give away or sell the source code for motif, or give away or
sell the object code or library of motif.

  In the "Master Software License Agreement Supplement" of the OSF for 
the "MOTIF User Environment", which you get when you purchase motif, 
it states in the Notes section:

  (1) There shall be no object code fee payable for use or distribution
     of "Run Time" copies of the Licensed Programs or the Developer's
     Toolkit.

    A "Run Time" copy is some application that was built using the 
motif libraries, but no other program can use that application to
get at the motif binaries (paraphrasing).

  I take this to mean that I can port any motif client I want, as long
as I don't give away or sell motif.

  Is this the correct interpretation? Can I port any motif clients I
want against the libraries on the RS/6000?

  Thanks for your time.

    Cheers,

    Tom McConnell
-- 
 Tom McConnell          |     Internet: tmcconne@sedona.intel.com
 Intel, Corp. C3-91     |     Phone: (602)-554-8229
 5000 W. Chandler Blvd. | The opinions expressed are my own. No one in 
 Chandler, AZ  85226    | their right mind would claim them.
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: GUIs Considered Harmful
Date: 12 Sep 92 01:02:49 GMT
Distribution: fj
Organization: McGill Research Centre for Intelligent Machines

Date: Fri, 11 Sep 92 02:40:42 GMT
Message-Id: <1992Sep11.024042.14985@thunder.mcrcim.mcgill.edu>
Newsgroups: alt.religion.computers,comp.windows.misc,comp.windows.news,comp.windows.x,comp.human-factors

In article <id.P72T.O1C@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> In article <1992Sep6.060556.14670@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>> In article <NEERI.92Sep1141334@iis.ethz.ch>, neeri@iis.ethz.ch (Matthias Neeracher) writes:
>>> In article <YANDROS.92Sep1003712@j-g-ballard.MIT.EDU> yandros@Athena.MIT.EDU (Chad Phillip Brown) writes:
>>>> (Does anyone know why there isn't a magic key sequence to get to
>>>> the menubar, for instance?)
>> "get to"?  The menubar is not a keyboard-useful device, unless you
>> want to arrow-key step through everything.
> Or unless you're running Microsft Windows. In which case you can step
> through the menus selecting the underlined letters with the ALT key
> depressed.

Now *that* is sensible, and very much the sort of thing I would like to
see everywhere.  Let someone who knows the sequences use the keyboard.
Let those who wish to use the mouse.  (Even better, of course, to let
people configure their own preferred keyboard sequences.  But half a
loaf is better than none.)

Aak, I'm saying something nice about Windows!  Quick, someone pinch me!

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
Newsgroups: fj.mail-lists.x-window
Subject: Re: tutorial of imake
Date: 15 Sep 92 21:36:59 GMT
Distribution: fj
Organization: Ada Joint Program Office

Date: Tue, 15 Sep 1992 04:23:17 GMT
Message-Id: <1992Sep15.042317.158@sei.cmu.edu>
Newsgroups: comp.windows.x

Hi Hang,

>
>
>Hi: everybody:
>
>Does anyone know where to get some tutorials of how to write imake and
>makedepend file from X? I hereby thank you for the hint. Please mail me
>at cs000hf@selway.ut.edu or hf@huckle.cs.umt.edu
>

I've got the tutorial notes from Todd Brunhoff's tutorial on Imake at
Xhibition '90 (Todd wrote Imake).  If you send me email after Oct 1 to
remind me, I'll photocopy it and send it to you.  (I don't get back
into my office until then).  The man page on imake is skimpy, and
there's not enough documentation anywhere to fully describe it well.
If you scan back issues of X Resource and X Journal, you'll find
some information also.

makedepend is just a program which will append file dependencies
to the end of a Makefile.  It parses for #include directives in
the code specified.  The man page on makedepend is sufficient
to use it effectively.  Usually, people put a "depend" rule
in their Makefile which will update the makefile when they 
invoke the makefile with "make depend".

later

John
John Goodsen                              Ada Joint Program Office
RADSoft Labs                              PCIS Programme
jgg@evb.com                               goodsenj@ajpo.sei.cmu.edu
800-877-1815


-- 
John Goodsen                              Ada Joint Program Office
jgg@evb.com                               PCIS Programme
800-877-1815                              goodsenj@ajpo.sei.cmu.edu
From: drand@spinner.osf.org (Douglas Rand)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Transparent windows
Date: 10 Sep 92 11:58:38 GMT
Distribution: fj
Organization: Open Software Foundation

Date: 9 Sep 92 23:19:43 GMT
Message-Id: <DRAND.92Sep9181943@spinner.osf.org>
Newsgroups: comp.windows.x

In article <DRAND.92Sep9105634@spinner.osf.org> drand@spinner.osf.org (Douglas Rand) writes:

   In article <9209081631.AA04622@uahcs2.cs.uah.edu> ldawes@uahcs2.cs.uah.EDU (Lisa Dawes, Computer Science Dept., Univ. of Alabama-Huntsville) writes:

      How are transparent window backgrounds created and/or implemented.
      Is there a color index for transparent colors.  Where is a good 
      source of documentation concerning this?

   There aren't any in standard X (to the best of my knowledge).  A 
   window can have CopyFromParent as background,  but that isn't 
   transparency,  and the X color model has no such notion.  Most
   display hardware doesn't either.

I should point out that I'm responding to his presumed intend of
overlaying "transparent" graphics.  If you just want a fully
transparent window that can not be drawn into,  an Input only window
is dandy.
--
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
From: tjt@blink.att.com (Tim Thompson)
Newsgroups: fj.mail-lists.x-window
Subject: Re: GUIs Considered Harmful
Date: 7 Sep 92 20:09:11 GMT
Distribution: fj
Organization: AT&T

Date: Mon, 7 Sep 1992 17:17:47 GMT
Message-Id: <tjt.715886267@wink>
Newsgroups: alt.religion.computers,comp.human-factors,comp.windows.misc,comp.windows.news,comp.windows.x

smr@hitkw14.pki-nbg.philips.de (S.Riehm) writes:
>I figure that GUI's are inherently non-extensible, even those
>wonderful window manager that allow you to define your own pop-up
>menus and so on, can you make this menu beep when it pops up? can you
>make this tear off menu always sit at the back of the window stack
>unless called up explicitly? 

I disagree that GUI's are inherently non-extensible.  It's clear that
very very few GUI's are written to be extensible (in more than trivial ways),
but I think this has more to with the fact that it takes a lot of
up-front effort to do it right.  People are too interested in
getting quick results, so they don't have the time to invest in
building an underlying tool that will make their GUI properly extensible.
The initial investment can pay off handsomely on the other end, but
that is a very tough concept to sell.

Ideally, there should be generic tools that make extensible GUI's easy
to build.  Tk (a Tcl-based shell) is the first tool I've seen that is
a significant step in the right direction.  If someone built a window manager
out of Tk, the extension you describe above would be easily possible.
A window manager built out of Tk has in fact been suggested.

As a hobby project, I'm building a GUI with an awk-like language that
has multi-tasking and multi-window support.  The GUI is fully-extensible,
because the entire GUI (and underlying MIDI application) is implemented with
the awk-like language, all the way down to handling and forwarding individual
mouse and window events.  Interestingly, I'm finding that multi-tasking
within the language has been critically-important in building the GUI.
I've come to the belief that any language with a single thread of control
is at a severe disadvantage for GUI work.

      ...Tim Thompson...AT&T Bell Labs/Holmdel/NJ...tjt@blink.att.com...
From: tjones@moose.cs.indiana.edu (terry jones)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Reading text from Athena (Xaw) asciiTextWidgets ?
Date: 11 Sep 92 03:05:28 GMT
Distribution: fj
Organization: Indiana University, Bloomington

Date: 10 Sep 92 16:15:08 GMT
Message-Id: <1992Sep10.111516.16280@news.cs.indiana.edu>
Newsgroups: comp.windows.x

In article <9SEP199213355388@portal.lasc.lockheed.com> le01156@portal.lasc.lockheed.com (Jeff Sheffel @ x2016) writes:
>I have unsuccessfully tried to read (retrieve) the user
>modified text from an Athena asciiTextWidget.  I looked
>at other example programs (xless and xdbx) to see how it
>was done.  Here is a section of (pseudo) code:
>
>
>When I tried this, buffer.ptr = '\0' and buffer.length
>was zero.  The standard X documentation is weak in the area
>Athena widget usage and particularly in the explanation of
>"text sources and sinks" which appear to be used in the
>above example.

I have no idea if there is an accepted way to do this, but I had exactly 
the same problem the other night and was also frustrated at the 
documentation. I ended up remembering that there is such a widget in a dialog
and so I went to the source to see how XawDialogGetValueString() got
the string from its ascii widget. What I saw was effectively:

	String text_widget_contents;
	String value;
	Args args[1];

	XtSetArg(args[0], XtNstring, &value);
	XtGetValues(text_widget, args, 1);
	text_widget_contents = strdup(value);

Maybe someone can advise whether this is standard practice?

Hope this helps,
Terry.
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Making big fonts, how to start?
Date: 5 Sep 92 00:31:22 GMT
Distribution: fj
Organization: McGill Research Centre for Intelligent Machines

Date: Fri, 4 Sep 92 08:57:56 GMT
Message-Id: <1992Sep4.085756.17778@thunder.mcrcim.mcgill.edu>
Newsgroups: comp.windows.x

In article <123@trident.datasys.swri.edu>, noren@trident.datasys.swri.edu (Greg Noren) writes:

> I want to make a few "large" fonts - something on the order of 128
> pixels tall by 64 pixels wide at 100 dpi, or even 64 tall by 32 wide
> at 200 dpi.

> We're using R4 on [...].  I've got access to R5, but my project team
> wants to stay with R4 for now as that's what our customer is running.
> So, no R5 servers.

> I'd like to minimize the effort and time required to create these
> fonts.

In that case, what you might do is grab getbdf.  Point it at your R5
server and ask for a big size of some scalable font.  Feed the
resulting BDF file to your R4 server (perhaps first tweaking the XLFD
info, if it's not already correct) and everything should be cool: once
you've got the BDF file, it'll work fine with R4; R5 is not needed past
that point.  (getbdf is something I wrote.  It can be fetched from
larry.mcrcim.mcgill.edu (132.206.1.1), /X/getbdf.c.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: strzelin@sscdaq.phy.bnl.gov (Bob Strzelinski)
Newsgroups: fj.mail-lists.x-window
Subject: Re: help - DEC.5000 / twm / .X11Startup
Date: 13 Sep 92 09:45:59 GMT
Distribution: fj
Organization: Physics Dept., Brookhaven National Laboratory

Date: Fri, 11 Sep 1992 15:04:58 GMT
Message-Id: <1992Sep11.150458.27015@bnlux1.bnl.gov>
Newsgroups: comp.unix.ultrix,comp.windows.x

In article <1992Sep9.100638.8758@vax.oxford.ac.uk>, nagrwb@vax.oxford.ac.uk writes:
|> On logging in to a DECStation5000/200 I have sitting at my desk at
|> the moment I would like to automatically:
|>   kill the DecWindow Manager
|>   use twm
|>   set a few friendly X clients
|>   start-up epoch (which resides on another host) in an iconified state
|>   have the DEC Session Manager and DECterm console window iconified
|> 
|> I'm a bit of a novice at this sort of thing so here's my .X11Startup file
|>   
|>    # Kill the DecWindow Manager
|>    kill -9 `ps -ax | grep dxwm | grep -v grep | awk '{ print $1}'` 
|>    # Use the Tab Window Manager (is nicer anyway no?)
|>    twm &

A simpler way to accomplish this much of your task is to include this line in
your .Xdefaults file (it's the first line in my file but I'm not sure whether
that is important):

sm.windowManagerName:           /usr/bin/X11/twm

This will startup twm for you (or you can substitute some other wm) rather than
dxwm.

///////////////////////////////////////////////////////////////////////////////

Bob Strzelinski
strzelin@sscdaq.phy.bnl.gov

///////////////////////////////////////////////////////////////////////////////
From: mamros@athena.lkg.dec.com (Shawn Mamros)
Newsgroups: fj.mail-lists.x-window
Subject: Re: help - DEC.5000 / twm / .X11Startup
Date: 12 Sep 92 12:28:48 GMT
Distribution: fj
Organization: Digital Equipment Corporation

Date: 11 Sep 92 14:07:05 GMT
Message-Id: <43017@athena.lkg.dec.com>
Newsgroups: comp.unix.ultrix,comp.windows.x


If you don't want to use the Session Manager, take a look at the man page
for login(1).  You'll see the following:

     -C string           Allows the system to specify a command to be run
                         using the user's shell.  This option causes a user
                         shell -c string to be exec'ed.

Then take a look at the :0 entry for /etc/ttys, and you'll see something
like the following:

:0 "/usr/bin/login -P /usr/bin/Xprompter -C /usr/bin/dxsession -e" none on secur
e window="/usr/bin/Xws"

Given those two pieces of information, it's fairly easy to use "something
else" in place of /usr/bin/dxsession in the :0 ttys entry, where, once
"something else" exits, then the login session is terminated.

-Shawn Mamros
E-mail to: mamros@athena.lkg.dec.com
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Free software and the future of support for Diamond products
Date: 8 Sep 92 10:10:29 GMT
Distribution: fj
Organization: Kithrup Enterprises, Ltd.

Date: Tue, 08 Sep 1992 09:33:00 GMT
Message-Id: <1992Sep08.093300.898@kithrup.COM>
Newsgroups: comp.unix.sysv386,comp.windows.x,comp.os.linux,comp.os.mach,comp.unix.bsd

In article <1992Sep7.133347.4433@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>1) Calling BIOS from a multitasking OS is trick, dangerous, and impossible
>   for those of us running SVR3/4

An interesting way to get around all of those:  set up a v86 process that
calls the BIOS routines for you.  It can be done, and I've seen it (not for
the card in question, however), although I don't recall enough to make any
claims about performance.

It probably requires some kernel help, however.

There's more than one way to skin a cat, remember!

-- 
Sean Eric Fagan  | "You can't get lost in one room, no matter how
sef@kithrup.COM  |  little effort you make to learn your way around."
-----------------+    -- William E Davidsen (william@crd.GE.COM)
Any opinions expressed are my own, and generally unpopular with others.
From: mramos@dtc.uvigo.es (Manuel Ramos Cabrer)
Newsgroups: fj.mail-lists.x-window
Subject: Unsubscribe
Date: 7 Sep 92 13:46:00 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: Mon, 7 Sep 92 13:22:19 PDT
Message-Id: <9209072022.AA02392@sil.dtc.uvigo.es>


	Please unsubscribe me. Thank you.
From: aoyama@astec.co.jp (Aoyama Hisao)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Problems with R5-i18n and scalable Kanji fonts
Date: 5 Sep 92 00:42:07 GMT
Distribution: fj
Organization: ASTEC, Inc. Tokyo, Japan

Date: Fri, 4 Sep 1992 08:14:17 GMT
Message-Id: <AOYAMA.92Sep4171411@hirame.astec.co.jp>
Newsgroups: comp.windows.x,fj.windows.x

In article <WPM.92Sep3200854@exile.is.morgan.com>wpm@is.morgan.com
	(W. Phillip Moore) writes:

   This is a subtle and odd problem, and probably one that R5 users who are
   *not* taking advantage of the i18n functionality will not see.

Well, it looks like an old fontlib bug, not related to Xaw.
It might be fixed in one of public patches, but I'm too lazy
to confirm it. Sorry.

   QUESTION:  How can one remove the scalable font and/or configure ones fonts
   such that this is the LEAST prefered (i.e. last possible match) rather than
   the first for 14pt font sizes??

Try again after removing FILE_NAME_ALIASES and/or a line for
k14 from font/misc/fonts.aliases. It would work if the
problem is the one I suppose.

   QUESTION:  Why is this font so ugly??

Bitmap-scaled font is always ugly :-)

   QUESTION:  Am I the first one to experience this problem??  Considering the
   wide use of the i18n features, especially in Asia, I would be very
   suprised.  

Probably i18n is not used so widely as you think, since we
don't need multi-lingual capabilities for day-to-day works.
At least, bi-lingual is enough for me.

   Note in Japanese for fj.windows.x readers:

   $@1Q8l$G%]%9(J$@%H$7$F:Q$_$^$;$s!#K\Ev$K0J>e$NLdBj$rF|K\8l$G(J fj.windows.x $@$GEj9F(J

Make sure the kanji-code of outgoing message is jis.
-- 
----
Hisao Aoyama						 $B@D;3(B $B>0IW(B
ASTEC, Inc.					  $B!J3t!K%"%9%F%C%/(B
aoyama@astec.co.jp
From: joet@dcatlas.dot.gov (Joe Trott)
Newsgroups: fj.mail-lists.x-window
Subject: Re: GUIs Considered Harmful
Date: 6 Sep 92 09:15:52 GMT
Distribution: fj
Organization: U.S Dept. of Transportation

Date: 4 Sep 92 14:23:24 GMT
Message-Id: <1992Sep4.142324.6554@dcatlas.dot.gov>
Newsgroups: comp.windows.x,comp.windows.misc,comp.human-factors

ematias@dgp.toronto.edu (Edgar Matias) writes:

>The *real* problem is that the keyboard is a two-handed device.
>Engelbart's original intent was that the mouse be used in conjunction
>with a one-handed keyboard.  Unforturnately, most systems do not come
>with one-handed keyboards.  Fortunately, you don't need to buy one to
>achieve the same thing.  There is a software solution to this problem...

I suppose this could work, and fairly well.  I've read about a number of
one-handed alternate input methods.  Unfortunately, it has been a dozen
years since I might have tried something like that.  I have lost
_considerable_ coordination in my left hand (although I still manage 40-50
wpm even on a bad day).  The point of this is something that I am finally
beginning to see in this thread.  *People are Different*.  It may be 'fun'
to enjoy a good flamefest from time to time, but some of the arguments here
are of random validity, depending on to whom they are applied.

This of course won't stop me from a mild slam at the gooey proponents.  I
don't think anyone is attempting to defend the use of GUIs in *applications*
that warrant them, such as graphics tools.  It seems pretty clear to me
that the argument concerns the _operating system_ interface; i.e. how we
run our computers, _not_ individual applications.  Who knows; maybe there's
an application out there whose "best" interface would be a row of
thumbwheels.  I don't think anyone would argue that thumbwheels should
thus also be used as the operating system interface (now watch somebody
try...:-)).  So you needn't waste bandwidth defending the GUI as the
appropriate interface to a Paint program.  

It also seems you are picking on the CLI for faults not of CLIs in general,
but of the lack of standards across CLIs.  That problem is true of GUIs
too, so that one ought to be a wash.  It isn't a CLI problem just because
one uses "erase", another: "kill", and a third uses "destroy" when what they
all mean is "delete (a file)".

-JTT

There can be no undefeated Evil when Reason prevails.
From: gasco!s1w@bloom-beacon.MIT.EDU (Scott A. White  x5947)
Newsgroups: fj.mail-lists.x-window
Subject: Understanding the X Error Handler Messages
Date: 11 Sep 92 23:19:57 GMT
Distribution: fj
Organization: Northwest Natural Gas, Portland, OR

Date: 10 Sep 92 20:45:04 GMT
Message-Id: <1992Sep10.204504.29428@gasco.com>
Newsgroups: comp.windows.x

Greetings!

I am developing a Motif application and sometimes get
some messages from the X Error Handler.  I know one
cause... calling XtVaSetValues in textFields within 
the text field's act callback.  However this on has 
me stumped. I perused our archived version of the FAQ, 
and checked Vols I and II, but to no avail.  

X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  62 (X_CopyArea)
  Minor opcode of failed request:  0
  Resource id in failed request:  0xc00148
  Serial number of failed request:  4346
  Current serial number in output stream:  4355

Would someone please e-mail me an interpretation
of this, and suggestions about how to debug this
problem  (besides "Fix your pixmap/window parameter").

many thanks!