Subject: Broken Java GUIs and Fvwm

From: Dan Espen <[email-masked]>
Date: Thu, 11 Jan 2001 14:40:18 -0500

I think this has come up before, but I don't think we've resolved it.
If we have, tell me and I apologise in advance.

My users are starting to use some Java GUIs,  and they report problems
with the way the GUI components lay out under Fvwm that they don't see
under CDE (dtwm).

I have a sample program which I will attach.  I got  the sample from a
KDE mailing list.  It looks like the same  problem exists (or existed)
in KDE (Sawfish?).  When you run the sample program, you get a window,
click on the middle of  the window and it pops  up another window that
has a cancel button at the bottom.  The bottom of the cancel button is
clipped off.

I tried the same program under twm and olwm and I see the same problem.

I  tried the same program  under  mwm and  dtwm and  the cancel button
displays correctly.

Here is the interesting part.

If I  just exit fvwm,  leaving  X running, and  go into  dtwm, the GUI
works.  If I then "kill -9" dtwm, still leaving X running, and go back
into fvwm, the GUI works under Fvwm!

The same thing  happens with mwm.  If I  "kill -9" mwm, mwm apparently
leaves something around that makes the Java app continue to work.

I have no way to exit dtwm cleanly (it refuses to), but if I exit mwm
cleanly (using its menus), and return to fvwm, the GUI doesn't work.

I concluded that mwm and dtwm leave something in X that Java uses to
determine when to behave correctly.  I used xprop to find all the
properties that dtwm leaves on the root window.  I then removed them
all while in fvwm, and that didn't make the GUI start to misbehave.

I then used "xwininfo -root -all" to see what else  I can find.  I see
that both dtwm and mwm leave a  10x10-100-100 window.  Mwm will remove
the window when you exit  cleanly, so its  possible that its the 10x10
window or some property that mwm puts on the  window that Java uses to
know when to behave.

I was looking for a way to kill the window, but I don't know of a tool
that will do that.  The window is override redirect:

xwininfo: Window id: 0x140002b (has no name)
  Absolute upper-left X:  -100
  Absolute upper-left Y:  -100
  Relative upper-left X:  -100
  Relative upper-left Y:  -100
  Width: 10
  Height: 10
  Depth: 0
  Visual Class: PseudoColor
  Border width: 0
  Class: InputOnly
  Colormap: 0x0 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +-100+-100  -1370+-100  -1370-1114  +-100-1114
  -geometry 10x10+-100+-100

Other than killing the window, I guess I could hack something together
to create the  window myself.  Of  course I  don't  know yet that  the
mystery window has anything to do with the Java problem.

My conclusion is that fvwm is not doing anything wrong.
Instead, Java seems to be hardwired into dtwm.  If it doesn't see
dtwm, it doesn't work.

Well, anyway, here is the sample program:

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 9 Jan 1904 21:10:48 +0100

> If we have, tell me and I apologise in advance.

No, we didn't.  Our past approach was to insist that Java is
broken (which still holds true) and to do nothing.

> has a cancel button at the bottom.  The bottom of the cancel button is

Do you see any chance to get some information from the KDE or
Sawfish developers?

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Sat, 9 Jan 1904 21:10:48 +0100

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Fri, 12 Jan 2001 08:58:07 -0500

> Do you see any chance to get some information from the KDE or

I'll do it, but it looks like the problem wasn't solved.
Its KDE bug report 13878.

I was trying to figure out how to contact the Java folks.
Assuming they would answer, they would be certain to know
the answer.

I've been looking thru the mwm code, and I don't see anything
special about the 10x10 window, or anything else odd going on
during startup or shutdown.

The 10x10 window is called a workspace window, and seems to
contain a flag indicating stardard startup or custom startup.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 12 Jan 2001 23:28:39 +0100

> Instead, Java seems to be hardwired into dtwm.  If it doesn't see

Ah, I can vaguely remember some discussion about this topic, but I
do not remember where.  I believe the Java stuff simply detects
CDE by looking for this particular window and changes its
behaviour to be CDE compliant then.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Fri, 12 Jan 2001 19:30:33 -0500

> behaviour to be CDE compliant then.

Well, I thought so, then I didn't think so, then you made me think
so again, and now I really think so.  :)

I first tested my Java program to make sure it has the same problem
under Exceed.  (I'm at home.)

The Java program works under Exceed.

So  I looked for the 10x10  window, and sure enough  it  was there.  I
wasn't fooling around with dtwm  or mwm, so  Exceed must put it there.
Seems like everyone else is in on this but us.

So then I hacked up fvwm to create its own 10x10 window.  (Now I have
2 of them.)

Then I ran the Java test program...any guesses?

$HOME/src> java Test
SIGBUS    10*  bus error
    si_signo [10]: SIGBUS    10*  bus error

and it hangs until I hit control C.

I almost feel like driving into work just to verify that this really
is the fix, but it looks almost certain that the solution is at hand.

I don't get it, this whole thing seems so bogus that my mind keeps
rejecting it.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 13 Jan 2001 16:00:30 +0100

> I don't get it, this whole thing seems so bogus that my mind keeps

That's the way sowftware is written in the sowtware industry.
Ugly but true.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report From [email-masked]  Sun Jan 14 08:07:39 2001
Date: Sun, 14 Jan 2001 08:07:33 -0600 (CST)
From: CVS <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: CVS olicha: * Send TaskBar window in the case of a click on the start button
Sender: [email-masked]

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	olicha	01/01/14 08:07:33

Modified files:
	modules        : ChangeLog 
	modules/FvwmTaskBar: FvwmTaskBar.c 

Log message:
* Send TaskBar window in the case of a click on the start button

---

From: Dan Espen <[email-masked]>
Date: Mon, 15 Jan 2001 16:11:20 -0500

> > Seems like everyone else is in on this but us.

I can make my sample Java program work by going into fvwm.c, function
SetMWM_info() and making it set the property that it normally only
sets if the "modality is evil" flag is set.

Of course, nothing is that simple.  When I do that, my real Java app
refuses to run.  It just hangs.  I think something is not being
set correctly.

The function SetMWM_info() was added during 2.0.24.  Thats before
Sept 95 when Chuck took over.  We don't appear to have any mail
archives from before 9/95.

I don't see anything in the ICCCM that describes this, and searches
on the Open Group pages haven't turned anything up.  I sure would
like to see some documentation that describes this.

I can try to sync up fvwm to mwm or try to find equivalent logic
in some other window manager, but I'd really like to know what
I'm doing.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 16 Jan 2001 11:28:41 +0100

On Mon, Jan 15, 2001 at 04:11:20PM -0500, Dan Espen wrote:
> > > > * Some placement code cleanup, manpage corrections and logic fixes.
> > > > * Restorde old active icon handling.
> > > 
> > > I don't think you went far enough back, the XEmacs live icon
> > > doesn't work.
> > 
> > Only with NoIconOverride.
> 
> Just like last time, thats not compatible with existing configurations.
> There is no automatic way change existing config files either.
> 
> For me, I adjusted my config file to handle the window that causes
> me a problem and I can probably do the same thing for the other users
> here.
> 
> Its up to you whether you do any further adjustments.
> I can explain again in more detail what I do and whats changed if you
> request it.

Yes, please describe again in detail the exact problem with the
current code and the code I backed out.  I'm not sure I'm
thinking in the right direction.

> I ended up setting the above style on just the window that
> gave me a problem.

I don't hink reverting back to the old code is an option.  It was
simply too inconsistent and confusing.  Unfortunately I have no
idea how to properly detect live icons.

Another attempt.  With my latest commit, the icon pixmap hint will
be ignored if all of the following conditions are met:

 1) The application did not supply an icon hint before the first
    MapRequest.
 2) NoActiveIconOverride is used.
 3) The application provides an icon hint for the first time and
    it is an icon pixmap hint.
 
With this code you should hopefully be able to revert back to
NoActiveIconOverride.

BTW, I just see you used

  Style * NoIconOverride
  Style xmh icon foo.xpm

And got the xemacs builtin icon for the xmh frame.  Of course this
is correct.  If you specify that fvwm supplied icons are never
used if the application provides one, you should not wonder that
your request is honoured.  The logic was badly broken before and
making icons work properly was more of a trial and error process.
With the new patch you should not have to use NoIconOverride
anyway.

Bye

Dominik ^_^  ^_^

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Jan 2001 11:06:41 -0500

> With the new patch you should not have to use NoIconOverride

Hmm, I still can't get back to what I had before with simple global
settings.

I'll try to describe everything I do.

In my .emacs I have:

(defun my-mail ()
  "Setup emacs for reading mail."
  (interactive)
  (select-frame (make-frame '((name . "xmh"))))
  (setq frame-icon-title-format "Mail")
  (iconify-frame)
  (mh-rmail))

(require 'live-icon)		; Icon looks like screen
(setq live-icon-max-height 48)	; Control size, my local mod
(setq live-icon-max-width 48)))	; 48x48 is same size as default icon

I normally start XEmacs like this:

xemacs -f my-mail

My original settings in my .fvwm2rc were like this:

Style "*"           Icon unknown1.xpm
Style "*macs*" 	  NoTitle,NoIconTitle
Style "xmh"	    Icon mail2.xpm

My XEmacs frames get these names:

Main frame:
  Name: emacs: file name
  Class: Emacs
  Resource: emacs

Mail frame:
  Name: xmh: +inbox
  Class: Emacs
  Resource: xmh

The original result was the "mail2.xpm" icon on the Mail frame
and the other (main) frame first showed unknown1.xpm, then changed to
the XEmacs builtin icon.  When  I deiconified the XEmacs main
frame, and reiconified it, it changed to a live icon and from then
on, showed the live icon.

With the latest changes, and my
original .fvwm2rc, the "xmh" icon is OK, but the live-icon never
appears.  The main  frame gets the  unknown1.xpm  icon and  stays that
way.  If I do a recapture, the live icon appears.

If I then add:

Style * NoIconOverride

The xmh frame gets the XEmacs built in icon and the main frame gets
unknown1.xpm.  When I deiconify/iconify I get the live icon.

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Jan 2001 11:29:03 -0500

I just noticed, with the current CVS I also see the gray icon
on the live icon.  This is a symptom that I previously reported.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 00:16:49 +0100

> (setq live-icon-max-width 48)))	; 48x48 is same size as default icon
                              ^^^

And this works? I had to remove two of the closing parentheses.

> way.  If I do a recapture, the live icon appears.

At least I now see exactly the behaviour you describe so I should
be able to fix it.

> unknown1.xpm.  When I deiconify/iconify I get the live icon.

Gee, when the xmh window starts up iconic, I first see the
mail2.xpm icon for a moment, then the icon built into xemacs and
then the live icon truncated to 48x48 pixels at the position where
the icon should show up if it had not been truncated :-/  The
live icon for the normal xemacs frame is not truncated at all, but
this seems to be a bug in the live-icons package.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Jan 2001 19:06:19 -0500

> And this works? I had to remove two of the closing parentheses.

Sorry.  Of course it  works.  I clipped  the leading conditional logic
but   forgot  about the  trailing  parens.  Its   in conditional logic
because it won't work under regular emacs or on Windows.

> At least I now see exactly the behaviour you describe so I should

Great!  If you run it under 2.4.x you will see how it used to work.

> this seems to be a bug in the live-icons package.

The live-icon package I posted should contain:

(defconst live-icon-frame "emacs"
  "Name of frame to use live icon.
Perhaps this should be a list, for now its just the name of the frame
that live-icon should generate an icon for.")

That should be sufficient to restrict the live-icon to the main frame
and not apply it to the mail frame.
In all cases the live-icon should only be 48x48 provided you are using
the live-icon package I posted.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 01:29:44 +0100

> unknown1.xpm.  When I deiconify/iconify I get the live icon.

With my latest commit I hopefully got it straight.  With

  style * noactiveiconoverride, icon unknown1.xpm

I get this:

  $ xemacs -iconic

starts out with the unknown icon and changes to the live icon when
deiconified and then iconified.

  $ xemacs

gets the live icon when iconified.

  $ xemacs -f my-mail

The xmh frame starts out (iconic) with the unknown1.xpm icon but
switches to the live icon after a moment.

With the additional style

  style xmh Icon mail2.xpm

Everything works exactly the same except that mail2.xpm replaces
unknown1.xpm everywhere.  I think that is the proper behaviour.
To get the icon from the config file for the xmh frame you have
to specify

  style xmh iconoverride

as I would expect.

The new algorithm works like this:

  IconOverride

    Always prefer fvwm provided icons.

  NoIconOverride

    Always prefer application provided icons.

  NoActiveIconOverride

    a) If an icon window hint was supplied, use it.
    b) If The application supplied an icon pixmap hint when it was
       mapped, ignore the hint and use the fvwm provided icons. If
       later a new pixmap hint is supplied, consider it an active
       icon and use the hint.
    c) If the application did not supply an icon hint when it was
       mapped and the application later sets an icon pixmap hint,
       ignore the hint as in b.  If it later changes the pixmap
       hint again, consider it an active icon and use the hint.

Is that understandable?  I can think of one situation where this
logic fails:

  - The application uses live icons implemented with a pixmap like
    xemacs and does not supply any hint at startup.
  - Later the application provides a pixmap hint exactly once
    pointing to the live icon.
  - The application is then iconified but never sent a new pixmap
    hint.

In this case the pixmap hint will not be used.  I think this is
only a minor inconvenience because the problem will evaporate as
soon the live icon changes for the first time.  It may be a
problem for mail clients that do not change the pixmap hint for a
long time, but then you can still use NoIconOverride.

Comments?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Jan 2001 19:55:50 -0500

> With my latest commit I hopefully got it straight.  With

I'll read the rest of your mail later.

I just gave it a try without changing anything in my config.

It works just like it did originally, except I have to deiconify/iconify
twice before I see the live-icon for the first time.

I'll read the rest of your mail when I get a chance to try to understand
the options.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 11:28:59 +0100

> twice before I see the live-icon for the first time.

Well, that's exactly the limitation I wrote about in my previous
mail.  This will only happen if you deiconify+iconify the frame
without changing anything inside it.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jan 2001 08:45:04 -0500

Dominik Vogt <[email-masked]> writes:
> This will only happen if you deiconify+iconify the frame

This part doesn't seem to be true for me.  I've tried visiting a directory
and changing the frame size.  Its still takes 2 cycles.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 14:57:40 +0100

> and changing the frame size.  Its still takes 2 cycles.

What output do you see on the console (in relation to the actions
you take).

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jan 2001 09:06:49 -0500

> What output do you see on the console (in relation to the actions

Heres the output, my comments are indented.

si: using default 'shell'
ciw: hint order: iwh xpm bmp iph 'shell'
ciw: iwh not used 'shell'
ciw: xpm used 'shell'
si: using style 'shell'
ciw: hint order: iwh xpm bmp iph 'shell'
ciw: iwh not used 'shell'
ciw: xpm used 'shell'
hpn: iph changed (1) 'shell'
icon hint count++ (1) 'shell'
hpn: first iph ignored 'shell'

  First 2 icons created, mail2 and unknown1
  Main Frame deiconified.
  Main Frame resized and /tmp visited.

ciw: hint order: iwh xpm bmp iph 'emacs: tmp'
ciw: iwh not used 'emacs: tmp'
ciw: xpm used 'emacs: tmp'
hpn: iph changed (1) 'emacs: tmp'
icon hint count++ (1) 'emacs: tmp'
hpn: first iph ignored 'emacs: tmp'

  Iconified main frame (still unknown1)
  Main frame deiconifed 2nd time.

ciw: hint order: iwh xpm bmp iph 'emacs: tmp'
ciw: iwh not used 'emacs: tmp'
ciw: xpm used 'emacs: tmp'
hpn: iph changed (1) 'emacs: tmp'
icon hint count++ (2) 'emacs: tmp'
hpn: using further iph 'emacs: tmp'
hpn: icon changed 'emacs: tmp'
hpn: applying new icon 'emacs: tmp'
ciw: hint order: iwh iph xpm bmp 'emacs: tmp'
ciw: iwh not used 'emacs: tmp'
ciw: iph used 'emacs: tmp'

  Second deiconify
  Now its live-icon.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 16:07:07 +0100

> ciw: iph used 'emacs: tmp'

I don't understand this.  Xemacs doesn't seem to provide it's
default icon as it does for me but seems to switch directly to
the live icon.  Shouldn't it use the built in icon before the
live icon package is activated?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jan 2001 11:28:12 -0500

I also use "dtcm".
dtcm has its own icon that shows the date.

With the latest changes, dtcm is showing unknown1.xpm as its icon.
I don't have anything special in my .fvwm2rc for dtcm.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 17:52:21 +0100

> I don't have anything special in my .fvwm2rc for dtcm.

Hm.  Perhaps the order in which icons are evaluated should be
changed for NoActiveIconOverride:

Currently:

 1) Icon window hint
 2) Icon pixmap hint (except first one)
 3) Icon provided by a specific style
 4) Icon provided by "*" style (default) icon
 5) Icon pixmap hint (first one)

New:

 1) Icon window hint
 2) Icon pixmap hint (except first one)
 3) Icon provided by a specific style
 4) Icon pixmap hint (first one)
 5) Icon provided by "*" style (default) icon

Try it when it's commited.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jan 2001 14:56:32 -0500

> Try it when it's commited.

I haven't put anything in my config file.

It still gets unknown1.xpm.

A recapture fixes the icon.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 23:28:30 +0100

> A recapture fixes the icon.

What's the bedug output?

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 23:29:49 +0100

> A recapture fixes the icon.

Ah, you have to make sure you don't have a style matching dtcm
that provides an icon (except "*").

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jan 2001 18:58:05 -0500

> > Dominik Vogt <[email-masked]> writes:
...
> > A recapture fixes the icon.

dtwm sets resources as follows:

Name: Calendar: dane@fork
Class: Dtcm
Resource: dtcm

Debug from create "dtcm" iconic:

using 3 labels and 1 icons
using 3 labels and 1 icons
si: using default 'dtcm'
ciw: hint order: iwh iph xpm bmp 'dtcm'
ciw: iwh not used 'dtcm'
ciw: iph not used 'dtcm'
ciw: xpm used 'dtcm'
hpn: iph changed (1) 'dtcm'
icon hint count++ (1) 'dtcm'
hpn: first iph ignored 'dtcm'

Issue "recapture":

icon hint count++ (1) 'Calendar : dane@fork'
si: using iph 'Calendar : dane@fork'
ciw: hint order: iwh xpm bmp iph 'Calendar : dane@fork'
ciw: iwh not used 'Calendar : dane@fork'
ciw: xpm not used 'Calendar : dane@fork'
ciw: bmp not used 'Calendar : dane@fork'
ciw: iph used 'Calendar : dane@fork'
si: using style 'fork -- /u/tools/dane/fvwm/version-2_3_28'
ciw: hint order: iwh xpm bmp iph 'fork -- /u/tools/dane/fvwm/version-2_3_28'
ciw: iwh not used 'fork -- /u/tools/dane/fvwm/version-2_3_28'
ciw: xpm used 'fork -- /u/tools/dane/fvwm/version-2_3_28'
si: using style 'SSxbiff'
si: using default 'dclock'
icon hint count++ (1) 'xmh: +inbox'
si: iph ignored 'xmh: +inbox'
icon hint count++ (1) 'emacs: nohup.out'
si: using iph 'emacs: nohup.out'
si: using style 'FvwmForm-Talk'
hpn: iph changed (1) 'emacs: nohup.out'
icon hint count++ (2) 'emacs: nohup.out'
hpn: using further iph 'emacs: nohup.out'
hpn: icon changed 'emacs: nohup.out'
hpn: iph changed (1) 'emacs: nohup.out'
icon hint count++ (2) 'emacs: nohup.out'
hpn: using further iph 'emacs: nohup.out'
hpn: icon changed 'emacs: nohup.out'

I don't have any style commands that match dtcm other than "*".

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 18 Jan 2001 11:28:53 +0100

> I don't have any style commands that match dtcm other than "*".

*Sigh*

Is it an option to remove icon support completely?

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 18 Jan 2001 11:51:23 +0100

...

I forgot to adapt events.c to the changes in icons.c.  Try again.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 18 Jan 2001 07:06:17 -0500

> I forgot to adapt events.c to the changes in icons.c.  Try again.

dtcm works and the live icon is now appearing after the first
deiconify/iconify.  Sehr gut.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 18 Jan 2001 13:18:08 +0100

> deiconify/iconify.  Sehr gut.

Phew!  Finally.

Bye

Dominik ^_^  ^_^