>>>>> "Dan" == Dan Calle <dcalle_at_falcon.gu.sbc.edu> writes:
Dan> First I have a question and then I'll get on with the bug report.
Dan> It's not in the FAQ so - what exactly is the purpose of libfvwm2.a?
Dan> Is it only for those who wish to write modules or what?
Basically (it's used to link fvwm itself too). It really doesn't need
to be installed, although I believe it currently is installed.
Dan> "Charles Hines" <chuck_hines_at_VNET.IBM.COM> wrote:
>> I'd like to make this the last beta before the first official
>> release (2.1.0). So let me know what other problems you find with
>> it so I can clean it up (especially build and doc problems). Bear
>> in mind that I can't fix ALL of it's bugs, especially the one's I
>> can't reproduce...
Dan> Background info:
Dan> I'm running Digital UNIX 3.2c on an AlphaStation and 3.0 on a DEC
Dan> 3000/300LX Alpha. Both systems have X11R5 and the XPM libs. Fvwm was
Dan> compiled "out of the box" with xmkmf;make Makefiles;make;make install;
Dan> make install.man - all I changed in Fvwm.tmpl were the destination
Dan> directories for the install.
Dan> Bug 1:
Dan> This had appeared on the DEC 3000 since 2.0.42 but didn't show up on
Dan> the AlphaStation 'til 2.0.43. Often, edgescroll won't work. I'll
Dan> drag and drag and it won't switch pages. If I then hit Control-right,
Dan> it works fine, and thereafter edgescroll works normally. I'm not sure
Dan> if the problem stays fixed 'til I next log out and back in again
Dan> though. The relevant lines from my .fvwm2rc file are:
....
I've seen some reports about this, but cannot reproduce it myself. I
think I need to put a remark in the BUGS file about it.
Just out of curiousity, is everyone else who is seeing it running on
DEC machines as well?
Dan> Bug 2:
Dan> xlock -mode flame has started dying after a few minutes of running.
Dan> The error is:
Dan> /bin/sh: 1416 Floating exception
Dan> where the number is the PID of:
Dan> /bin/sh -c xlock -nolock -mode flame
Dan> Previously the only mode I'd ever had trouble with was "galaxy". I
Dan> don't know which of the last few versions this might have appeared in
Dan> because I don't run XLock that often. I can't really say for certain
Dan> that it's fvwm but I haven't changed anything else that would affect
Dan> it.
....
Actually, I think this is a bug with xlock. Do you see the same
problems if you run xlock by hand? I've seen problems like this with
xlock in various modes core dumping (or locking up the machine
entirely) on PowerPC based machines, but haven't had a chance to
investigate yet.
Dan> Bug 3:
Dan> The bug I mentioned in another message in which one of my xterms
Dan> wasn't getting the Styles hasn't been fixed and may be worse.
Dan> I'm not sure it was supposed to have been fixed but "Simple patch
Dan> to help take care of some timing bugs" might be referring to it.
Dan> To reiterate, the first xterm I run in my .xsession often,
Dan> especially on the slower machine, does not get any Styles (not *,
Dan> not xterm, nothing) even though the other xterms (also run from
Dan> the .xsession after a short "sleep" delay...probably not starting
Dan> until after fvwm2 is already running) do get the Styles.
Dan> Restarting fvwm2 fixes this problem but, if I do it before some
Dan> of the other delayed jobs in the .xsession finish, some of them
Dan> will never finish and I end up with no xclock or xpostit+ or
Dan> something.
Dan> The reason I say this may be worse is that it's now happening more
Dan> often on the AlphaStation, which is faster and hardly ever needs to
Dan> swap. In 2.0.42, it usually happened on the slower, lower RAM,
Dan> machine and only occasionally on the fast machine.
The "Simple patch..." does not address this problem. As I said in a
note a few days ago (I believe), I know what is causing this problem
and have a good idea how to fix it.
In a nutshell, fvwm isn't Grabbing the server soon enough and new
windows are popping up after the list of windows to traverse has been
made (which is why they don't get updated). The least destructive fix
that I can think of is to move the initial XGrabServer call up a
little, but some of the functions that are called below it make calls
to XGrabServer and XUngrabServer, which don't keep track of the total
grab request count (ie the first XUngrabServer could mess things up
again), so I'm creating my own wrappers around XGrab/UngrabServer to
keep track of the count and only ungrab after all corresponding grabs
& ungrabs are done which should fix the problem. It'll be in 2.1.0,
although I may mail out a patch for people to try early.
Dan> Request for 2.1.0:
Dan> Not a bug report and I know the TO-DO list mentions resurrecting
Dan> StubbornPlacement but, in case it's not implicitly grouped with
Dan> StubbornPlacement, the return of StubbornIconPlacement would also be
Dan> very nice - especially the feature that caused icons to reposition
Dan> themselves to avoid windows when the Scroll function was called. I
Dan> had gotten used to not having to search for icons under windows.
Neither of them will be in 2.1.0, but I have had the latter in mind
for part of the "better icon handling needed?" entry.
Chuck
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Jul 15 1996 - 11:20:16 BST