HDTenEightyP/NetNews huggingface dataset:
From: skinner@cshl.org (John Skinner)
Newsgroups: comp.windows.x.motif
Subject: I don't want my windows popping up as outlines
Date: 15 Sep 92 20:18:01 GMT
Organization: Cold Spring Harbor Laboratory

I'm working on Silicon Graphics machines. When I bring up a window,
it appears as a outline until I push the left mouse button.
What do I need to do to get the fully drawn windows exposed
when new windows are created.
-- 
*****************************************************************************
John M. Skinner   Brookhaven National Laboratory, Upton N.Y. USA
e-mail : skinner1@bnl.gov
*****************************************************************************
From: dbrooks@osf.org
Newsgroups: comp.windows.x.motif
Subject: Re: test
Date: 5 Sep 92 02:44:04 GMT
Distribution: inet
Organization: The Internet

Kalidoss Sivasamy writes:
> slkadf'asldkhg
> lkhlkh
	
Nice to see that someone has got i18n working.
From: dsmith@aa.cad.slb.com (J. Daniel Smith)
Newsgroups: comp.windows.x.motif
Subject: Re: A bug in Motif 1.1 option menus?
Date: 10 Sep 92 02:53:11 GMT
Organization: Schlumberger CAD/CAM; Ann Arbor, MI (USA)

In <1992Sep2.162803.26711@ornl.gov> jxt@stc06.ctd.ornl.gov (TOLLIVER J S) writes:
>I have noticed a strangeness with Motif 1.1 option menu callbacks. I
>[...]
>Is this a bug or am I totally missing something here? If a bug, is it a known
>bug? The only work around I have found is to also set arm and disarm callbacks
This sounds similiar to a problem we ran into; here are a few comments
from our code...

void optionChildCallback(w, tag, callbackData)
   Widget w;
   int *tag;
   XmAnyCallbackStruct *callbackData;
{
    /*****
     * Don't do this if the parent (menuShell) is
     * still up. A menu shell is only managed when the
     * menu is visible. (This should stop the quick-clicks)
     *-----------------------------------------------------
     * We are doing this internally because of a bug in MOTIF
     * that should be fixed in 1.1.4  When we get 1.1.4 we should
     * ...
     *****/
    if (!XtIsManaged(XtParent(w)))
    {
	/* do something... */
    }
} 

   Dan
-- 
============================================================================
J. Daniel Smith                     Internet: dsmith@aa.cad.slb.com
Schlumberger CAD/CAM                          dsmith@aaaca1.sinet.slb.com
Ann Arbor, Michigan (USA)               UUCP: uunet!sharkey!applga!dsmith
From: anderson@eecs.cs.pdx.edu (Karen Anderson)
Newsgroups: comp.windows.x.motif
Subject: Help, please, with XmNsubMenuId
Date: 4 Sep 92 18:14:37 GMT
Distribution: inet
Organization: Portland State University, Portland, OR

I've run into a problem with cascading submenus.  What I want to do is
replace a pulldown menu attached to a menu_bar cascade button.  Please
forgive me if this is a terribly novice question or the ground has been covered
before.

I am running Motif v1.1 on a Sun4/200 with SunOS 4.1.1, X11R4

What I tried was: 

1) After setting up the form, menu_bar etc., 
   create and manage the cascade button

   cbutton = (Widget) XmCreateCascadeButton(menu_bar, "Cascade", NULL, 0);
   XtManageChild(cbutton);

2) Make the pulldowns

   p1 = (Widget) XmCreatePulldownMenu(menu_bar, "menu1", NULL, 0);
   XtManageChild(p1);

   p2 = (Widget) XmCreatePulldownMenu(menu_bar, "menu2", NULL, 0);
   XtManageChild(p2);

3) Add some PushButtonGadgets to each of the pulldowns, say 3 buttons on
   menu1 and 2 buttons on menu2 ...

4) Set the initial XmNsubMenuId resource for the CascadeButton:

      XtSetArg(args[0], XmNsubMenuId, p1)
      XtSetValues(cbutton, args, 1);


When the user sets/resets certain options I want to change the pulldown,

      XtSetArg(args[0], XmNsubMenuId, p2)
      XtSetValues(cbutton, args, 1);


The first time I pull the menu everything is ok--the change has been
made, the gadgets on the pulldown work ok; but when I change back 
to menu1 using the same XtSetArg/XtSetValues calls the program crashes
when I pull down the menu.  Dbx says that the stack was

   OnPostFromList()
   SetCascadeField()
   MenuProcedureEntry()
   `CascadeB`AttachSubMenu()
   `CascadeB`SetValues()
   CallSetValues()
   XtSetValues()

when it crumped. 

The CascadeButton resource documentation says that XmNsubMenuId is "CSG"--
so I thought it was resettable.  Can anybody give me some insight why 
this strategy doesn't work?  It seems like a pretty straightforward
thing to want to do though I must admit I couldn't find any relevant
examples in the O'Reilly book or other books I have lying about...

I'd appreciate e-mail.  Thank you for your help.
Karen
Newsgroups: comp.windows.x.motif
From: tonyf@ims.com (Antonio Freixas)
Subject: Re: Is there something analogous to XtIsMapped() ?
Reply-To: tonyf@ims.com
Organization: Integrated Measurement Systems, Inc.
Date: Fri, 11 Sep 1992 15:17:17 GMT

In article <DRAND.92Sep9181726@spinner.osf.org>, drand@spinner.osf.org (Douglas Rand) writes:
|> In article <7a5yxra@rpi.edu> cecchinr@hornsby.cs.rpi.edu (Ron Cecchini) writes:
|> 
|>      There is XtIsManaged() and XtIsRealized().  I need XtIsMapped() and
|>    there is none.  What is the easiest way to detect this (I'm not
|>    having any luck trying to use the widget's resources).
|> 
|> Why do you care?  You need to know XtIsRealized so you don't draw
|> to a NULL window,  but why do you need the mapping state?  You 
|> normally draw to a Widget's window in response to an Exposure.
|> The server won't generate these events until the window is mapped.
|> 
|> --
|> Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
|> Snail:         11 Cambridge Center,  Cambridge,  MA  02142

-- 

Assume for a second that you have an application which is continually
updating its window.  Assume also, the updates are expensive in terms
of CPU time.  Finally, assume the user iconizes the window.

You may not want to keep updating the screen.  The map state is the
only way I know of handling this case.

					         -- tonyf@ims.com
					       (503) 626-7117 x1349
From: boag@world.std.com (Scott A Boag)
Newsgroups: comp.windows.x.motif
Subject: Info on TAE+ wanted
Date: 6 Sep 92 16:57:47 GMT
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3

[ Article crossposted from comp.windows.x ]
[ Author was Scott A Boag ]
[ Posted on Sun, 6 Sep 1992 16:53:11 GMT ]

Does anyone know anything about TAE+, which is sold by an 
organization called COSMIC?  I received the following blurb from 
someone at COSMIC, but I am still not sure what it is.  My client 
sounded like it was a User Interface Language (UIL), but the blurb 
makes it sound like a GUI builder.  Maybe it's both.  Any information 
would be appreciated.

------ from message titled "COSMIC Info, September 1992" ------
TAE Plus (Transportable Applications Environment)  provides a
generic, user interface development and management system that
allows anyone, programmers and non-programmers alike, to create a
sophisticated graphical user interface for virtually any type of
application.  TAE Plus utilizes MIT's X Window System, Version
11, Release 4, and the Open Software Foundation's Motif Toolkit. 
TAE Plus is portable across a wide range of computing platforms
using either the UNIX or VAX/VMS operating systems, and is
capable of generating code in C, FORTRAN, and Ada, as well as in
the high-level TAE Command Language (TCL).  A new Silicon
Graphics version is now available.  Site license, $750.
------------------------------------------------------------------------------




-- 
**********************************************************
*  Scott Boag
*  DMR Group, Inc.
**********************************************************
-- 
**********************************************************
*  Scott Boag
*  DMR Group, Inc.
**********************************************************
Newsgroups: comp.windows.x.motif
From: aardvark@nt1l.krl.com (Donald Koch)
Subject: Re: Is there something analogous to XtIsMapped() ?
Organization: Koch Research Labs
Date: Sun, 13 Sep 1992 04:20:49 GMT

In article <1992Sep11.151717.2443@ims.com>, tonyf@ims.com (Antonio Freixas) writes:
> 
> Assume for a second that you have an application which is continually
> updating its window.  Assume also, the updates are expensive in terms
> of CPU time.  Finally, assume the user iconizes the window.
> 
> You may not want to keep updating the screen.  The map state is the
> only way I know of handling this case.

Assuming that you really care about whether the window is obscured, as
opposed to being iconified, you could either set the visible_interest
field in the widget (Core class structure) or make an event handler for
VisibilityNotify.  Check out the Input Techniques chapter in O'Reilly
Volume 4.

-- 
Don Koch
aardvark@nt1l.krl.com
Newsgroups: comp.windows.x.motif,comp.windows.x.intrinsics
From: daniel@moonshine.osf.org (Daniel Dardailler)
Subject: Re: inheriting motif methods?
Organization: Open Software Foundation, Motif Team
Date: Tue, 15 Sep 1992 21:09:52 GMT

 
|> Is it proper to use Motif's internal draw routines to do this, or do I 
|> inherit methods from the primitive class?  

It depends.

If you want true inheritance, one that evolves as the superclass
evolves, always try to inherit or envelop the class method.

Obviously, there is a moment where you can't use the superclass method 
(since you are subclassing) but you still want to use some 
available _Xm routine (no duplicated code, or it requires too much internal knowledge).

In term of documentation and compatibility, both are kind of equivalent 
since you only have the source code itself (that will probably change 
in the future, we have a plan :-).
 
We try to ensure binary compatibility even for widget writers, so 
you should have no problem from Motif release to release but the semantics
of a class method is more likely to change than those of a pure _Xm 
stand-alone function (and a class method is also less understandable).


Daniel
From: dbrooks@osf.org
Newsgroups: comp.windows.x.motif
Subject: Re: Bugreport template for OSF MOTIF
Date: 9 Sep 92 15:46:10 GMT
Distribution: inet
Organization: The Internet

Ann Ross, at Hughes, wrote:
> Would someone please send me a BUGREPORT template for OSF Motif.
> 
> Thanks,
> Ann Ross
> Hughes Aircraft Co.
> El Segundo, CA
> 310-616-3430

Please include a usable email return address for requests like this.  Apologies
to everyone else for the public reply.

The template is on your Motif source tape; its contents depend (marginally) on
the release you are using.

You should ask one of the technical contacts at you site; names I have include
Phil Gavin and Peter Liang.

David Brooks
OSF
Newsgroups: comp.windows.x.motif
From: chris@ods.com (Chris Atkins)
Subject: Re: XmCR_RESIZE -> XmCR_EXPOSE ?
Organization: Optical Data Systems, Inc.
X-Newsreader: Tin 1.1 PL5
Date: Tue, 8 Sep 1992 16:44:44 GMT

K J MacDonald (kenny@castle.ed.ac.uk) wrote:
: Dear All,
: 	I've got an application which draws into a XmDrawingArea which
: gets resized by the user. When it grows some XmCR_EXPOSE events are
: generated, the last of which my program acts upon. However, when it
: shrinks, only a XmCR_RESIZE event is sent. If I act on this I get the
: drawing done twice when it grows (yup, it gets XmCR_EXPOSE's as well !)
: 
: 	Any ideas on how to get around this.
: 
: 	I need to redraw on shrinks, to keep all the picture in the
: window.
: 
When you get in the first expose event record the widgets width and height.  
Whenever a resize callback occurs compare new width and height to old and 
only perform the update processing if neither the width or height has grown,
If either has grown, you will be getting expose events.  Update the old width 
and height on all resize events.

You could also try removing expose events from the queue by using the
following commands inside of your resize callback.
  Display *display;
  Window window;
  int event_type;
  Xevent event;

  window = XtWindow(drawing_area_widget);
  event_type = ExposureMask;
  display = XtDisplay(drawing_area_widget);
  while(XCheckTypedWindowEvent(display, window, event_type, &event) == True);
  
  XtCallCallbacks(drawing_area_widget, XmNexposeCallback, call_data);

The above will remove all expose events for the drawing area from the event
queue and then invoke the expose callback.  You need to see what motif does when
the expose events are removed from the queue (ie. are the borders and shadows 
for the drawing area widget updated properly).


Note: it might be safe to remove expose events from the queue inside the resize
callback, but you should not remove configure notify events from the queue in 
the expose callback.  The removal of configure notify events WILL have a 
definite impact on motif. 

Chris Atkins
chris@ods.com
From: zi@edf.fr (Zixiong WANG)
Newsgroups: comp.windows.x.motif
Subject: Re: Accented characters in Motif widgets.
Date: 7 Sep 92 09:34:29 GMT
Organization: EDF Direction des Etudes et Recherches
X-Newsreader: Tin 1.1 PL5

Paul Provost (paul@taarna.UUCP) wrote:
: 
: Hi all,
: 
:     I'm trying to have accented characters in my Motif application
: (this application will be used mostly by French people, who would like
: things written correctly!). I've searched all through the O'Reilly
: guides, but can't seem to find anything.  Anybody out there done this
: before?  And, if so, How?
: 

On a Sun box, open a xterm with a font like courr14, set stty -istrip,
use meta-key and another key to obtain a accented characters. Use xfd to
find the corresponding key, for example: meta-i for 'e and meta-h for `e.
On a HP, open a hpterm, set the terminal on Francais mode, then the keyboard
switchs to french keyboard which contains accented characters.
	In vi, enter your accented characters in strings of your C or UIL code,
set the fontList of your widgets on a font having accented characters (you
know that by xfd), make your executable, you obtain your characters on your
widgets.

Zixiong WANG
zi@cli52na.edf.fr

Clamart, France.
From: klute@tommy.informatik.uni-dortmund.de (Rainer Klute)
Newsgroups: comp.windows.x.motif
Subject: Re: Help on XtMainLoop
Date: 11 Sep 1992 06:58:01 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: tommy

In article <1992Sep10.210545.26449@unx.ucc.okstate.edu>,
muthann@next1.mae.okstate.edu (Venkatesh Bmuthanna) writes:
|> 	I have to develop  an user interface for an expert system  
|> which does not allow me to use the XtMainLoop, hence i am trying to  
|> write a code which would perform the functions of XtMainLoop. I don't  
|> have any idea about this and will appreciate any help in this matter.

If only all questions where that easy to answer! XtMainLoop is a function
left in the toolkit for compatibility reasons. It calls XtAppMainLoop with
the default application context. Use the source, Luke:

void XtMainLoop()
{
        XtAppMainLoop(_XtDefaultAppContext());
}


void XtAppMainLoop(app)
        XtAppContext app;
{
    XEvent event;

    for (;;) {
        XtAppNextEvent(app, &event);
        XtDispatchEvent(&event);
    }
}

-- 
  Dipl.-Inform. Rainer Klute      klute@irb.informatik.uni-dortmund.de
  Univ. Dortmund, IRB
  Postfach 500500         |)|/    Tel.: +49 231 755-4663
D-W4600 Dortmund 50       |\|\    Fax : +49 231 755-2386
From: lr@laurie.smec.Sony.COM
Newsgroups: comp.windows.x.motif
Subject: Postscript to Bitmap (Fonts, Fonts, Fonts)
Date: 13 Sep 92 16:26:44 GMT
Distribution: inet
Organization: The Internet

Hello:

	I need to be able to create a text message in bitmap form and
pass it to another application.  I'm
assuming that the fonts that come with Openwindows for SparcStations
are in postscript.

1.  Is there some way of doing so without putting the text up and
grabbing it as an image?  


2.  If this is the only way, what is the best way to accomplish this
without displaying it on the screen?


3.  Is there a public domain postscript interpreter?


4.  Has anyone worked with SUN's Newsprint?  Would it be possible to
use this without directing the output
	to a printing device?  I'd prefer not to because of the expense, but......

5.  Are there any other packages which purport to convert postscript
fonts and such to bitmaps?


with gratitude to all who offer suggestions,

laurie s. reynolds
sony medical
lr@smec.sony.com
From: graham@comp.lancs.ac.uk (Graham Dean)
Newsgroups: comp.windows.x.motif
Subject: Doug Young's "xtalk"
Date: 9 Sep 92 17:29:07 GMT
Organization: Department of Computing at Lancaster University, UK.

I recently pulled the source code for Doug Young's Xt Programming
book (Motif edition) - I'm having trouble running the "xtalk"
example. I'm using X11R4, Sun SPARCstation SLC, SunOS 4.1.1 and
Motif 1.1. My problems seem to be in the send_to_remote() event
handler. The first problem I had was the use of "XtAllEvents" as a
mask - my server complained about that, so I changed it to mask
comprising all the event masks (is that right? - originally I just
used the mask comprising the masks used in the XtAddEventHander for
send_to_remote()). I can now connect with other displays fine (using the
connect and accept buttons. The main problem is now when the XSendEvent()
function is invoked from the send_to_remote()callback I get the error message
"Error: Couldn't find per display information" - this comes
from the Intrinsics library (Display.c) when dispatching the event.

Any ideas anyone? (Esp. Doug Young if he's out there :-))

Graham Dean

-- 
********************************************************************
internet :  graham@comp.lancs.ac.uk    	   Graham Dean		   *
arpa     :  graham%lancs.comp@ucl.cs       Department of Computing *
janet    :  graham@uk.ac.lancs.comp   	   Lancaster University    *
Newsgroups: comp.windows.x.motif
From: dyoung@media.mit.edu (David Young)
Subject: Q: Help with XtAppAddInput
Organization: MIT Media Laboratory
Date: Thu, 10 Sep 1992 22:13:04 GMT


I have a X/Motif program which needs to monitor and read from a file which
is open for writing by another application.

What I think I'm supposed to do is use XtAppAddInput() to monitor the file
and then do a callback when the file has been written to.  

But what I've gotten to "work" is terribly hacked up.  And it  increases
the load on my machine by what seems to be too much.

Does anyone have any examples or sample code which can demonstrate
XtAddAddInput and the correct format an XtInputCallbackProc which is close
to my needs?

Thanks in advance.

david young
dyoung@media-lab.media.mit.edu

Note: while I am still using my media lab account, I am no longer a student
there.  I am now employed by: USAnimation, 818 N. La Brea Ave, Hollywood,
CA 90038  


Newsgroups: comp.windows.x.motif
From: dec@alex.demon.co.uk (Doug Clinton)
Subject: Re: Is there something analogous to XtIsMapped() ?
Reply-To: dec@s-strat.co.uk
Organization: Alex Technologies Ltd
Date: Thu, 10 Sep 1992 08:42:59 GMT

In article <DRAND.92Sep9181726@spinner.osf.org>, drand@spinner.osf.org (Douglas Rand) writes:
|> In article <7a5yxra@rpi.edu> cecchinr@hornsby.cs.rpi.edu (Ron Cecchini) writes:
|> 
|>      There is XtIsManaged() and XtIsRealized().  I need XtIsMapped() and
|>    there is none.  What is the easiest way to detect this (I'm not
|>    having any luck trying to use the widget's resources).
|> 
|> Why do you care?  You need to know XtIsRealized so you don't draw
|> to a NULL window,  but why do you need the mapping state?  You 
|> normally draw to a Widget's window in response to an Exposure.
|> The server won't generate these events until the window is mapped.

There are other reasons why you might care whether a widget is mapped.
Most that I can think of are obscure and have to do with interaction
with window managers but I have needed this information before.

In response to the original question, call XGetWindowAttributes() on
the widgets window and then examine the map_state element of the
returned attribute structure.


-- 
Doug Clinton				Alex Technologies Ltd,
dec@s-strat.co.uk			32A The Mall, Ealing
					London, England, W5 3TJ

Newsgroups: comp.windows.x.motif
From: akerson@deimos.srg.af.mil (Pete Akerson - akerson%srg@uunet.uucp)
Subject: Re: SCO Update and X11/R5
Organization: ARINC Research, Corp.
Date: Thu, 10 Sep 92 20:47:37 GMT
Keywords: none




tmod@ccvax.ucd.ie writes 

>>  have SCO Unix 3.2.2 with ODT 1.0.1 and I'm considering updating to
 SCO Unix 3.2.4 just so I can compile X11R5.

you can run R4 under ODT 1.1; ODT 2.0 requires R4 (and Update G) to install right.

>> My applications at present are
 running under the X11R3 and Motif 1.0 from the development system.

some of our R3 apps dont work right on R4 machines, ( Synchronize - has some problems, I think.)

So, If the apps are compiled for R3, why do you want R5 ?
--
Usually Reply-to: akerson%srg@uunet.uucp
Internet: akerson@srg.af.mil@uunet.uucp
Uunet: uunet!srg!akerson
Milnet: akerson@srg.srg.af.mil     maybe ...
Newsgroups: comp.windows.x.motif
From: chess@m1-252-2.mit.edu (Patrick G Kinnicutt)
Subject: XmCreateCascadeButton Gives a segmentatioon violation???
Organization: /mit/chess/.organization
Distribution: comp
Date: Mon, 7 Sep 1992 21:15:03 GMT


Hi there.
I am porting an application from the SUN and VAX environments to the DEC
platform, and am having trouble with one Xm function, XmCreateCascadeButton.
It seems on the DEC, using X11R5 and Motif1.1, I get a segmentation violation
within this function invocation, which dbx and printfs seem to indicate.
I checked the arguments out and they seem fine, and it works on the SUN
and VAX.
Is there a known bug with XmCreateCascadeButton on the DECstations, or am I
doing something wrong?  Following is the piece of code for creating a menubar
and submenus which has the problem if you are interested.


  /* Attachments for menubar. */
  ac = 0 ;
  XtSetArg(args[ac], XmNtopAttachment, XmATTACH_FORM) ; ac++ ;
  XtSetArg(args[ac], XmNleftAttachment, XmATTACH_FORM) ; ac++ ;
  XtSetArg(args[ac], XmNrightAttachment, XmATTACH_FORM) ; ac++ ;
  menubar = XmCreateMenuBar(_main, "menubar", args, ac) ;
  XtManageChild(menubar) ;


  /* Create submenus. */
  item_names = specify_menu_items(&item_nums) ;

    {

      panes = XmCreatePulldownMenu(menubar, "panes", NULL, 0) ;

      ac = 0 ;
      XtSetArg(args[ac], XmNsubMenuId, panes) ; ac++ ;


      cascades = (Widget) XmCreateCascadeButton
        (menubar, item_names[j].name, (ArgList) args, ac) ;

      for (i=0 ; i < item_names[j].number ; i++)
        {

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

The error occurs at the XmCreateCascadeButton call 5 lines from the end
of the code.  Am I doing something wrong in creating the menus? Thank
you for your help.

-----------
Patrick Kinnicutt                                (617) 428-8367(h)
chess@athena.mit.edu				 (617) 253-3883(o)
Department of Civil Engineering
Massachusetts Institute of Technology

Mailing Address:     /* Any ideas are entirely my own unless otherwise */
----------------     /* stated.                                        */
Patrick Kinnicutt
MIT Branch P.O. Box 233
Cambridge, MA  02139

From: bazavan@hpindda.cup.hp.com (Valentin Bazavan)
Date: Wed, 9 Sep 1992 15:36:26 GMT
Subject: Re: XmNhelpCallback
Organization: HP Information Networks, Cupertino, CA
Newsgroups: comp.windows.x.motif

The action is PrimitiveHelp(). In the example below, a (primitive) help
callback is attached to the text field widget "text_field." The callback
is activated by the F1 key. This works with Motif 1.1; I haven't tried it
with Motif 1.0.

XtAddCallback(text_field, XmNhelpCallback, <your help callback>, ...)

*XmTextField.translations:       #augment \n\
	<Key>KP_F1:     PrimitiveHelp()

Valentin Bazavan
bazavan@cup.hp.com
Newsgroups: comp.windows.x.motif