Conference bulova::decw_jan-89_to_nov-90

Let me tell you what I do.

You can run savimg on an Ultrix machine to grab an image from the
screen.  It takes coordinates, so can be run independent of the
mouse.  I need to grab images of popup menus, which don't take mouse
focus under dxwm, so I just type in my savimg command, leave focus
in the xterm that calls savimg, popup the menu, and hit a <CR>.  If
you need to capture a pull down menu, which does take input focus,
you can just make the savimg on a delay and hold the menu down until
the screen capture takes place.

This, however, gives you a screen dump in img format, so you need to
run resimg to display the image and take another screen dump using 
the session manager print screen routine to get a picture in ps or
ddif form.

What this all means, is that the session manage print screen routine
should have a command line interface and it should take coordinate
arguments.

If you are on a VMS system, you can run resimg and savimg from an
Ultrix machine and display them on your workstation, or try it the
other direction.

 -dave- 

   RE:.0  

   Actually, there is a rather simple way to get what you want:

   Go into the Session manager Customize menu and select Print Screen.
   Make sure the option 'Prompt for file name' is checked and OK the
   change.

   Now, position the window you want to snapshot and the Session manager window
   so they don't overlap at all.  Usually, you can put the 'target' window
   at the top of the screen and the session manager window at the bottom,
   without overlap.

   From the Print Screen menu on the Session manager, chose Capture Entire
   Screen.  If you did the above step correctly, a modal dialog box should 
   appear with the name of the file the screen image will be placed in.
   Fix the file name if you need to, but don't hit OK yet!

   Now mouse up to the window you want to see the menu on and pull down
   the menu.  Don't give the window input focus (i.e. don't click in the
   window or title bar).  With MB1 holding the menu down, hit the RETURN
   key.  The OK box in the printscreen window will highlight and the
   screen image will reside in the file specified.

   Now all you need do is go into DECW$PAINT and crop out the parts you don't
   want!  

   It's actually much easier than these directions sound!

I hadn't thought about doing that, but it will work, too, provided
that pulling the menu down doesn't cause input focus to move.  I
just tried an experiment with dxmail (on Ultrix) and found that on
one window, pulling down a menu from the menu bar causes input focus
to move and on a different window, input focus doesn't move.  So
I guess it depends on how the application you are getting a picture
of behaves.  

Either way, the session manager print screen functionality should
be split out to a seperate executable with a command line interface.

 -dave-

>Either way, the session manager print screen functionality should
>be split out to a seperate executable with a command line interface.

  Bleah.  I thought the whole idea with direct manipulation interfaces
  was to avoid this sort of stuff.  Next you'll be telling us we need a 
  command line interface to Fileview and UUE :-)!

  But seriously, I think there is a more 'windowy' way to make this easier:

  Enhance the print screen and capture screen doodads so that you can specify
  an amount of time to wait before taking the 'picture' - just like the little
  self timers they put on cameras.   A clever implementation might even
  clean up it's dialog boxes before the snapshot is taken.  

  In fact, I have just such an item for my Mac, and it works great.  I guess
  I just forgot to buy the command line interface for my Mac....

  My .02

  Craig

  

A command line interface to print screen would make it a much better citizen
wrt the rest of the OS than it is now.  Giving it a command line interface
allows it to collect its information up-front all at the same time and run
without bothering the user for more information later.  This doesn't mean that
the user has to pull up a terminal emulator and type the command line.  A
windowy thing could construct the command line instead.

Proposing that print screen have timers added to it is silly.  The functionality
that print screen provides is to capture a piece of the screen.  It should do
exactly that and no more, especially since timers already exist and it is a
simple matter to have print screen run after an external timer has expired.
				Jeff

There are still many people who don't like to use the session
manager.  There are other ways to start sessions, and other
session managers to use.  From a functionality stand point, managing
a session and printing a screen are two completely seperate actions,
and they should be seperate executables.

As for the timer, I kind of like that idea.  However, I still do
a lot of my work from a terminal emulator, and I want to be able
to use input/output redirection and pipes to get my work done.  When
we come up with a visual representation of that, I'll be very happy.

 -dave-

    The other part of the problem with print screen (and other
    DECwindows applications) is that it isn't really playing the
    network and X window game.  I should be able to capture any
    screen on any host that lets me into its display.  Instead,
    print screen, at least as it's packaged, knows only about the
    local display.  
    Perhaps in a future version...
    
    John Hoffman
    ULTRIX DECwindows Engineering

    Thanks to all of you.
    My feeling is that a command line interface for experienced users 
    would be helpful on the screen printer. Perhaps are there other 
    tools which could become more usable for experienced users. 
                
    Best regard,
    	Benoit.

This is the issue of capturing the screen which has a pulldown menu exposed.

I thought of and presented the scenario which is outlined in 941.2 to a 
customer which works fine under DECwindows.  Unfortunately, the 
customer is using the MOTIF window manager, and it does not leave
focus with the modal dialogbox where a filename is prompted.

And it figures that this is for documentation, so they need the Motif WM
design around it.

1) Is Motif WM in error in not leaving input focus with the modal dialog box    
    of the Session Manager?

2) Any other solutions out there that can work under Motif WM?  The tools
    mentioned in 941.1: savimg and resimg, how are they available to a 
    customer?  Can they be used here in this setup, when an (name your)term
    won't keep focus?

Thanks,
Dan

    re:      <<< Note 941.9 by HOTSHT::SCHNEIDER "Where'd all the leaves go?" >>>
                   -< Capture pulldown menu under Motif WM >-
    
>                                            Unfortunately, the 
> customer is using the MOTIF window manager, and it does not leave
> focus with the modal dialogbox where a filename is prompted.
    
    Sounds like your customer is using pointer focus policy.  Have you
    thought of switching to explicit focus to snap the screens?  I use
    pointer too, so I'm not sure if this will work (and I'm at home).  Try:
    
Mwm.keyboardFocusPolicy:		explicit
    
    in the user's .Xdefaults (or DECW$XDEFAULTS.DAT for VMS)?
    
    Regards,
    
    	 	== ken miller ==