Subject: Re: FVWM: i can't run fvwm 2.4

From: John Latham <[email-masked]>
Date: Thu, 5 Sep 2002 17:22:57 +0100

> Date: Tue, 03 Sep 2002 11:27:37 -0600
> From: Gregg Dameron <[email-masked]>
> To: [email-masked]

> John Latham wrote:
>
> > I've just noticed that the one I thought might be the most helpful,
> > ResizeHintOverride actually is already there in 2.4 -- for some reason I
> > thought it was only in 2.5. (I am hoping this will help combat the quite
> > common but appalling 1x1, modal, nonresizable dialog ``feature''!!!!)
>
> If a solution to the 1x1 presents itself, please post it.  We've been fighting this
> one in 2.4.7 (and prior to that, under fvwm95 for many years).  It seems to happen
> more frequently if the CPU is under load.
>
> Gregg Dameron

Success -- I just managed it!!!!!!!

I have in the last day or so started to build up a set of togglable java bug
work arounds to put on the menu in AnotherLevelUp. This allows the user to
switch them on/off at will in a persistent way (i.e. next start/restart has
them on/off as you last left them). This reduces the risk of unforseen side
effects, if they were enabled for everyone all the time, and allows users to
experiment and report back what works, how and when.

So far I have implemented 3, and 2 of them certainly seem to help, at least
with blackdown's jdk1.3. I have yet to see any effect from the first one
below. For now I am calling them:

1)	BugOpts ModalityIsEvil

2)	Style AWTdialog ResizeHintOverride

3)	FvwmEvent AWT add_window Deiconify

1) is one of the recommended Java 1.3 `fixes', but I have not yet seen it have
any effect (but have not really given it a good try).

2) I have just managed to successfully use this against a 1x1 modal dialog --
I was able to stretch it out and the real contents appeared!! We're
celebrating here! (BTW, it was the tip of the day dialog for Together 6.)

3) I have successfully used this to get around the non-reappearing dialog and
(app) windows: viz a dialog is created and mapped, user dismisses it, then
later it is reshown, but is remapped iconified. Particularly devastating if
you do not have transient windows appearing in task vars or as icons, etc..
This fix deiconifies all AWTdialog and AWTapp windows when they are mapped,
and it seems to work so far.

I can post the toggle mechanism that AnotherLevelUp uses, if you wish, but
attached are the guts of the work arounds so far, as hopefully self evident
functions.

Best wishes, John Latham
================================================================================

DestroyFunc ToggleJAVAModalityIsEvilOn
AddToFunc ToggleJAVAModalityIsEvilOn
+ "I" BugOpts ModalityIsEvil

DestroyFunc ToggleJAVAModalityIsEvilOff
AddToFunc ToggleJAVAModalityIsEvilOff
+ "I" FvwmForm RestartAfterChanges

DestroyFunc ToggleJAVAAWTdialogResizeHintOverrideOn
AddToFunc ToggleJAVAAWTdialogResizeHintOverrideOn
+ "I" Style AWTdialog ResizeHintOverride
+ "I" Recapture

DestroyFunc ToggleJAVAAWTdialogResizeHintOverrideOff
AddToFunc ToggleJAVAAWTdialogResizeHintOverrideOff
+ "I" Style AWTdialog NoResizeOverride
+ "I" Recapture

DestroyFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOn
AddToFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOn
+ "I" *JAVAFvwmEvent: Cmd Function
+ "I" *JAVAFvwmEvent: PassID
+ "I" *JAVAFvwmEvent: add_window DeIconfiyGivenWindowIfAWT
+ "I" Module FvwmEvent JAVAFvwmEvent

DestroyFunc DeIconfiyGivenWindowIfAWT
AddToFunc DeIconfiyGivenWindowIfAWT
+ "I" WindowId $0 (AWTapp) Iconify off
+ "I" WindowId $0 (AWTdialog) Iconify off

DestroyFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOff
AddToFunc ToggleJAVAFvwmEventAWTAddWindowDeIconifyOff
+ "I" KillModule FvwmEvent JAVAFvwmEvent
+ "I" DestroyModuleConfig JAVAFvwmEvent*

*RestartAfterChangesWarpPointer
*RestartAfterChangesFont	fixed
*RestartAfterChangesButtonFont	*helvetica*medium-r*12*
*RestartAfterChangesInputFont	fixed
*RestartAfterChangesFore	#FFFFFF
*RestartAfterChangesBack	#E64080
*RestartAfterChangesItemFore	#FFFFFF
*RestartAfterChangesItemBack	#19007F
*RestartAfterChangesLine left
*RestartAfterChangesText "The changes you have made will not apply until you"
*RestartAfterChangesLine left
*RestartAfterChangesText "next restart Fvwm2."
*RestartAfterChangesLine expand
*RestartAfterChangesLine left
*RestartAfterChangesText "If you want to make more changes first,"
*RestartAfterChangesLine left
*RestartAfterChangesText "you may ignore this form until you are ready,"
*RestartAfterChangesLine left
*RestartAfterChangesText "or make it go away for now."
*RestartAfterChangesLine expand
*RestartAfterChangesLine expand
*RestartAfterChangesLine expand
*RestartAfterChangesButton quit "I want to Restart now" ^M
*RestartAfterChangesCommand Function ReallyRestartWithoutRandomPreferences
*RestartAfterChangesButton quit "Go away - I will Restart later"  ^C
*RestartAfterChangesCommand Nop
Style RestartAfterChanges StaysOnTop,Sticky

AddToFunc ReallyRestartWithoutRandomPreferences
# AnotherLevelUp has lots of stuff here, but the main thing is:
+ "I" Restart
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Gregg Dameron <[email-masked]>
Date: Tue, 10 Sep 2002 16:40:45 -0600

> experiment and report back what works, how and when.

Thanks for your post, John - please excuse my delay in responding.

Strangely, our 1x1 dialog problem is not Java related.  It's happening on dialogs
created by XmCreateMessageDialog() in C code.  As I mentioned, it's more likely to occur
when the CPU is under load and/or the X server has a backlog of events to work through
due to being swapped out.  Our workaround is to add a map callback for the dialog; when
it fires, we see if the dialog was mapped "too small" and if so, allow the dialog shell
to become resizeable (we are also looking at a programmatic forced resize to a hardwired
height and width).

My suspicion is that both your problem and ours have the same root cause, but at this
point I can't be sure whether it's an fvwm problem or an X server problem.  (We run
2.4.7 on Solaris 8 now; previously we ran fvwm95 on Solaris 7.)

I'd be curious to know if anyone else has seen the 1x1 problem outside of Java.

Gregg Dameron