michal@kuhub.cc.ukans.edu (Merlin The Magician) (09/04/90)
I need to run a program in a pad that creats a yet another pad
(grpahics). So I decided to do this.
xdmc '(600,500)dr; (1020,768) cp program -n name parameters'
This works well, but there is a few small obstacles I cannot seem to
get around.
1. WHen program quits, pad gets closed but window remains. I need to
remove it using the exit key (or wc -q).
Any way to have the window blow from the display when program
finishes running ? (I tried wc -a, to no avail).
2. After the dr command above, the window gets created ok.
Problem is the next window created after that one is killed is
also of that size (small). Issuing cms or rm does not do the
trick.
Thanks.
--
Merlin [The Magician] (AKA Michal Chmielewski)
US Mail: Academic Computing Services, Univ. of Kansas, Lawrence, KS 66045, USA
E-mail : michal@kuhub.cc.ukans.edu, michal@ukanvax.bitnet, AT&T (913)-864-0443wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (09/05/90)
In article <25406.26e391cb@kuhub.cc.ukans.edu> michal@kuhub.cc.ukans.edu (Merlin The Magician) writes: > > I need to run a program in a pad that creats a yet another pad >(grpahics). So I decided to do this. > xdmc '(600,500)dr; (1020,768) cp program -n name parameters' >This works well, but there is a few small obstacles I cannot seem to >get around. > 1. WHen program quits, pad gets closed but window remains. I need to > remove it using the exit key (or wc -q). > Any way to have the window blow from the display when program > finishes running ? (I tried wc -a, to no avail). I away use the following, which works on OS9.7 and OS10.2: xdmc '(600,500)dr; (1020,768) cp program -n name parameters;wc -a' This way the display manager knows that the wc -a goes with the last window. The other question also bugs me: One can set a range of window size to create. But on a regular basis does the DM decide that it'll make a different size. prefably of the size which was last recently used. I do not want this, how do we get ride of this ? Now as to some questions of the same type: Upon login a script is forked which puts up extra shells (in icons). This give faster login on DN3000, and after a while you still have all the windows you would like. Now the problem is that your cursor bounces around and certainly does not end up in the window where you were. So all keys go into the black hole and the DM gets upset and beeps at you. Is there a way to have the cursor end up in the window where it was before creating the extra icons. Regards, Willem Jan Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands
rees@pisa.ifs.umich.edu (Jim Rees) (09/05/90)
In article <600@eba.eb.ele.tue.nl>, wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) writes:
The other question also bugs me: One can set a range of window size to create.
But on a regular basis does the DM decide that it'll make a different size.
prefably of the size which was last recently used.
I do not want this, how do we get ride of this ?
If you give window dimensions, the DM should always honor them. If you
don't, the DM will use the dimensions of the last window you closed, unless
it has already created a window using those dimensions. Otherwise, the DM
will cycle through your "window defaults," which you set with the 'wdf'
command. You can have as many window defaults as you like, up to some
maximum (10 or so?).
If you want to get a somewhat more rational (in my opinion) behavior than
just cycling through your window defaults, use the undocumented 'wdf -a' DM
command in your startup_login. This will change the behavior so that the DM
will count up how many windows are using each window default, and try to
create the new window in the least busy place (using the default with the
least number of windows already there). This eliminates the annoying case
where you have one window on the screen and the DM decides to put your next
window exactly on top of it.
All this goes out the window (so to speak) if the DM isn't your window
manager. The DM will still try to adhere to the above behavior, but will
fail miserably because your window manager will move each window down after
creation to make room for decorations at the top. This results in your
windows slowly creeping off the bottom of your screen. Most annoying.