HDTenEightyP/NetNews huggingface dataset:
From: todd@fred.dfrf.nasa.gov (Todd Vernon)
Subject: Re: HELP - Vertical Text
Reply-To: todd@fred.dfrf.nasa.gov (Todd Vernon)
Organization: NASA
Date: Wed, 27 Jan 1993 00:33:01 GMT

In article <C14FLx.Fp6@csn.org>, tom@teal.csn.org (Tom Schutter) writes:
> We do some vertical text the hard way, basically by creating a pixmap,
drawing
> text into the pixmap, using XGetImage to copy the pixmap to an image,
using
> XGetPixel and XPutPixel to rotate the image into another image, and
then
> XPutImage to put the result into the final pixmap (window).
> 
> It is a pain, but it works. (Not quickly).

Another way that is often a little faster is to create two pixmaps, image
the string into one then do XCopyArea's 1 pixel by 1 pixel into the
new pixmap applying the transform.  For me it was quite a bit 
faster.  Blow the first pixmap away and use the second to update the
screen during refresh....

-todd
From: powell@newyork.crd.ge.com (Powell)
Newsgroups: comp.windows.x.motif
Subject: Need Widget to continually display contents of a growing file
Date: 21 Jan 93 16:09:34 GMT
Reply-To: powell@crd.ge.com
Organization: GE Corporate R&D Center, Schenectady, NY

The FAQ shows how to import a static file into a scrollable text widget.
I have a need to have the text in the scrollable widget continually
updated as the file changes. For example, I have a 3rd
party package that writes continually to a file over a period
varying from 10 minutes to one week. I am trying to wrap
a motif interface around this package. I can start
the package from my Motif UI. My problem is how can I attach
a scrollable text widget to the file created by the 3rd party package
(which I only have the execuable) that
continually updates itself as the file grows. Furthermore, while
the file is growing can I still scroll back and forth within the
text widget.



Regards
Dave
From: buzz@bear.com (Buzz Moschetti)
Newsgroups: comp.windows.x.motif
Subject: Re: Using Pixmaps
Date: 25 Jan 93 13:12:23 GMT
Reply-To: buzz@bear.com (Buzz Moschetti)
Distribution: usa
Organization: Bear, Stearns & Co. - FAST
In-reply-to: ross@loral.cts.com's message of 21 Jan 93 01:01:27 GMT

In article <1993Jan21.010127.7091@loral.CTS.COM> ross@loral.cts.com (Robert Ross) writes:
>  I'm trying to get a Pixmap (not Bitmap) to be displayed as the labelPixmap
>  on a XmPushButton.  The XmNlabelPixmap resource expects its argument to
>  be of type Pixmap.  I need to do the Pixmap creation during runtime, because
>  the labelPixmap may vary during the life of the application.
>  [...]
>  a string (ie. "my_pixmap.xpm") to Pixmap.

The string type conversion built into the XmNlabelPixmap resource assumes
that the string names a file in standard X11R4 _bitmap_ format:

	...,
	XtVaTypedArg, XmNlabelPixmap, XmRSTring,
	    "my_bitmap.bm", strlen("my_bitmap.bm") + 1,
	...

Motif widgets do not know how to convert XPM format color pixmaps.  If 
you are using XPM, simply use the function

	Pixmap p = XpmReadFileToPixmap();

If you're not using XPM, use it!  :-)  It is available on
export.lcs.mit.edu and avahi.inria.fr
Newsgroups: comp.windows.x.motif
From: kobet@xsun2a.ct.picker.com (Harry J Kobetitsch)
Subject: XmSelectionBox Problem
Organization: Picker International, Inc.
Distribution: na
Date: Wed, 27 Jan 1993 18:51:43 GMT


I am having a problem changing colors on the XmSelectionBox
scroll bar. Here is a part of a program that I am having trouble
with. It seems that when the callback is activated a core dump 
is performed because XmDIALOG_WORK_AREA does not exist.
Can anyone help me find a way to change the color of the
scroll bar ?

    argcnt = 0;
    XtSetArg(args[argcnt], XmNx, 183); argcnt++;
    XtSetArg(args[argcnt], XmNy, 325); argcnt++;
    XtSetArg(args[argcnt], XmNwidth, 500); argcnt++;
    XtSetArg(args[argcnt], XmNheight, 110); argcnt++;
    dialogShell12 = XtCreatePopupShell("dialogShell12",
		xmDialogShellWidgetClass,
		form39,
		args,
		argcnt);

    XtInitializeWidgetClass(xmDialogShellWidgetClass);
    argcnt = 0;
    XtSetArg(args[argcnt], XmNx, 516); argcnt++;
    XtSetArg(args[argcnt], XmNy, -586); argcnt++;
    XtSetArg(args[argcnt], XmNwidth, 272); argcnt++;
    XtSetArg(args[argcnt], XmNheight, 374); argcnt++;
    xmDialogShell12 = XtCreatePopupShell("xmDialogShell12",
		xmDialogShellWidgetClass,
		form39,
		args,
		argcnt);

    XtInitializeWidgetClass(xmSelectionBoxWidgetClass);
    argcnt = 0;
    XtSetArg(args[argcnt], XmNokLabelString, (xmstr[3]=XmStringCreateLtoR(
		"OK", XmSTRING_DEFAULT_CHARSET))); argcnt++;
    XtSetArg(args[argcnt], XmNhelpLabelString, (xmstr[4]=XmStringCreateLtoR(
		"Dismiss", XmSTRING_DEFAULT_CHARSET))); argcnt++;
    XtSetArg(args[argcnt], XmNmustMatch, True); argcnt++;
    XtSetArg(args[argcnt], XmNx, 0); argcnt++;
    XtSetArg(args[argcnt], XmNy, 0); argcnt++;
    XtSetArg(args[argcnt], XmNwidth, 272); argcnt++;
    XtSetArg(args[argcnt], XmNheight, 374); argcnt++;
    selectionBox = XtCreateWidget("selectionBox",
		xmSelectionBoxWidgetClass,
		xmDialogShell12,
		args,
		argcnt);
    XmStringFree( xmstr[0] );
    XmStringFree( xmstr[1] );
    XmStringFree( xmstr[2] );
    XmStringFree( xmstr[3] );
    XmStringFree( xmstr[4] );


    XtAddCallback(selectionBox, XmNhelpCallback, SelectionListDismissCB,
				 (XtPointer)0);
    XtAddCallback(selectionBox, XmNnoMatchCallback, PhysicianListNoMatchCB,
		 		(XtPointer)0);
    XtAddCallback(selectionBox, XmNokCallback, PhysicianSelectionListOkCB,
				(XtPointer)0);


PhysicianSelectionListOkCB(w, client, call)
Widget w;
XtPointer client;
XtPointer call;
{
    XtVaSetValues(XmSelectionBoxGetChild(w, XmDIALOG_LIST),
		XtVaTypedArg, XmNforeground, XmRString, "white",
			strlen("white") + 1,
		NULL);
}




Thanks
From: vijay@gateway.iitb.ernet.in (Vijay Talati)
Newsgroups: comp.windows.x.motif
Subject: FAQ location
Date: 21 Jan 93 13:10:48 GMT
Distribution: inet
Organization: The Internet


Recently there have been many queries regarding the place where FAQ
is archived. 

So here goes.. from the FAQ itself.
-----
Subject:  2) Is the FAQ list available for FTP anywhere?

Answer: A number of FAQ's (including this one) are available for anonymous ftp
at pit-manager.mit.edu, 18.172.1.27 under the directory pub/usenet.  (Motif is
under pub/usenet/comp.windows.x.motif) There is also a mail server called
mail-server@pit-manager.mit.edu.  To retrieve a file send mail to the server
with a subject or body similar to

        send usenet/comp.windows.x.motif/Frequently_Asked_Questions_About_Motif_(Part_1_of_3)

This service is looked after by Jonathan Kamens (jik@pit-manager.mit.edu).

It has also been placed in contrib/Motif-FAQ at export.lcs.mit.edu.
-------

BTW, going by the number of queries, many users dont seem to be aware of these
sites. So why not there be a periodic posting giving this info as well.

Vijay

-----------------------------------------------------------------------
Vijay Talati                        Email: vijay@iitb.ernet.in
ERNet Lab.                          (X.400):
Computer Centre                      s=Talati ou=gateway o=iitb prmd=ernet c=in
Indian Institute of Technology		Voice: (022)-5783177
Powai, Bombay - 400076                     (022)-5782545 ext. 2791/2799
From: cq377@cleveland.Freenet.Edu (David C. Williss)
Newsgroups: comp.windows.x.motif
Subject: Re: FAQ location
Date: 29 Jan 1993 04:11:27 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Distribution: inet
Reply-To: cq377@cleveland.Freenet.Edu (David C. Williss)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, vijay@gateway.iitb.ernet.in (Vijay Talati) says:

>
>Recently there have been many queries regarding the place where FAQ
>is archived. 
>
>So here goes.. from the FAQ itself.

[ stuff deleted ]

>
>BTW, going by the number of queries, many users dont seem to be aware of these
>sites. So why not there be a periodic posting giving this info as well.
>
>Vijay
>
Good idea.  It's hard to read a FAQ to findout where it is.  Kinda' like
having to go to the library to get a map showing where the library is.

-- 
		-Dave Williss
---------------------------------------------------------------------------
Standards are great!  Everybody should have one of their own!
The opinions stated above are Mine!  All Mine!  You can't have them.
From: wbn@merit.edu (Bill Norton)
Newsgroups: comp.windows.x.motif
Subject: Please unsubscribe me
Date: 20 Jan 93 18:34:57 GMT
Distribution: inet
Organization: The Internet

Please unsubscribe me!  wbn@merit.edu

Sorry to waste up all this bandwidth, but I've tried 5 times to
unsubscribe from this list.

Thanks in advance
Newsgroups: comp.windows.x.motif
From: tommc@hpcvusc.cv.hp.com (Tom McFarland)
Subject: Re: XmText cursor sticking around (1.2.1)
Reply-To: tommc@cv.hp.com
Organization: Hewlett Packard UTD-Corvallis
Date: Thu, 28 Jan 1993 18:45:05 GMT

In article <1993Jan7.001318.27715@CSD-NewsHost.Stanford.EDU>, rfrench@Xenon.Stanford.EDU (Robert S. French) writes:
|> I'm having a lot of trouble with the Motif 1.2.1 XmText widget.  If I
|> have multiple XmText widgets in some kind of form, and hit "TAB" when
|> the cursor is "on" in one of the widgets, the cursor stays there
|> (unblinking).  When I hit "TAB" when the cursor is "off", it stays
|> gone.  This allows you to have non-blinking cursors in all of your
|> text widgets simultaneously, which is ugly at best.  I'm pretty sure
|> it's not just my application since the demos do it too.  Any hints on
|> how to fix this?

This is the new style guide compliant behavior dictated by OSF for 1.2.
If a text widget has the focus, it has a solid (non-stippled) I-Beam cursor.
If a text widget does not have the focus, it has a stippled I-Beam cursor,
except if the text widget owns the Motif destination selection; if it owns
the destination selection, it displays a solid non-blinking I-Beam cursor.
If you are getting multiple non-stippled I-Beam cursors (other than one
in the text widget with focus and one in a text widget that owns the
destination), then there is a bug in the text widget.

A bit of history...

In pre-1.2, destination ownership was indicated by displaying the "carat
cursor".  Also, in pre-1.2 location of the destination could be disjoint
from the insertion point; as of 1.2, destination location and insertion point
are always at the same position.  OSF recieved lots of questions along the
lines "What the heck is this 'hat' character doing in the baseline of my
text widget?".  So, they dropped the different cursor for the destination.
However, they felt it was still important to see where the result of quick-cut
and quick-copy operations would be sent, so they created the new semantic for
showing location of the destination selection.

|> 			Rob
|> 

Tom McFarland
Hewlett-Packard, Co.
R&D Motif team
<tommc@cv.hp.com>
From: klaus@tat2.esf.de (Klaus Wicovsky)
Newsgroups: comp.windows.x.motif
Subject: XmSelectionBoxGetChild crashes application
Date: 21 Jan 93 06:58:46 GMT
Reply-To: klaus@tat2.esf.de (Klaus Wicovsky)
Organization: ESF Headquarters, Berlin, FRG

Hello,

I have the following problem: I have a widget A with a callback definition.
In the function that implements the callback, I would like to modify
something in a different widget B, e.g. add a text string to a selection
box. How do I access this widget B???

What I tried and failed to do is this:

----------------------------------------------------------------------
void fs_okCB(w, client_data, call_data)
...
...
     	text=XmSelectionBoxGetChild (w, XmDIALOG_TEXT);
	filename=XmTextGetSelection(text);
...
	list = XmSelectionBoxGetChild (selected, XmDIALOG_LIST_LABEL);
----------------------------------------------------------------------

Whenever this callback procedure is carried out, my application crashes at
the last line. "w" would be my original widget for which I define this callback
and "selected" would be my new widget, which would like to modify.

Although "selected" is globally defined, the last statement crashes my
application. Any  idea why this could happen ???
-- 
   Klaus Wicovsky                                                   
                                                                    
   ESF Headquarters                    Tel : ++49+30-820 903 47      
   Hohenzollerndamm 152                Fax : ++49+30-820 903 19      
   1000 Berlin 33                      UUCP: klaus@esf.de        
   Germany             
Newsgroups: comp.windows.x.motif
From: tma@encore.com (Thanh Ma)
Subject: Running a motif application on a remote machine
Organization: Encore Computer Corporation
Date: Thu, 21 Jan 1993 23:26:43 GMT

I am trying to run a motif application on a remote machine and have it
displayed on my 386 with 16M RAM and a Diamond video card with 1M RAM.
The problem I have is that it displays really, really slow. I just
wonder what is the problem and what can I do to speed it up. Do I need
more memory, faster VGA card, faster CPU, or what ? Please help.

--
thanh
tma@encore.com
From: fineman@tatertot.arc.nasa.gov (Charles Fineman)
Newsgroups: comp.windows.x.motif
Subject: Problems with Modality
Date: 26 Jan 93 20:03:05 GMT
Distribution: comp
Organization: NASA/ARC Information Sciences Division


I'm having a bear of a time getting modal dialogs to work correctly
for me (or at least working in way the expect them to work given my
interpretation of the literature.)

Here's an example... I have a main window, a help dialog for that main
window, a file selection dialog, and another dialog. The later two
dialogs are children of the main window. I made the file selection
dialog primary application modal and the other dialogs modeless. Now,
the file selection dialog is a child of the main window so when I
request help, it pops up the help dialog for the main window like it
should have.

The problem is that I can't interact with the help window. I can still
interact with the "other" dialog though. The help dialog won't accept
any events until I close the file selection dialog. Now, my
interpretation of the literature is that PRIMARY_APPLICATION_MODAL is
supposed to disallow interaction with immediate ancestors and that is
all. This is not the case though!

Is this a bug or am I missing some obtuse semantic idiosyncrisy of
Motif?

	Charlie
--
From: english@alicudi.usc.edu (Joe English)
Newsgroups: comp.windows.x.motif
Subject: Re: MenuBar challenge
Date: 25 Jan 1993 13:17:43 -0800
Organization: Nerds of Action
Distribution: na
Reply-To: joe@trystero.art.com
NNTP-Posting-Host: alicudi.usc.edu


sglanger@vela.acs.oakland.edu (LANGER STEVEN C) writes:
|>   I know that the menubar is "supposed to" only accept homogenous
|> children of type pull down menu. My problem is, my clients want a
|> display like this

[ Menubar containing non-CascadeButton widget ]

|> I've already got the power meter written (all subclassed on a drawing
|> area) and attached just under the menubar. The clients want it ON
|> the menubar. Is there some way to "fake out" the menubars homogeneous
|> setting?

Can't be done, at least not that way.

Instead of putting the power meter inside the
MENU_BAR RowColumn widget, you could wrap them both
inside another horizontal WORK_AREA RowColumn.
(Just don't tell the Style Guide Police I said this,
OK?)

You'll probably have to use a Frame widget as well
if you want the shadow, since WORK_AREA RowColumns
don't draw one.  (Does anyone know why this is?
It's a ``feature'' I could do without...)


--Joe English

  joe@trystero.art.com
From: buzz@bear.com (Buzz Moschetti)
Newsgroups: comp.windows.x.motif
Subject: Re: Killing Motif Aplications on Sun
Date: 28 Jan 93 19:04:20 GMT
Reply-To: buzz@bear.com (Buzz Moschetti)
Distribution: na
Organization: Bear, Stearns & Co. - FAST
In-reply-to: kobet@xsun2a.ct.picker.com's message of 28 Jan 93 15:55:52 GMT

In article <1993Jan28.155552.4857@picker.com> kobet@xsun2a.ct.picker.com (Harry J Kobetitsch) writes:

   I am trying to kill a Motif application by double clicking on the
   top leftmost button. 

What window manager is this, if that's the button you're double
clicking?  Assuming it is a WM button we're talking about here, beware
that some shells respond to the WM WM_DELETE hint by unmapping, not
destroying the shell, in which case you've lost it.  Also, the 
standard XtAppMainLoop() event loop does *not* return when there
are no more resources with registered events, so even if you are good
about destroying everything your app will still hang.

Advice:  
1.  Make sure the shell tries to destroy itself upon receiving WM_DELETE.
2.  Set up your own event loop as follows:

	active_flag = 1;

	while(active_flag) {
	      XtAppNextEvent(UxAppContext, &ev);
	      XtDispatchEvent(&ev);
	}

3.  Add a destroy callback to shell widget that does this:

	void
	destroy_cbk(w, clientdata, callbackdata)
	Widget w;
	XtPointer clientdata;
	XtPointer callbackdata;
	{
	      /* This will stop the loop in main()... */
	      active_flag = 0;
	}





Newsgroups: comp.windows.x.motif
From: drand@spinner.osf.org (Douglas S. Rand)
Subject: Re: popping up a PopupMenu using Btn1
Organization: Open Software Foundation
Date: 22 Jan 93 17:47:24

In article <1993Jan22.160053.24231@unislc.uucp> fladmoe@unislc.uucp (Gary Fladmoe) writes:

   In article <C14G2D.Gvu@csn.org> tom@teal.csn.org (Tom Schutter) writes:
   >I am constructing a toolbar where some buttons do actions when pushed, and
   >others bring up popup menus. To make things consistent, I want the popup
   >menus to come up with Btn1.
   > 
   >I start with a RowColumn (of type XmWORK_AREA) with a number of PushButton
   >children. An activate callback on each PushButton then either calls one of
   >my action callbacks or calls XmMenuPosition and XtManageChild to popup a menu.
   > 
   >The problem is that Btn1 pops the menu up, but only Btn3 will pop it down.
   >...

   The following function violates the rule against using the Widget's private
   data, but it seems to work:

   #include <Xm/RowColumnP.h>
   void MenuButtonCB(w, menu, cbs)
   Widget w;
   Widget menu;
   XmAnyCallbackStruct *cbs;
   {
	   XButtonPressedEvent *event;

	   event = (XButtonPressedEvent *)(cbs->event);
	   XmMenuPosition(menu, event);
	   XtManageChild(menu);
	   if (event->type == ButtonPress)
		   RC_PostButton(menu) = event->button;
   }


Naughty, naughty, playing with a widget's privates :) .  Seriously,
don't do this.  This is not the only thing which must happen.  That is
why there is a data abstraction layer between you and the widget
internals.

--
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
Xref: sparky comp.windows.x.motif:8801 comp.windows.x.intrinsics:789
From: mjo@iao.ford.com (Mike O'Connor)
Newsgroups: comp.windows.x.motif,comp.windows.x.intrinsics
Subject: Re: TO move motif programs from hp's to sun
Date: 25 Jan 1993 13:43:56 GMT
Organization: Not an official spokesperson for Ford Motor Company
Distribution: world
Reply-To: Mike O'Connor <mjo@fmsrl7.srl.ford.com>
NNTP-Posting-Host: localhost

In article <1jq540INNrb0@shelley.u.washington.edu>
pramodmm@stein.u.washington.edu (Pramod Mahadev) writes:

:I have written a couple of programs in motif 1.1 on H.P
:workstations. Now, we want to move the software to sun workstation
:I dont have a motif library on sun workstation. 
:So, i was wondering if there is any way, i can get access to the motif libraries
:for sun. i have a sparc 1.0, with o.s 4.0.3 c . 
:Can anyone tell me, where ican get the libraries so that i can just
:link my programs and make it run on the sun work station.
:does the motif for sun work for any version of o.s .

For your particular problem, needing Motif for Sun to move programs
written with HP's Motif (1.1.1 with retentions), I suggest contacting
the good people at SAIC (saic.com).  From what I recall (please
correct if I am wrong), they actually ported HP's Motif to Sun to
facilitate porting HP VUE to Sun.  I think you'd need an OS upgrade on
your Sun to use most any of the commercial Motif alternatives out
there...  4.0.3 is a little crusty.

						...Mike

-- 
 Michael J. O'Connor           |  Internet:  mjo@fmsrl7.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277
From: steffen@jane.dekwl.abb.com (Ulrich Steffen - ABB Power Plant Control - Mannheim Germany)
Newsgroups: comp.windows.x.motif
Subject: (none)
Date: 26 Jan 93 14:14:17 GMT
Distribution: inet
Organization: The Internet

help
Newsgroups: comp.windows.x.motif
From: bobm@oracodev.uucp (B. Mortensen)
Subject: Motif development on Sun and Vax/VMS with C++.
Organization: Optical Research Associates
Date: Wed, 27 Jan 1993 01:00:07 GMT

Our company is about to enter the world of Motif and we naturally have some
basic questions.  First a little bit about our background/plans.  We have
been developing applications on the Sun using OLIT.  Our goal is to port
them to Motif and support them on (at least) Sun's and Vax's (VMS).  The
applications are written in C++.  The two big questions we have are:

1) Are there C++ friendly header files available for X/Motif on VMS?
Where? We have the Glockenspiel C++ VMS compiler and have tried compiling a
simple Motif program (xmbutton from the OSF/Motif Programmer's Guide)
without success.  The X FAQ states "The X11R4/5 header files are compatible
with C++. The Motif 1.1 header files are usable as is inside extern "C"
{...}."  Apparently, whoever wrote this hasn't tried DEC/Motif.

2) Who is a good source for a Sun Motif "developer's kit".  I assume that
we will be targeting Motif 1.1(.2?) initially since we will need to work
with OpenWindows 3.0 (X11R4).  BTW: what version of X does the DEC/VMS X
server support?

Please e-mail responses directly to me (uunet!oracodev!bobm or
oracodev!bobm@uunet.uu.net).

Thanks in advance for you help.

-- 
Bob Mortensen				    Optical Research Associates
Senior Software Engineer		      550 North Rosemead Avenue
						    Pasadena, CA  91107
uunet!oracodev!bobm					 (818) 795-9101
Newsgroups: comp.windows.x.motif
From: sasarh@demetris.unx.sas.com (Tony Hefner)
Subject: Need help with AUTOMATIC scrolled window
Originator: sasarh@demetris.unx.sas.com
Date: Thu, 21 Jan 1993 23:53:08 GMT
Organization: SAS Institute Inc.


Someone please help if you can.  I'm using a ScrolledWindow with
XmAUTOMATIC scrolling policy, and XmAS_NEEDED scrollBarDisplayPolicy.
The workWindow is a DrawingArea.  The trick is, I don't ever want a
horizontal scrollbar; so I put a resize callback on the clipWindow,
and resize the underlying drawingArea to that width, and whatever height
is necessary to contain all my data.  (I use XtResizeWidget so I don't
get into any nasty resize loops).  Then I have the resizeCallback for
the underlying drawing area rearrange all of its children accordingly.
(using XtMoveWidget, again to alleviate contention)  The layout works
fine, but the scrollbars never update their maximum value or slidersize,
and the horizontal scrollbar still appears sometimes.  Can anyone help
me out?

              -- Tony Hefner (aka sasarh@unx.sas.com)
Newsgroups: comp.windows.x.motif