Subject: 2.1.1 oddities

From: job bogan <[email-masked]>
Date: Tue, 17 Nov 1998 09:53:22 -0600

--------

(i'm not subscribed, so cc me. =)

well, since people were asking... here are somethings i've noticed w/
2.1.1  i was using 2.0.46 for the last ~6m w/o most of these problems.

*FvwmWinListGeometry -1+1
*FvwmWinListMinWidth 100
*FvwmWinListMaxWidth 130

winlist has a tendancy to creep west.  if i restart fvwm with a smaller
MaxWidth (-n), it will end up living farther and farther west until it's
n pixels off the right edge.  the odd thing is that ident still claims
it has a NE gravity. (did not notice in 2.0.46)

also for winlist, if i use -0+0 for the gravity, it does not stay on
the NE corner. (also in 2.0.46)

pager does not deal w/ 2 displays very well.  I have 2 displays :0.0
:0.1  if i switch from one to the other, pager still marks the last
window that had focus, as still having focus.   (not in 2.0.46)

i'm using sloppy focus.  i go from :0.0 to :0.1, and then return.  the
last window that had focus on :0.0 does not have the focus returned.  in
general, there seem to be focus problems when switching from one display
to the other.  if i use the mouse to move from :0.0 to :0.1 and the
mouse does not pass over any of the root window in :0.1 (eg netscape is
stitting on the screen edge), no window gets focus until i pass over the
root window.  after that, everything is a-ok.  (did not notice in 2.0.46)

if i start up an xterm, and have to click to place it, it will let me
click to place it, and then proceed to place it at +0+0, no matter
what.  if there is enough free space to let fvwm place the window, there
is no problem.  (not in 2.0.46)

buttonbar cannot swallow pager right if i have an odd number of buttons defined.
so, if there is an empty space, it does not swallow pager, and i cannot see if
the buttons are getting drawn ok. (not in 2.0.46)

so, that's what i've found in the last ~3 days...  i'm happy to play
with things to help isolate or fix these problems.

i'm including my .fvwm2rc for reference.

job

---

From: [email-masked]
Date: Tue, 17 Nov 1998 19:54:26 +0100

On Tue, Nov 17, 1998 at 09:53:22AM -0600, [email-masked] wrote:
> winlist has a tendancy to creep west.
> ...

Work on this bug is in progress. Should be fixed in 2.1.2.
(2.1.2 is not out yet).

> root window.  after that, everything is a-ok.  (did not notice in 2.0.46)

? Can't say anything about that.
 
> is no problem.  (not in 2.0.46)

A bug in interactive placement. Hopefully fixed in 2.1.2. If not,
please post this again.
 
> the buttons are getting drawn ok. (not in 2.0.46)

I'm not sure I understand correctly. Do you mean you actually
USE an odd number of buttons or has the whole button bar an
odd number? Could you please post the FvwmButtons config
strings that reproduce/solve this? (Plus the Pager config in
the same mail, please).

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 23 Nov 1998 11:20:10 +0100

> root window.  after that, everything is a-ok.  (did not notice in 2.0.46)

I'm not quite sure what you mean. You say 'display', but :0.0 and
:0.1 are different *screens* on a single display. Don't know if
fvwm deals with more than one screen at all (can somebody help me
out here?). I have not the slightest idea how to connect more than
one screen to an X server and how to switch between them. But perhaps
you are talking about desks? Or pages (your comment about mouse
movement suggests this)?

 - Display: every display has it's own X server and fvwm2 running.
            Therefore you cannot 'switch' fvwm2 between them.

 - Screen: don't know. If that is what you have please tell me how
           I can connect/switch multiple screens to my X server
           (XFree86).

 - Desk: yes, the focus isn't returned to the original window that had
         the focus when you first switched desks. This has nothing to do
         with the pager (FvwmPager I assume) however. And this has not
         changed between 2.0.46 and 2.1.x. You can't switch desks with
         mouse movement.

 - Page: nothing strange with the focus here. It works like it should
         as it did in 2.0.46. This isn't related to FvwmPager either.
         The focus is never switched when you change pages. Only if
         the pointer happens upon another window that window may
         receive the focus. Works as intended.

Please clarify what you did (if you don't know exactly what 'desk,
'page', 'screen' (not the same as an X screen like :0.0 and :0.1)
and 'virtual desktop' mean, please have a look at the fvwm2 manpage.
The terms are explained in detail there.

Thanks

Dominik

---

From: job bogan <[email-masked]>
Date: Mon, 23 Nov 1998 07:53:25 -0600

Your message dated: Mon, 23 Nov 1998 11:20:10 +0100

>:0.1 are different *screens* on a single display. Don't know if

i was using display in the sense of monitor/frame buffer/whatever.

how about this for clarification:

sun ultra 170E:
/dev/fb0 is a creator (24bit accel) :0.1
/dev/fb1 is a cgsix (8bit accel card) :0.0

i'm starting X with this line in /usr/dt/config/Xservers.  i'm using CDE
and have added fvwm to the menu of windowmanagers/env's to choose from.

:0   Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -dev /dev/fb0 right -dev /dev/fb1 left

I end up with X running on both frame buffers. the login screen is on
the cgsix.  And i can move my mouse off the right edge of :0.0 and end
up on the left edge of :0.1.  it's a pretty normal multihead X setup.
You can get the same type of thing with 2 matrox boards under linux.

>out here?). I have not the slightest idea how to connect more than

it forks off a second copy to run on the separate display. (see -s flag)

>you are talking about desks? Or pages (your comment about mouse

??  i'm not sure i follow you.  i'm not talking about desks, oversized
desktops, or anything of that ilk.

the basic problem is that fvwm does not seem to understand what to do
when the mouse is not anywhere on it's $DISPLAY.  

I don;t know X internals very well, but something like this would fix
the problem (i think):

when the mouse moves off a DISPLAY, drop all focus.
when the mouse returns to a DISPLAY, give focus back to the last window
that had focus.

I'd guess that you could do that by looking for stuff happening with the
root window.  or perhaps by putting a 0 width border around the root
window, and looking for events that indicate that the mouse is not on
DISPLAY anymore.  it does not seem like knowing which DISPLAY/fvwm has
the focus/mouse; since i can use cntl-<arrow> to move around within the
current desk.

or maybe when the 2nd copy of fvwm gets forks off, a pipe could be setup
between the two so they know what's happening?

i'd be happy to play with this more, or turn on prolific logging.

thanks

job

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 23 Nov 1998 15:05:07 +0100

> You can get the same type of thing with 2 matrox boards under linux.

Duh, I don't have two graphics cards. Can't help you much with
that, sorry.

> when the mouse returns to a DISPLAY, give focus back to the last window

Sorry, you insist on calling sth a display that is clearly called
a screen in X terminology if the numbers are correct, :0.0 and :0.1
are the same display but a different screen.

Anyway, anybody on the list that can duplicate this setup to verify
what is happening?

Bye

Dominik

---

From: "Eddy J. Gurney" <[email-masked]>
Date: Mon, 23 Nov 1998 09:41:42 -0500

On Nov 23 at  7:53, job bogan wrote:
,--
| >fvwm deals with more than one screen at all (can somebody help me
| >out here?). I have not the slightest idea how to connect more than
|
| it forks off a second copy to run on the separate display. (see -s flag)
`--
Don't remind me. :-) This is one of my biggest complaints with fvwm2. I
run an Ultra 170E with nearly the same configuration (Creator card
is :0.0, cgsix is :0.1 in my case; haven't tried the latest 2.1.2
release to see if there are problems with multiple heads; still running
2.0.46 here.) The fact that I have to fork two copies of fvwm2, two
FvwmButtons, two FvwmPagers, two FvwmIconMans, two FvwmAuto's, etc. is
really a bummer. `vtwm' (Virtual Tab Window Manager?) can happily
handle multi-headed X sessions without forking. If there is one thing I
*really* wish for in fvwm2 it is the the ability of the window manager
itself and all of the modules to handle multiple instantiations (i.e.,
multiple button bars, multiple pagers, etc.) _without_ having to fork
for each display. It seems like such a waste of precious resources... :-)
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Mon, 23 Nov 1998 10:26:36 -0500

> for each display. It seems like such a waste of precious resources... :-)

Hmm... Ultra 170E and precious resources, oh right, I see the smiley.

At  least 2 of the maintainers  (Dominik and myself) lack multi-headed
displays.  As for myself, not having a multi-headed display, I am at a
loss to appreciate the problems this forking causes.  It would seem to
me that running 2 copies of the same program by way of a fork would be
pretty efficient.

I would  also guess that a workstation  with more than 1 display would
tend to  be  high powered.    This would  argue  for using   addtional
resources   in  the  multi-headed     case,  and  optimizing for   the
non-multi-headed case.

Anyway, the point I am  trying to make is, we  can't do much about the
"don't remind me" issues without patches.  Even  with patches, some of
us can't do any realistic testing, so patches, and testing are needed.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Eddy J. Gurney" <[email-masked]>
Date: Mon, 23 Nov 1998 10:58:08 -0500

On Nov 23 at 10:26, Dan Espen wrote:
,--
| "Eddy J. Gurney" <[email-masked]> writes:
| > On Nov 23 at  7:53, job bogan wrote:
| > ,--
| > | >fvwm deals with more than one screen at all (can somebody help me
| > | >out here?). I have not the slightest idea how to connect more than
| > |
| > | it forks off a second copy to run on the separate display. (see -s flag)
| > `--
| > Don't remind me. :-) This is one of my biggest complaints with fvwm2. I
| > run an Ultra 170E with nearly the same configuration (Creator card
| > is :0.0, cgsix is :0.1 in my case; haven't tried the latest 2.1.2
| > release to see if there are problems with multiple heads; still running
| > 2.0.46 here.) The fact that I have to fork two copies of fvwm2, two
| > FvwmButtons, two FvwmPagers, two FvwmIconMans, two FvwmAuto's, etc. is
| > really a bummer. `vtwm' (Virtual Tab Window Manager?) can happily
| > handle multi-headed X sessions without forking. If there is one thing I
| > *really* wish for in fvwm2 it is the the ability of the window manager
| > itself and all of the modules to handle multiple instantiations (i.e.,
| > multiple button bars, multiple pagers, etc.) _without_ having to fork
| > for each display. It seems like such a waste of precious resources... :-)
|
| Hmm... Ultra 170E and precious resources, oh right, I see the smiley.
|
| At  least 2 of the maintainers  (Dominik and myself) lack multi-headed
| displays.  As for myself, not having a multi-headed display, I am at a
| loss to appreciate the problems this forking causes.  It would seem to
| me that running 2 copies of the same program by way of a fork would be
| pretty efficient.
`--
I guess I just find the fact that every instantiation of an Fvwm "feature"
takes about a megbyte of "real" memory (and 2.5MB of virtual memory) a little
disconcerting:

USER       PID %CPU %MEM   SZ  RSS TT       S    START  TIME COMMAND
eddy      1888  0.1  1.5 3104 1792 console  S   Nov 11  1:42 fvwm2 -cmd FvwmM4
eddy      1890  0.1  1.1 3016 1368 console  S   Nov 11  0:38 fvwm2 -cmd FvwmM4
eddy      1986  0.0  0.9 2648 1080 console  S   Nov 11  0:02 FvwmButtons
eddy      1989  0.0  0.9 2656 1152 console  S   Nov 11  0:03 FvwmButtons
eddy      1995  0.0  0.9 2648 1064 console  S   Nov 11  0:00 FvwmButtons
eddy      1998  0.0  1.0 2656 1200 console  S   Nov 11  0:00 FvwmButtons
eddy      1993  0.0  1.0 2752 1280 console  S   Nov 11  0:14 FvwmIconMan
eddy      2007  0.0  1.0 2672 1232 console  S   Nov 11  0:03 FvwmIconMan
eddy      2014  0.0  1.0 2656 1224 console  S   Nov 11  0:08 FvwmPager
eddy      2019  0.0  1.0 2664 1240 console  S   Nov 11  0:19 FvwmPager
eddy      8790  0.2  1.2 2576 1440 console  S 10:38:35  0:00 FvwmAuto
eddy      8786  0.1  1.2 2576 1440 console  S 10:38:20  0:00 FvwmAuto

2.5MB virtual/1.4MB real (per display) to get auto-raise
functionality? Modules are a nice way to add "big" features, but couldn't
auto-raise be added in a couple K if it were part of the fvwm2 proper?

Now I am not one to take the memory requirements reported by `ps' as
gospel (nobody can ever give me a straight answer on how to determine
the *real* memory requirements of a process), but adding up the above
indicates about 32MB of virtual and about 16MB of real memory. That seems
like a lot to me. :-) I only recently upgraded my machine to 128MB of
RAM, so fvwm2 and "friends" was using a pretty decent chunk (nothing
compared to the X server itself or Netscape, of course :-).

Hopefully more people will start using multiple video cards in Linux-type
systems so testing the multi-headed-ness of fvwm2 is nice and thorough. I
know that with the MetroX server and Matrox video cards, you can run
multi-headed in Linux today (up to 4 cards I think).

,--
| Anyway, the point I am  trying to make is, we  can't do much about the
| "don't remind me" issues without patches.  Even  with patches, some of
| us can't do any realistic testing, so patches, and testing are needed.
`--
Hope you guys didn't take it the wrong way; I just was pointing out
something that I thought would be nice to be looked at. I really appreciate
all the work the current maintainers are doing on fvwm2, and I look forward
to the next "official" release so I can update all our workstations here
from 2.0.45 to 2.2. :-)

Keep up the great work!!

---

From: "Eddy J. Gurney" <[email-masked]>
Date: Mon, 23 Nov 1998 12:40:32 -0500

(Subject changed from "2.1.1 oddities")

On Nov 23 at 11:02, Jason L Tibbitts III wrote:
,--
| >>>>> "EJG" == Eddy J Gurney <[email-masked]> writes:
| EJG> I guess I just find the fact that every instantiation of an Fvwm
| EJG> "feature" takes about a megbyte of "real" memory (and 2.5MB of virtual
| EJG> memory) a little disconcerting:
|
| Ummm, most of that is going to be libc, and just about all of it is shared
| between two invocations of the same program.  How much memory does it
| really take (in non-library, non-shared pages)?  If you fork and run the
| same code the memory cost is near zero; any OS that doesn't suck will share
| the code pages and mark the data pages copy-on-write.  What ps is giving
| you is true if you look at the programs individually, but taken as a
| collection the real memory hit should be much smaller.
`--
Right. I assumed the shared libc portion in the non-resident virtual
memory space (the 2.5MB space). I could be wrong about this, but I don't
think the memory from multiple FvwmAuto or FvwmButton instantiations is
shared. That would mean that FvwmButton of FvwmAuto is the one doing the
forking, and I don't think that is the case. It appears that fvwm2 spawns
all of the child processes:

 F   UID   PID  PPID CP PRI NI   SZ  RSS    WCHAN S TT        TIME COMMAND
 8  3271  1888  1874  0  58 20 3112 1760   mm_dip S console   1:45 fvwm2 -cmd
 8  3271  1890  1888  0  58 20 3016 1376   mm_dip S console   0:41 fvwm2 -cmd
 8  3271  1986  1888  0  58 20 2648 1080   mm_dip S console   0:02 FvwmButtons
 8  3271  1989  1888  0  58 20 2656 1152   mm_dip S console   0:03 FvwmButtons
 8  3271  1993  1888  0  58 20 2752 1280   mm_dip S console   0:14 FvwmIconMan
 8  3271  1995  1890  0  58 20 2648 1064   mm_dip S console   0:00 FvwmButtons
 8  3271  1998  1890  0  58 20 2656 1200   mm_dip S console   0:00 FvwmButtons
 8  3271  2007  1890  0  58 20 2672 1232   mm_dip S console   0:03 FvwmIconMan
 8  3271  2014  1890  0  58 20 2656 1224   mm_dip S console   0:09 FvwmPager
 8  3271  2019  1888  0  58 20 2672 1240   mm_dip S console   0:19 FvwmPager

Looking at the Parent Process ID of all these modules, they are
all children of fvwm2 (which the first one should be, but not the
second/third/fourth copies if what you are saying holds true). But I
guess I didn't make that point very clear in my first message. In other
words, they all appear to be separate entities. This is already pushing
my limited knowledge of the Unix kernel, but are saying the OS is smart
enough to share page space amongst all child processes? (i.e., fvwm2
spawns three copies of FvwmButtons, the OS is smart enough to share the
code space amongst those three processes?) That would be pretty cool. :-)

(Note that the second copy of fvwm2 *is* a child of the first fvwm2 process.)

Eddy

---

From: Jason L Tibbitts III <[email-masked]>
Date: 23 Nov 1998 11:02:56 -0600

>>>>> "EJG" == Eddy J Gurney <[email-masked]> writes:

EJG> I guess I just find the fact that every instantiation of an Fvwm
EJG> "feature" takes about a megbyte of "real" memory (and 2.5MB of virtual
EJG> memory) a little disconcerting:

Ummm, most of that is going to be libc, and just about all of it is shared
between two invocations of the same program.  How much memory does it
really take (in non-library, non-shared pages)?  If you fork and run the
same code the memory cost is near zero; any OS that doesn't suck will share
the code pages and mark the data pages copy-on-write.  What ps is giving
you is true if you look at the programs individually, but taken as a
collection the real memory hit should be much smaller.

 - J<

---

From: Jason L Tibbitts III <[email-masked]>
Date: 23 Nov 1998 11:54:06 -0600

>>>>> "EJG" == Eddy J Gurney <[email-masked]> writes:

EJG> I could be wrong about this, but I don't think the memory from
EJG> multiple FvwmAuto or FvwmButton instantiations is shared.

If it isn't, you need to be looking for a new OS.  Code pages should be
shared off of the disk; running the same program a pile of times should
result in all of its code pages being shared between all invocations.

EJG> This is already pushing my limited knowledge of the Unix kernel, but
EJG> are saying the OS is smart enough to share page space amongst all
EJG> child processes?

If the OS is worth anything, it will do this.

It would still be nicer if modules were implemented as shared libraries
instead as separate processes, but that's a lot of work.

 - J<

---

From: Dan Espen <[email-masked]>
Date: Mon, 23 Nov 1998 14:02:45 -0500

> If the OS is worth anything, it will do this.

I  think its safe to say,  all UNIXs do this.  As  Eddy said when this
started out, "ps" is not to be trusted for this kind of information.

So, I think we are beyond the issue  of the "fork" consuming resources
and this being a problem in itself.

> instead as separate processes, but that's a lot of work.

I've heard this one before, but can't say that I see where a "dlopen?"
would be significantly better than the current "fork"/"execvp".

Is the gain in function calls vs. pipe reading and writing?  Isn't the
asynchronous nature of the modules  an advantage in  most cases?   How
would we make shared libraries ansynchonous?

I do see the advantage to making libfvwm.a into a shared library, I'm
just not sure what the issue is with the modules.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 23 Nov 1998 14:04:30 -0600

>>>>> "DE" == Dan Espen <[email-masked]> writes:

DE> I think its safe to say, all UNIXs do this.

Maybe not Ultrix.  ^_^

DE> So, I think we are beyond the issue of the "fork" consuming resources
DE> and this being a problem in itself.

I hope so.  I think most object to it because when you type ps you get a
pile of processes.

DE> I've heard this one before, but can't say that I see where a "dlopen?"
DE> would be significantly better than the current "fork"/"execvp".

Depends on what you consider 'significant'.  Slightly lower footprint, fast
nature of function calls, no task switch overhead, etc.  Most machines are
fast/big enough to not care, but then if your machine is really fast and
big you probably aren't using FVWM for its size.

I suppose it would be nice if some of the folks who really hate the fact that
FVWM spawns piles of processes to put some work into proving the worth of
some alternatives.  (That's what my 'goad' was intended to elicit.)

 - J<

---

From: Mohsin_Ahmed <[email-masked]>
Date: Tue, 24 Nov 1998 11:01:45 +0530 (IST)

An idle FvwmCommand caused a network traffic jam here
by unnecessarily accessing my NFS mounted ~/FvwmCommand* files.

A UDP/IP based IPC (with X/Cookie based authorization) would
have really cut down io. Besides it is more generalized and
low on overheads. Any reason for choosing files for IPC?

- Mohsin,       [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Tue, 24 Nov 1998 10:19:30 +0000

> some alternatives.  (That's what my 'goad' was intended to elicit.)

There's a discussion going on with Scwm at the moment about how to stop
Scwm killing itself.  Scwm aims to do everything itself without modules
and to help this it uses guile-gtk (some sort of library that lets
scheme code create windows). When a user kills one of these windows Scwm
dutifully kills the client connection (which is Scwm) and boom! bye-bye
Scwm.  Fixing this is very difficult.

The nice thing about Fvwm modules is that they can die with no risk of
killing Fvwm. It means Fvwm can be a window manager and other bits of
GUI can be provided separately.

If it really is a pain to have lots of processes I would suggest having
a mega module that has the usual modules linked in as dynamic libraries.
That would cut the number of processes down to two per screen and leave
Fvwm unchanged.

Cheers,
Tim.