HDTenEightyP/NetNews huggingface dataset:
From: huub@cwi.nl (Huub Bakker)
Newsgroups: comp.windows.x.motif
Subject: De-iconifying widget trees.
Keywords: icons, XtNiconic, XtNinitialState
Date: 14 Dec 92 08:33:14 GMT
Reply-To: Huub.Bakker@cwi.nl
Organization: CWI, Centre for Mathematics & Computer Science

Hello world,

I want to (de-)iconify widget trees not only with the windowmanager but also
from "inside out". So I need to write code to do this job. Iconifying works,
but deiconifying gives some problems. Here is the code:
   
   XtPopdown(tree->tree_widget);
   XtUnrealizeWidget(tree->tree_widget);

   XtSetArg(args[n], XtNiconic, False); n++;
   XtSetArg(args[n], XtNinitialState, "NormalState"); n++;
   XtSetValues(tree->tree_widget, args, n);
   
   XtRealizeWidget(tree->tree_widget);
   XtPopup(tree->tree_widget, XtGrabNone);  
   XtMapWidget(tree->tree_widget);

tree->tree_widget is a toplevelShellWidget created as popupshell.

After execution of this code, the icon window is removed from the screen. But
the new "normal" window is not mapped on the screeen, but is vissieble in the
"virtual desktop" window of vtwm (the window_manager).
  
Is this code right, but is the window manager stupid (I'v tried other window
managers, but they also fail (twm, 4dwm)? Or is something wrong in the code?

Can anybody help? Thanks.

Greetings, Huub.

-- 
CWI, P.O. Box 4079 			Huub Bakker (huub@cwi.nl)
1009 AB Amsterdam
The Netherlands
Tel. 31 20 5924080
From: pickerig@eee.bham.ac.uk (Guy Pickering)
Newsgroups: comp.windows.x.motif
Subject: Re: mwm Icon Manager
Date: 16 Dec 1992 17:31:10 GMT
Organization: The University of Birmingham, England
Distribution: inet
NNTP-Posting-Host: nanda_devi.eee.bham.ac.uk
X-Newsreader: TIN [version 1.1 PL6]

Luis Galleguillos (luisg@hadar.fai.com) wrote:
: 
: Is there an icon manager for mwm  a la twm? I would like to run mwm
: but still retain some of the twm flavor. Any hints?
: Not in the FAQ. I looked .
: 
: Thanks in advance.
: 
: Luis
: luisg@hadar.fai.com

I haven't used twm but have you tried setting "Mwm*useIconBox: True" in
your .Xdefaults file?

Guy.


--
+--------------------------------+-----------------------------------------+
| Guy Pickering                  | School of Electronic & Electrical Eng,  |
| E-MAIL: G.PICKERING@uk.ac.bham | University of Birmingham,               |
| Tel: (021) 414 4340            | Edgbaston, Birmingham. B15 2TT.         |
+--------------------------------+-----------------------------------------+
From: jeff.blanchet@sdrc.com (Jeff Blanchet)
Newsgroups: comp.windows.x.motif
Subject: Help using TAB to move to next field in ScrolledWindow
Date: 16 Dec 92 15:39:59 GMT
Reply-To: jeff.blanchet@sdrc.com


I have a question about the use of the TAB key to get to the next field on a form.

I have a form that includes a scrolled window. Inside the scrolled window is a number of XmText widgets each one on a seperate line (inside a RowColumn). When I hit the TAB key from the first field the input focus goes to the scroll bar on the scrolled window instead of the next XmText. I fixed this by changing the XmNtraversalOn resource to FALSE on the scrollbar for the scrolled window. Other XmText TAB's go to the next XmText widget like I want it (If in the viewing area).

My current problem I am trying to solve is when I TAB from a XmText widget that is in the viewing area to a XmText widget that is out of the viewing area of the Scrolled Window (need to scroll). Instead of going to the next XmText, which is what I want, it changes focus to my OK PushButton on the bottom of my form (next visible widget).

I tried to solve this by changing the TranslationTable on the XmText fields to capture the TAB key press. Great! Now I have control and know which XmText I need to go to next. What I can't figure out when doing this is first how to transfer focus to the next XmText field, and second if the next XmText is out of the viewing area what to do?

Has anyone come across this? How did you solve it? How would you suggest I solve this? Am I going in the right direction?

Any help would be GREATLY appreciated!

Jeff Blanchet				jeff.blanchet@sdrc.com
SDRC
Cincinnati Ohio
From: aw@BAE.BELLCORE.COM (Andrew Wason)
Newsgroups: comp.windows.x.motif
Subject: Re: Key events in Text Widget
Date: 13 Dec 92 02:13:05 GMT
Distribution: inet
Organization: The Internet

ontek!diana@uunet.uu.net (Diana Eppstein)  writes:
> 1) I am writting a widget, that uses the Motif text widget
> as a child.  What I need to do, is to look at all arrow keys, return,
> tab, select, ect, before the text widget so that I can only pass
> on the keys I don't need. There is a simple Xt solution to this,
> I make another child which handles the keys the way I want, and
> give it the keyboard focus.  The problem, is that when the
> text widget does not have the keyboard focus, the I-beam cursor is
> not visible.  I need a method that will allow everything to work.

Forget about the other child, just override the text widgets
translations to call actions defined in your parent widget for
each of the keys you care about.

e.g. your parent widget can define RightArrow() and LeftArrow()
actions (in its XtActionsRec in core_class.actions).  Then
override the text widgets translations with:

  <Key>osfRight: RightArrow()\n\
  <Key>osfLeft: LeftArrow()

Andrew

_______________________________________________________________________________

Andrew Wason                                       Bell Communications Research
aw@bae.bellcore.com                                Piscataway, NJ
bellcore!bae!aw
Newsgroups: comp.windows.x.motif
From: mwp@iconix.oz.au (Michael Paddon)
Subject: Re: Should I be using UIL???
Keywords: Motif / UIL
Organization: Iconix Pty Ltd (World Headquarters)
Date: Mon, 21 Dec 1992 01:02:00 GMT

In <1992Dec15.223953.21690@mlb.semi.harris.com> dbrillha@dave.mis.semi.harris.com (Dave Brillhart) writes:

>What is your opinion about the use of UIL to make the job of writing
>Motif applications easier, more maintainable, &/or more portable?

We use UIL for all of our interface coding because:
   * it forces a complete divorce of form and function
   * it speeds up the development of the interface. Fine tuning
     is fast because uil compiles much quicker than C. Also,
     writing UIL is easier than calling the correct C widget functions.
   * the user can alter, or completely change, the interface without
     us having to give them access to C source code (with the resulting
     maintenance headaches).

On the down side, UIL is not necessarily a well designed language.
But is is a standard, which means a lot when you are sinking money into the
development of a product.

Michael
Newsgroups: comp.windows.x.motif
From: cecchinr@gehrig.cs.rpi.edu (Ron Cecchini)
Subject: How to simulate a ToggleButton with a PushButton
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Tue, 15 Dec 1992 17:19:48 GMT

Hi all,

 I've seen this asked here before, and I thought it was in the FAQ,
but lo and behold - it is not.  And of course, I didn't save the information
because I didn't need it until now...

 So: How can I make a PushButton stay pushed in when it is pressed?

Thanx,
Ron

p.s. It would be nice if there were a ToggleButton resource that basically
     allowed you to do this; i.e. get rid of the indicator and draw the
     ToggleButton as if it were a PushButton

Newsgroups: comp.windows.x.motif
From: mattf@cac.washington.edu (Matthew Freedman)
Subject: Setting Color on OptionMenu Button -- Impossible?
Organization: U.W. Information Systems
Date: Thu, 17 Dec 1992 20:07:59 GMT

I have a very Motif-naive user population. We are receiving lots of
complaints that users do not realize that the button on my option menus
are actually pressable items -- they think they are static labels that
just happen to have shading around them. This is exacerbated by the
fact that my menus do not have a label portion.

One obvious thing to do is make the push-button on the option menu the
same color as all the other push-buttons on the application, which is
different than the default background. However, OSF in its wisdom made
the pushbutton a gadget, hence it can not have a different color than
its parent, which in this case is a rowcolumn. If I set the color of
that rowcolumn so that the button inherits it, I get a strange looking
colored border around the button (I.e. the portion of the rowcolumn
not covered by the button).

Is there any way to do this? I realize that it would be fairly easy to
go into the source of XmCreateOptionMenu() and use a widget instead of
a gadget, but I need to distribute the source to my application, which
obviously can not include Motif source.

Another possibility would be to change that stupid little rectangle on
the button to something more obvious, like a down-arrow, which might
cue the user to the fact that there is something under it. But again,
this would appear to require source modification.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
= Matthew M. Freedman                                                 =
= U. of Washington Information Systems       mattf@cac.washington.edu =
= 4545 15th Ave. NE; 4th Floor               (206) 543-5593           =
= Seattle, WA  98105                                                  =
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Newsgroups: comp.windows.x.motif
From: tero@vipunen.hut.fi (Tero Takki)
Subject: How can I make Drawing Area invisible?
Reply-To: Tero.Takki@hut.fi
Organization: Helsinki University of Technology, Finland
Distribution: comp
Date: 19 Dec 92 20:38:24


I have an application that has widgets toplevel, form and on top
menuBar and DrawingArea. Two problems:

1. On the pullDownMenu there is a choise of "Invisible".
   This should make the drawingArea invisible so that user could
   see applications running under this application. The target
   is to move the application over some other and grab the contents
   of invisible drawingArea to backgroundPixmap of the drawingArea.

   How can I make the drawingArea invisible?

   I have tried to change the XmNbackgroundPixmap-attribute to None
   and NULL but that causes error.

2. On a pullDownMenu there is a choise of "Show ruler". When the user
   clicks it, it should change to "Hide ruler".

   How can I do that?

Thank's in advance and Merry Christmas.
--
   Tero Takki
   Bredantie 26 B                   phone:  +358-0-505 1452
   SF-02700 Kauniainen              e-mail: Tero.Takki@hut.fi
   FINLAND
Newsgroups: comp.windows.x.motif
From: mikeg@Ingres.COM (Mike Glendinning)
Subject: Problem with 'mwm -multiscreen' resources.
Organization: Ingres Corporation
Date: 16 Dec 92 11:05:05 GMT

I'm trying to get 'mwm' to manage two screens using the '-multiscreen'
option, but I'm not having much success!  Both screens are being
managed, but I can't seem to pick up the correct resources for
each screen.

My understanding of the documentation is that if I use a command such
as:

   mwm -multiscreen -screens one two

then the resources for screens 0 and 1 will be picked up using the
names "one" and "two" instead of just "mwm".  That is, on a single
screen system, the command:

   mwm -multiscreen -screens one

has much the same effect as:

   mwm -name one

Is this correct?  I've also tried setting the resources "Mwm*multiScreen"
and "Mwm*screens" without any success either.

I also can't figure out exactly what resource names 'mwm' is using
for the two screens.  The documentation says "0" and "1", which
don't seem to work.

This is all with Motif 1.1.1 (I think).

-Mike Glendinning, Ingres UK (mikeg@ingres.com).
Newsgroups: comp.windows.x.motif
From: mattb@plato.ds.boeing.com (Matt Baney)
Subject: Problem Exiting from a Dialog?
Reply-To: mattb@plato.boeing.com (Matt Baney)
Organization: Boeing Defense & Space Group
Date: Fri, 18 Dec 1992 17:01:02 GMT

I am using the examples from the Douglas Adams book to 
create an application using MOTIF and C++.

I have created a dialog window and set up the callbacks
for the _okButton and _cancelButton, then I added some
textEditFields to the dialog window. BUT whenever you 
type a carriage-return in one of the textFields the
dialog exits??  I only want the dialog to exit when 
one of the _OK or _CANCEL buttons??

thanks
matt

-- 
|  Matt Baney         | Boeing Defense and Space Division    |
|  -----------------  |   Knowledge Systems Group            |
| "I can't tolerate   | UUCP:        ..!bcstec!plato!mattb |        
| intolerant people!" | Internet:   mattb@plato.boeing.com |
From: dave@eagle.smec.Sony.COM (David Jarrin)
Newsgroups: comp.windows.x.motif
Subject: Re: Unmanaging a toplevel shell
Date: 14 Dec 92 16:04:23 GMT
Distribution: inet
Organization: The Internet

>       Is there is a way to unmanage a topLevelShellWidget created by
>  w = XtAppCreateShell("shell","Shell",topLevelShellWidgetClass ....
> 	I get a core dump if I use XtUnmanageChild(w). I could use 
> XtUnrealize(w) but it not only unmanages but also destroys all the windows 
> of its children. This wreaks havoc with the phigs-workstation opened on those windows when I do XtRealize(w) again.
> 	there's probably a very simple solution to this. Any help appreciated.
> 
 

Hi!

Have you tried XtPopup() and XtPopdown() ?

Good luck!

David Jarrin
dave@smec.sony.com
SONY Medical Systems - Montvale, New Jersey - U.S.A.
Newsgroups: comp.windows.x.motif
From: magnuson@skyler.mavd.honeywell.com (Randy Magnuson)
Subject: Need help with building application on HP workstation
Organization: Honeywell Systems & Research Center
Date: Fri, 18 Dec 1992 21:30:45 GMT

I am having a problem building and running Motif applications on an HP
workstation.  After seeing the problem with the application I am writing, I
decided to try the example "dynapix.c" out of O'Reilly Volume 6.  I got the
exact same symptoms.

The symptoms are the 1st menubar item is missing completely, and the others all
pulldown with nothing in them.  (Just a small empty box shows up).  I don't get
any messages when compiling/linking and nothing at run time.  Has anyone seen
this, or does anyone have any suggestions as to what to look for.

I compile using:

  cc -odp dynapix.c -lXm -lXt -lX11

My LPATH is:

  /lib:/usr/lib:/usr/lib/Motif1.1:/usr/lib/X11R4

I am running HP-UX 8.05.

I have tried it at both the local console and on a remote display with the same
results.  Also, I can build it and my application on a VAX/VMS system without
problems.

--
Randy R. Magnuson
magnuson@skyler.mavd.honeywell.com  (612-951-5486)
From: craigm@chateau-rouge.ics.uci.edu (Craig MacFarlane)
Subject: Re: question: resizing a window
Newsgroups: comp.windows.x.motif
Reply-To: craigm@ics.uci.edu (Craig MacFarlane)
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.
Date: 16 Dec 92 22:00:35 GMT

In article <DRAND.92Dec10100847@spinner.osf.org> drand@spinner.osf.org (Douglas S. Rand) writes:
>In article <1992Dec9.224358.9026@newsgate.sps.mot.com> dichter@chdasic.sps.mot.com (Carl Dichter) writes:
>
>   In article <SNOW.92Dec9132542@castor.hahnemann.edu>, snow@castor.hahnemann.edu (Donald C. Snow) writes:
>   |> The problem is I'd like for the window the user sees to resize itself
>   |> to accomidate the new child, if the new child would cause the
>   |> RowColumnWidget to be bigger than the space left in the window (and
>   |> thus leave the new child unseen).
>   |>
>   |> How do I do this?
>   |>
>
>   In other words, how do you grow/shrinkwrap a parent to fit all the children.
>
>   I too, need the answer to that,
>
>Not sure.  Try resizeWidth and resizeHeight.  They govern the
>geometry management request with parent stuff.

You mean you want Motif to provide a routine like XView's macro,

  window_fit(Xv_window window)

Unfortunately, I have not found such a beast in Motif.  I needed to do the
same thing and accomplished it by keeping a list of all children of
the parent that needs to be shrinkwrapped.  Then when it came time to
shrinkwrap, I'd query the widths, and heights, find the rightmost and
bottommost edge of all children and you end up with the required size.

I'd be interested in hearing other people's solutions.  Especially if there
is a canonical way  of doing this.

Craig
--
-----
"We... have no use for adventures.  Nasty disturbing uncomfortable
things!  Make you late for dinner!"  -- B. Baggins

Xref: sparky comp.windows.x.motif:8064 comp.windows.x:20304
From: rjc@cogsci.ed.ac.uk (Richard Caley)
Newsgroups: comp.windows.x.motif,comp.windows.x
Subject: Re: Spanning windows on X is not X (was Re: Dual Screens)
Date: 16 Dec 92 03:49:26 GMT
	<897@metrix.UUCP> <1992Dec5.193705.12883@thunder.mcrcim.mcgill.edu>
Organization: Human Communication Research Center
In-reply-to: mouse@thunder.mcrcim.mcgill.edu's message of 5 Dec 92 19:37:05 GMT

In article <1992Dec5.193705.12883@thunder.mcrcim.mcgill.edu>, der Mouse (dm) writes:

dm> Whether it [emulation of 8-bit on 1-bit] would be a good idea to
dm> do this is another question entirely.  In my opinion such a server
dm> would not be appropriate for general-purpose use.

Maybe not, but it would be amazingly useful in a couple of situations.

	1) For people (eg me) developing X software whose usual display is
	   1-bit. Having to borrow a colour machine each time I
	   modify the program to check I havn't broken something is a
	   pain. 

	2) For users who want to run a client which doesn't provide
	   1-bit support. Yes, one might say that every client should,
	   but some don't, and anyway this would prevent much wheel
	   reinvention.

--
rjc@cogsci.ed.ac.uk			_O_
					 |<
From: trest@VisiCom.COM (Mike Trest)
Newsgroups: comp.windows.x.motif
Subject: X in a Real-Time environment
Date: 16 Dec 92 16:11:09 GMT
Organization: VisiCom Laboratories, Inc., San Diego, California

We have all of X and Motif running with VxWorks for over 2 years now,
a popular Real-Time operating system.  We have other RTOS versions
under development.  Our server works with a several different
vidio boards.  Applications can do all the expected things with
local or remote servers.  Our libraries work with most of the
GUI application/program generators.  The whole thing is fully
re-entrant . . . that means all libraries, servers, and client
applications share only one copy of the code.

We have placed X & (sometimes Motif) inside instruments, gagets, 
and what-nots.  They are all running variations of a RTOS. Some
devices are totally stand-alone, some are net-connected.  All
are very "light weight" interms of limited memory, limited fonts,
careful use of bitmaps.

I am trying to connect with others in the X community who have an
interest in resolving the pratical problems of operating the very
non-deterministic character of X and the need for determinism
in real-time application.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================
====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================
Newsgroups: comp.windows.x.motif
From: glasgow@techunix.technion.ac.il (Jason R. Glasgow)
Subject: Motif of X386
Organization: Technion, Israel Institute of Technology
Date: Tue, 15 Dec 1992 13:11:50 GMT

We are currently running XFree386 under mach and we want to develop
X11 applications. Does anyone have any information about using Motif
widgets on XFree386?

Where can we get the libraries and the include files? Are they public
domain or do we have to buy them somewhere?

Any assistance would be greatly appreciated.

-Jason



-- 
+----------------+----------------------------------------------------------+
|  Jason Glasgow | bitnet:   glasgow@techunix.bitnet                        |
|                | internet: glasgow@techunix.techion.ac.il                 |
+----------------+----------------------------------------------------------+
Newsgroups: comp.windows.x.motif
From: mark@prepress.com (Mark S. Bubien)
Subject: Anyone got a Ruler Widget?
Organization: Pre-Press Technologies, Carlsbad Ca.
Date: Fri, 18 Dec 1992 15:19:00 GMT


I am looking for a way to put rulers into a Motif
window.

For example, on the Mac, PageMaker and QuarkExpress both
have vertical and horizontal rulers.  I want implement
something very similar in Motif, but I don't know
where to start.

If anyone's got any advice or an implementation that I can
use, please drop me a line.

Thanks
	Mark

--
=============================================================================
                        |  Most of the time, my head is on straight         |
Mark S. Bubien		|  Most of the time, I'm strong enough not to hate  |
mark@prepress.com	|  I don't build up illusion, 'til it makes me sick |
                        |  I ain't afraid of confusion, no matter how thick |
Pre-Press Technologies	|  I can smile in the face of mankind.              |
2443 Impala Dr.		|  Don't even remember what her lips felt like on   |
Carlsbad, Ca 92008	|       mine                                        |
(619) 931-2695		|  Most of the time.                                |
                        |                -Bob Dylan                         |
=============================================================================
Newsgroups: comp.windows.x.motif,comp.windows.x.intrinsics
From: converse@excess.lcs.mit.edu (Donna Converse)
Subject: Re: Shift vs. CapsLock Translation
Organization: X Consortium, MIT Laboratory for Computer Science
Date: Fri, 11 Dec 1992 19:31:54 GMT


> Xt is differentiating between "Shift<key>F6" and "Lock Shift<key>F6".
> What is the translation that will fire for "Shift<key>F6" ignoring
> the Lock key?

Given the production

	Shift <Key>F6: action1()

action1 should fire regardless of the state of the Lock key.  But if
you also have this other production in the same translation table:

	Lock Shift <Key>F6: action2()

then it must appear earlier.  This is because the matching of an
event to a production is done by testing each production in the
same order as they appear in the translation table.  If the
translation table appears like this:

	Shift <Key>F6: action1()
	Lock Shift <Key>F6: action2()

Then action2 will never fire, because an event with the Shift and
Lock keys engaged always match to the production for action1.

If the productions appear in the translation table in the other order:

	Lock Shift <Key>F6: action2()
	Shift <Key>F6: action1()

action1 will fire only when Shift is pressed and the Lock key is not
engaged.  When Shift and Lock are both engaged, action2 will fire.

There is currently a bug in the matching algorithm, sorry to say.
However I don't believe it has an affect on this particular example.


Donna Converse
MIT X Consortium