When I log in, running fvwm as my CDE wm, it starts up fvwmpager and
fvwmbuttons, then
waits 10 minutes (I've timed it) before starting my home session. During
that time, fvwm is
sitting there with an hourglass cursor and is unresponsive.
I'm sure it's my fault, but I can't imagine what the problem is. I'm using
the same fvwm2rc
I used at my previous job, and my home session consists of 5 xterms.
Also, is there a way to get apps in the home session to start on a
specified workspace?
---
Michael Lindner
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majo...@hpc.uh.edu.
To report problems, send mail to fvwm-...@hpc.uh.edu.
Thanks for your help, but that did not change the timeout. I even tried
changing the "1" to
larger and smaller (well, 0) numbers, to no avail.
Regarding the window starts on workspace question, doesn't StartsOnDesk
start the app on a different desktop? I'm trying to start it on the same
desktop but in a different workspace (or perhaps I'm using desktop and
workspace wrong - a workspace is a box in the pager - can you display all
the desktops in the pager and page through them instead)?
> Regarding the window starts on workspace question, doesn't StartsOnDesk
> start the app on a different desktop? I'm trying to start it on the same
> desktop but in a different workspace (or perhaps I'm using desktop and
> workspace wrong - a workspace is a box in the pager - can you display all
> the desktops in the pager and page through them instead)?
Ok, first the terminology. Fvwm uses the terms desktop (same as the
X property) and page or viewport (a screen-sized subdivision of the virtual
desktop). If you specify DeskTopSize 3x3, you have a virtual desktop of 9
pages arranged in a 3x3 grid. What many window managers refer to as
workspaces are functionally equivalent to Fvwm's desktops.
There is a fixed number of pages per desktop (set by DeskTopSize -
though you *can* reconfigure that while running). There is no fixed number
of desktops. You can arbitrarily assign an app to desk 38 if you like,
though it would probably be a bit silly. The pager *displays* a fixed number
of desktops depending on the arguments with which it was started, and the
*FvwmPager section of your fvwm2rc allows you to assign titles to the
desktops, that the pager will display.
I normally start the pager with
"I" Module FvwmPager 0 4
which has the pager display all 5 of my 4x4 desktops. If I said instead
"I" Module FvemPager 0 1
it would display only the first two desktops. When the pager is iconified,
the icon displays an image of the current desktop.
Now, as to starting an app on a particular page, there are two
options. One is to start the app with very large x,y coordinates to try
to position the windows on the page where you want them. The disadvantage
is that you must always start the app from a particular page, since the
geometry offsets are always calculated relative to where you are at the
moment. (Also, obviously, the app must understand *and* correctly handle
a standard geometry argument. Some don't.)
The second option is to apply my StartsOnPage patch, available at
http://www.pcnet.com/~proteus/Fvwm/FvwmPatches.html
The patch is written against version 2.0.46. Basically, it adds a new
command, StartsOnPage, which can be used as a replacement for StartsOnDesk.
With a single argument, it operates like StartsOnDesk. With three arguments,
it sets the desk and page. (With two arguments, it sets the page and uses
the current desk.)
I hope this helps a bit.
/// Magnus Back
M&T> I have read earlier postings about the 2.0.47d release of fvwm2.
It is not a release. It is a testing version for use by the folks on
fvwm-workers. If you want to talk about it, you should join the
fvwm-workers list.
M&T> Why isn't it stored on the official ftp server?
Because it's not a release.
- J<
OK, this may not even be an FVWM problem, but thanks in advance for any
help you can give me. I have tried starting fvwm 3 different ways:
1. I edited my .Xdefaults file and added
*wmStartupCommand: /usr/openwin/bin/fvwm2
*waitWmTimeout: 1
and started a CDE session.
2. I set and exported OW_WINDOW_MANAGER=/usr/openwin/bin/fvwm2 in my .profile
and started an OpenLook session.
3. I followed the advice of a post in the archives and set up an FVWM
session from the
login screen.
ALL of these methods starts up fvwm2, but all of them suffer from the same
problem. I have since learned that even a "straight" CDE session, using
dtwm, or a "straight" OpenLook session using olwm suffers from this problem
- after the window manager starts, it sits there for EXACTLY 10 minutes,
then starts the home or current session (i.e. starts up apps).
During the 10 minutes, the cursor is an hourglass, and the WM is
unresponsive. What's even worse is that this problem only affects me.
Other users using the machine, even with the identical environment and
$HOME/.* files don't see the 10 minute delay. I tried removing my $HOME
and making an empty one, thinking I had some wierd file in there, but it
still takes 10 minutes.
I tried doing a "ps" during the 10 minute hang and after, and they are
identical - no processes are started or finished (except, of course, for my
session apps), and no CPU is used during the 10 minutes.
Since there are no man pages available to me on any of the "dt" commands, I
tried copying all the startup files and adding "set -x" to them. I though
the command "ttsession" was the culprit, but I'm not so sure.
Has anyone seen this behavior, or have a clue where there's a 10 minute
time out in the Solaris startup cr*p?
Since I'm seeing this with dtwm and olwm, I'm assuming this is NOT an FVWM
problem, so I will not trouble this list further with this issue, and thank
you for your indulgence in ranging off-topic.
---
Michael Lindner