I still wasn't able to set the layer. The output from xprop indicated that all the java windows were in the 4th layer. I took at look at the JDK 1.6 source for Solaris. Java's two layers, "normal" and "always on top", correspond to layers 4 and 6 respectively. I suppose I'll use the "alwaysOnTop" property when I can upgrade my compiler to 1.5 (or 1.6). Thanks.
-----Original Message----- From: Thomas Adam [mailto:[EMAIL PROTECTED] Sent: Sunday, February 18, 2007 4:14 AM To: McClellan, Kyle C; [email protected] Subject: Re: FVWM: Java windows ignore layering On Sat, Feb 17, 2007 at 11:56:03AM -0800, McClellan, Kyle C wrote: > I am running a mixed language application using fvwm2 (v. 2.5.10) and > the 1.5 JVM. It appears that all the java windows (JWindow and > JFrame) are being placed in layer 4 (the default layer) regardless of > my attempts to set their layer in the fvwm file. For instance, No surprise there. That's just Java being Java. I've just spent the last half an hour seeing if I could debug this to determine why. I used LimeWire as a test-bed. In stack.c (line 2189 in set_layer()): fprintf(stderr, "For window: %s (class: %s | res: %s), layer is: %d\n", t->name.name, t->class.res_class, t->class.res_name, t->layer ); And added similar debugging in get_layer(). In the case of LimeWire, it pops up a transient window first (the layer of which is inherited from the parent application) -- which is Layer 10. That matches from a Style line of: Style com-limegroup-gnutella-gui-Main CirculateHit, Layer 10 Which is the Class of the two windows in question (the other window being the main application). However, as soon as the transient window is closed, the default layer of the main application is reset. Indeed: Next (com-limegroup-gnutella-gui-Main) Layer 0 10 Fixes this annoyance. Other Java applications I tried this with that don't have annoying transient windows that start up initially seem to work just fine, although anything Java sucks, given that Sun hates other window managers. > Style "com.SomeJavaWindow" Layer 6 > Style "com.SomeJavaFrame" Layer 6 > > don't appear to have any effect. Am I doing something wrong, and is > there an alternate solution? Thanks. You don't appear to be doing anything wrong. What I would say to you is check that the Java windows you're trying to reference really do have the Name/Class/Resource you expect them to as soon as they're mapped. So often is the case with Java applications that once the toplevel window is mapped that various hints are then set, which is no good for post-matching of style conditions on window as far as FVWM is concerned. Hence you can use something like this: DesatroyModuleConfig a:* *a: add_window SomeFunction Module FvwmEvent a DestroyFunc SomeFunction AddToFunc SomeFunction + I ThisWindow (Xmessage) Break + I Exec exec xmessage "name: $[w.name] : class: $[w.class] : res: $[w.resource]" Comparing what xmessage tells you there, with the output from xprop might prove useful. Look also for other oddities such as an initial space in either the WM_CLASS atom description for the window -- that's a classic as well. -- Thomas Adam -- "Wanting to feel; to know what is real. Living is a lie." -- Purpoise Song, by The Monkees.
