Subject: FVWM: Windows for java apps Don't Obey Placement

From: "Reuben D. Budiardja" <[email-masked]>
Date: Thu, 1 Aug 2002 09:19:49 -0400

Hi,
I have a rather annoying problem when running java apps. The windows that are 
produced by java apps don't obey my manual placement. For some of the apps, 
it always goes right to the top left corner of my virtual window, hiding even 
the handles and menu in the handles, make me cannot grab it to move it.
For some windows app, it just tends to go more to the top left. 

I only see this happens with java programs. I am not sure what causes this. I 
am using FVWM 2.4.8 compiled from source on Redhat Linux 7.3. Here is part of 
my rc files that specify window placement. Any help would greatly 
appreciated. Thanks in advance.

########################      WINDOW PLACEMENT     #######################
# RandomPlacement prevents user interaction while placing windows:
# Style "*" RandomPlacement

# Manual Placement asks user interaction while placing windows:
Style "*" ManualPlacement

# SmartPlacement makes new windows pop-up in blank regions of screen
# if possible, or falls back to random or Manual placement.
Style * SmartPlacement
 
# With SmartPlacement, windows will normally place themselves over icons.   
# Uncomment this to change that.
#StubbornPlacement

# NoPPosition instructs fvwm to ignore the PPosition field in window 
# geometry hints. Emacs annoyingly sets PPosition to (0,0)!
Style "*" NoPPosition 

Reuben D. Budiardja
--
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: Dan Espen <[email-masked]>
Date: Thu, 01 Aug 2002 11:56:06 -0400

> For some windows app, it just tends to go more to the top left. 

This is a Java problem.

Java looks for a few different window managers, and if it doesn't
find them, it misbehaves.  Fvwm is not on the list of window managers
that it looks for.

We've contacted the Java developers, and its my understanding that
Java 1.4 should start working better.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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: "Reuben D. Budiardja" <[email-masked]>
Date: Thu, 1 Aug 2002 12:17:05 -0400

I am using Java 1.4 SDK, and developing application using Java 1.4. I guess 
they didn't fix it correctly yet.

Rdb
On Thursday 01 August 2002 11:56 am, Dan Espen wrote:
> > I have a rather annoying problem when running java apps. The windows that
> > are produced by java apps don't obey my manual placement.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 1 Aug 2002 18:21:03 +0200

> appreciated. Thanks in advance.

[snip]

> # Uncomment this to change that.

Note:  this style was removed in the transition from fvwm-1.x to
fvwm-2.x.

> # geometry hints. Emacs annoyingly sets PPosition to (0,0)!

NoPPosition only prevents that programs can set their initial
size using the PPos (program specified position) hint.  They can
still enforce their position with the user specified position
hints (which fvwm is forbidden to ignore by the spec), or change
their position afterwards.  In 2.4.x, there is no way to prevent
thisi.  But because of the ever growing number of applications
whose developers think they know better where the windows should
appear than the user, I've implemented a few new styles to control
that behaviour in 2.5.x:

  Style * NoUSPosition
  Style * FixedPSize

You may want to apply these styles only to the misbehaving
windows, not all windows.  The latest release is fvwm-2.5.2, but
it is *unstable* and may crash at any time, when the wrong
features are used (there are known crashes with dynamic menus and
the MenuStyle command not using the default style).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe

---

From: Dan Espen <[email-masked]>
Date: Thu, 01 Aug 2002 13:36:03 -0400

> they didn't fix it correctly yet.

This is bugid 4401846 on the Java bug database.

Make sure you vote for this to get fixed.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 1 Aug 2002 13:53:27 -0400

On Thu, 1 Aug 2002 12:17:05 -0400

> they didn't fix it correctly yet.

<RANT WHINE="max" ASPECT="dour">
	$%#@#!!!  They said, or at least implied, that they were going to improve this
situation in 1.4.
</RANT>

	We used to have some luck using an ugly hack that's still in the fvwm code. Try
adding the following to your .fvwm2rc:

BugOpts ModalityIsEvil True

	This sets a property on the root window that causes Java (well, all Motif
programs that use the XmIsMotifWMRunning() function, really) to think that mwm
is running, and it makes some adjustments to its behavior. This may work for
you. We'd certainly like to hear if it still works with the 1.4 jdk. (Don't even
ask about the name of the option - it hasn't performed its original function in
years.)

Cheers,
Bob

---

From: "Reuben D. Budiardja" <[email-masked]>
Date: Thu, 1 Aug 2002 15:22:27 -0400

On Thursday 01 August 2002 01:53 pm, Bob Woodside wrote:
> 	We used to have some luck using an ugly hack that's still in the fvwm
> code. Try adding the following to your .fvwm2rc:
>

I voted for the bug. The solution suggested by Dominik requires the unstable 
version, and I don't think I am ready for that.

The "BugOpts ModalityIsEvil True" hack doesn't work for me. This is probably 
because Java 2 uses Metal (swing) as default instead of motif (??). 

So, I guess I have to bear on this annoying thing for now... <sigh>..
Thanks anyway for all reponds.

Reuben D. B.

> programs that use the XmIsMotifWMRunning() function, really) to think that
> mwm is running, and it makes some adjustments to its behavior. This may
> work for you. We'd certainly like to hear if it still works with the 1.4
> jdk. (Don't even ask about the name of the option - it hasn't performed its
> original function in years.)
>
>
> Cheers,
> Bob

---

From: "Rob 'Feztaa' Park" <[email-masked]>
Date: Thu, 01 Aug 2002 16:27:35 -0600

> version, and I don't think I am ready for that.

I use 2.5.2 on my system, and it runs perfectly well. There are no
random crashes or bugs that I have seen. You might try it, if you want
to ;)

-- 
Rob 'Feztaa' Park
http://members.shaw.ca/feztaa/
--
If a subordinate asks you a pertinent question, look at him as if he had
lost his senses.  When he looks down, paraphrase the question back at him.
--
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: Andy Arbon <[email-masked]>
Date: Thu, 01 Aug 2002 23:24:05 +0100

> version, and I don't think I am ready for that.

While it's true it's unstable by name I've been using it (because it 
contains a feature Dominik kindly implemented to solve a problem I was 
having with two different sized monitors in a dual head set up) for a 
while now and I haven't had a single problem with it.

I don't do anything particularly weird with FVWM, so I'm probably not 
pushing it at all, but it's been rock solid for me.

Now, if I could just stop the NVidia drivers from occasionally locking 
the machine up with X shuts down everything'd be peachy.. ;)

Cheers,

Andy

---

From: Gordon Prieur <[email-masked]>
Date: Fri, 02 Aug 2002 08:56:50 -0700

Hi,

     I just looked at the Java bug report and they experimented with a
fix for Java 1.4 and decided its a fvwm bug. The comment in the bug
evaluation says that fvwm ignores gravity when handling
ConfigureRequests. Perhaps one of the current fvwm developers could
take a look at this and see if this is true and if it fixes the
problem. If its not the problem you might try contacting Sun about
bug # 4401846. Perhaps the 2 sets of developers (fvwm and Java) can
get this resolved together.

Gordon

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 2 Aug 2002 18:36:04 +0200

On Fri, Aug 02, 2002 at 08:56:50AM -0700, Gordon Prieur wrote:
> problem.

That's complete nonsense.  Fvwm is the only window manager I know
of that *does* handle gravity in ConfigureRequest events.

> If its not the problem you might try contacting Sun about

No comment ;-)

> >>are
> >>produced by java apps don't obey my manual placement. For some of the 
> >>apps, it always goes right to the top left corner of my virtual window, 
> >>hiding even

Bye

Dominik ^_^  ^_^

---

From: Gordon Prieur <[email-masked]>
Date: Fri, 02 Aug 2002 09:58:15 -0700

> of that *does* handle gravity in ConfigureRequest events.

It may be complete nonsense. However, unless you (or another fvwm
developer) get in touch with the Java group this problem is unlikely
to ever get fixed.

I'm not trying to say who's problem it is. I certainly don't know.
But we have the classical case of 2 different groups each saying
the other group has the bug. It will never get fixed unless the
2 groups communicate.

>>get this resolved together.

Well, do you want the problem fixed or not? This problem was serious
enough I stopped using fvwm for several months (I'm back now :-).

Gordon

---

From: Dan Espen <[email-masked]>
Date: Fri, 02 Aug 2002 13:17:41 -0400

> get this resolved together.

Can you tell us where you are getting this information, all I see
is this:

According to the report, it sounds like this test works fine with Sawfish and
dtwm, and has problems only with fvwm and fvwm2.
xxxxx@xxxxx 2001-01-04

See also 4457472.  Commit to fix in Tiger.
xxxxx@xxxxx 2001-05-18

Reproducible on build 1.4.0-beta_refresh-b70.
xxxxx@xxxxx 2001-07-11

Ie., it looks like an open bug.

---

From: Gordon Prieur <[email-masked]>
Date: Fri, 02 Aug 2002 10:55:02 -0700

> Can you tell us where you are getting this information, all I see

I'm a Sun developer so I can look at the corporate bug database rather
than the one you see from developer.java.sun.com. There is a more
recent evaluation from 8/2 which isn't in the version I see from the
java web site.

I'll see if I can get authorization to send the full evaluation to
this list (it shouldn't be hard to get). I doubt its intentionally
not on the external page but suspect the external (ie, viewable from
the java web pages) just isn't as up-to-date as it should be.

> Ie., it looks like an open bug.

Its still open but I doubt if the bug will get serious consideration
again unless somebody can convince the JDK developer their evaluation
is wrong (this is what I'm hoping to get the fvwm developers to do :-)

Gordon

---

From: Bob Woodside <[email-masked]>
Date: Fri, 2 Aug 2002 15:47:41 -0400

On Fri, 02 Aug 2002 10:55:02 -0700
> >>get this resolved together.

	A golden opportunity. Let's grab it!

	This bug report is really a restatement of bug # 4102292, the great-grand-daddy
of these reports (open since Jan 07, 1998, with a long list of public comments
including a Happy Birthday message to the bug). In a nutshell, the problem is
that Java insists on placing windows at 0,0 if the program hasn't specified
placement coordinates. It correctly calculates the offsets for the window
decorations for relatively simple WM's - e.g., twm - and adjusts accordingly. It
calculates them incorrectly for WM's that do double (or more) reparenting of the
top level window.

	There are actually over 40 bug reports (that we can see on the public list,
anyway) over the past 4.5 years (since around jdk 1.1.5) describing what is
substantially the same problem. Some reference other window managers (e.g., the
GNOME and KDE WM's); some describe the symptoms a bit differently, and so on;
but they all boil down to the same misfeature.

	The infuriating thing about the 1.4 release is that we had developed a hack
that worked - setting the property on the root window that made the JVM think
the mwm was running, and it seemed to be happy enough to let mwm decide where to
place the windows without interfering. We've now had to work on other hacks to
try to get around the problem.

	The fundamental question I see in all this is: what earthly purpose is served
by trying to force the top level window positions to 0,0? What would it take to
convince the Sun developers that this is genuinely a Bad Thing?

> the java web pages) just isn't as up-to-date as it should be.

	That would be great, if you can!

> is wrong (this is what I'm hoping to get the fvwm developers to do :-)

	We'll certainly try.

Cheers,
Bob

---

From: Gordon Prieur <[email-masked]>
Date: Fri, 02 Aug 2002 16:08:08 -0700

Hi,

     I just got email from the owner of this bug. He said the public
version of hte bug report will get updated in the next several days
but that he had no problem with my posting it. He also seemed very
willing to work with fvwm developers towards resolution.

     As you can see, it doesn't say much more than I did in my email.
I suggest you add a comment to the bug report giving your email and
who you are. Hopefully, the jdk developer will contact you and you
two can work out a resolution. I can't wait to have my netbeans windows
start at the right location :-)

Gordon

=====================================================================

xxx@xxxxxxxxxxx  2002-08-02

This is an fvwm2 bug, it ignores gravity when handling ConfigureRequest's.

$ wish
% wm geometry .
200x200+0+0
% wm geometry . +1+1

That request to move window to +1+1 will move the window title off-screen.

We have a code to work around this problem that is activated for E!
and IceWM, but I feel this is the wrong thing to do - when the gravity
bug is fixed, the workaround will cause problems.  Since there are
several popular WMs with this bug, perhaphs the workaround shall be
conditionalized on a property or an environment variable.