Subject: [Fwd: Interesting Bug report on Sun Java Site]

From: "Robert H. Ford II" <[email-masked]>
Date: Wed, 08 Mar 2000 11:53:08 -0600

I am forwarding this bug report to the workers list (it is long I am sorry) in
hopes that maybe something can be done on FVWMs side to fix this very annoying
problem.

Bob Ford II
-- 
    _/_/_/     _/  _/   _/_/_/_/   _/_/_/_/_/_/ Robert H. Ford II
   _/   _/    _/  _/   _/           _/    _/    Lucent Technologies
  _/_/_/     _/_/_/   _/_/_/       _/    _/     Bell Labs Innovations
 _/   _/    _/  _/   _/           _/    _/      Naperville IL, 60566-7045
_/    _/   _/  _/   _/         _/_/_/_/_/_/     mailto:[email-masked]
                                                Voice: (630) 713-4957
__________________________________________________
|  M R spiders!                    |      |   |  |
|  M N O spiders!                  |      |   |  |
|  O S A R - C D E D B D I's?      |      |   |  |
|  Y I B, M R spiders...           |      |   *  |
|                                  *      |      |
|                                         *      |
--------------------------------------------------

Subject: Interesting Bug report on Sun Java Site
From: Dave Trollope <[email-masked]>
To: Robert Ford <[email-masked]>
Date: Wed, 08 Mar 2000 11:33:22 -0600

Hi,
Here is a report on the Sun Java site about poor window positioning in fvwm. Note wish (Tcl/Tk) has the same problem.
http://developer.java.sun.com/developer/bugParade/bugs/4147997.html
Dave (description follows)
Bug ID: 4147997
Using the fvwm window manager, in JDK 1.1.6
and 1.2Beta3 it appears that the border dimensions
are ignored when determining window locations.
As a result, placing a frame at 0,0 places the
window contained by the frame at 0,0 and leaves
the title border above the screen and inaccessable.
This bug is being submitted on behalf of a
large Sun customer by a Sun Systems Engineer.
import java.awt.*;
import java.awt.event.*;
class Main extends Frame {
// The contructor creates a frame with a window size that gives
// the desired interior size.
Main() {
super("Frame Example");
// Calling addNotify() creates the peers; otherwise insets()
// does not return the right values.
addNotify();
Insets insets = getInsets();
setSize(insets.left + insets.right + 150,
insets.top + insets.bottom + 150);
// Add listener
this.addMouseListener(new MouseEventHandler());
}
class MouseEventHandler extends MouseAdapter {
public void mousePressed(MouseEvent evt) {
// x, y are in interior coordinates
// must be translated to screen coordinates.
Rectangle bounds = getBounds();
//System.out.println("evt " + evt.getX() + " " + evt.getY());
//System.out.println("bnd " + bounds.x + " " + bounds.y);
int x = evt.getX() + bounds.x;
int y = evt.getY() + bounds.y;
// Set location of new frame
Main m = new Main();
//m.setLocation(X, Y);
m.setLocation(0,0);
m.show();
}
}
static public void main(String[] args) {
(new Main()).show();
}
}

xxxxx@xxxxx
Subject: Re: 1.1.6 Java Bug
Mime-Version: 1.0
AIM = AOL Instant Messenger.  The Java version can be downloaded from
http://www.xxxxx.com/aim/downloadjava.html  If you don't have a
screen name yet, you need to start at http://www.xxxxx.com/aim/ and get
one first.  You are welcome to "im" me at screen name "AndyWick".
It would be great if we could get JavaSoft and/or SUN people using
AIM, especially since it *IS* now included on some *SUN* CD. :-)
Fvwm is a window manager, similiar to mwm, but it supports virtual screens
and lots more features.  It is a very common window manager used
by programmers that I work with.  You can get it at
ftp://ftp.hpc.uh.edu/pub/fvwm/version-2  I am using version 2.0.46
The bug itself is caused by the borders of the frames being ignored.
So this means the inside of the frame is considered 0,0 instead of
including the border.  Say the width of the frame border is 10 pixels.
If I say place a frame at (0, 0), in reality the inside of the
frame would be (10,10) because the borders would be (0,0).  In version
1.1.6 and 1.2beta3 they don't coun't the borders, so the borders show
up "offscreen".  ie I say frame.setLocation(0,0) in reality does
setLocation(-10, -10).
Thanks,
Andy
(Review ID: 29458)

Workaround
None.
Evaluation

xxxxx@xxxxx
I was able to reproduce it under jdk1.1.6, 1.1.7 and 1.2fcsN.
Some window managers (fvwm, fvwm2, Afterstep) just work in the way
that they treat requested position as a position to place client
area (shell). This is easy to
see: just run any X application and programmatically place it at
0x0 position (one can use, for example, 'wish') :
#>wish
% wm geometry .
200x200+32+64
% wm geometry . +0+0
After this command under fvwm test window will be placed in such a way that
title bar and left border became unaccessible while under other WM
(such as CDE, OpenLook, twm etc) upper left corner of the frame's
title will be placed at 0x0.
So what user should do is just specify desired frame's location
before showing it and this location should take into account WM
decorations dimensions.

---
>    I agree that one of them is a duplicate. However, before you change the
bug
> status to not-a-bug, could you make some effort to see why both test cases
work
> correctly in JDK1.1.4 but not in JDK1.1.5 or later?
Actually, as far as I can judge, it never worked correctly in
fvwm-line (fvwm's, AfterStep, ..) window managers. Here under
'correctly' I mean the ability to place frame at specified coordinates.
In jdk's earlier than 1.1.6 (including 1.1.5FCS) it was working in
the way that (fvwm-like) window managers were just placing frames to
the location they want 'ignoring' setLocation calls. So there were no
way to position frame to the desired location. That's why frames were
never placed outside the screen - WM did 'the right thing'.
After major code rewriting in awt_Frame.c (deltas 1.84, 1.91
Fixes: 4028130, 4017504, 4071086, 1231233, 4077874, 4040662,
4033151, 4041442, 4080504, ??????? (FrameMoveBug)) by
pauly frame behavior has been changed and now awt is trying to
place frames to the location asked (using setLocation),
so these new problems were introduced (since jdk1.1.6)
Note that under OLWM, CDE, twm, WindowMaker and some other WMs all still
work fine.

There are several reasons why we couldn't (and, moreover, shouldn't)
fix this properly. I'll try to describe them:
- there is no certain way to know from the WM what its
policy in placing frames decorations is
- there is no certain way even to determine which WM we're running
under
So any code we'll could probably invent to do this will be uncommon
and there will be always possibility that new WM will appear which
our hacks will not be able to handle (good exampe if this point
is frame's current implementation).
- actually, we're trying to override WM's behavior, which is not
right since WM represents user's preferences. If WM doesn't
satisfy user needs he'd move to other one it or do some workaround
So it was decided to just keep this bug as a record in bugtraq.
It probably will be fixed in 1.2 during the major awt_Frame
code rewritting.

--
Dave Trollope
HTML: mailto:[email-masked]
WWW: http://ns.uk.lucent.com/~dtrollop/
Tel: +1 630 713 9110 Fax: +1 630 979 1390
WWW: http://www.geocities.com/SiliconValley/7499/

---

From: Jason L Tibbitts III <[email-masked]>
Date: 08 Mar 2000 13:27:11 -0600

>>>>> "RHF" == Robert H Ford <[email-masked]> writes:

RHF> I am forwarding this bug report to the workers list (it is long I am
RHF> sorry) in hopes that maybe something can be done on FVWMs side to fix
RHF> this very annoying problem.

The only reason it's long is because it's 90% "&nbsp".  I wonder what it
looks like in English.

 - J<
--
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: "Paul D. Smith" <[email-masked]>
Date: 08 Mar 2000 14:31:56 -0500

It looks like this hasn't been tried with any FVWM version except
2.0.46, which is ridiculously old.  Anyway, that's the only fvwm version
I can find in the bug report (would be nice if you could make some
effort to reformat it; every line in the message is indented 50+ spaces!)

Can you test/reproduce this with 2.2.4 or one of the latest 2.3.x betas?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Wed, 08 Mar 2000 14:34:59 -0500

> The only reason it's long is because it's 90% "&nbsp".  I wonder what it

Looks like:

Hi, 

import java.awt.*; 
import java.awt.event.*; 

        // Add listener 

    } 

xxxxx@xxxxx 

Thanks, 
Andy 
(Review ID: 29458) 

None. 

xxxxx@xxxxx 

--- 
bug 
work 

  

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: "Robert H. Ford II" <[email-masked]>
Date: Wed, 08 Mar 2000 14:20:24 -0600

> Can you test/reproduce this with 2.2.4 or one of the latest 2.3.x betas?

Sorry for the garbage that I sent to the list and thank you Dan for
re-formatting it for me.

I am running the one of the latest 2.3.x beta version:

ihgp74x123: fvwm2 -version
[FVWM][main]:  Fvwm Version 2.3.15 compiled on Feb 25 2000 at 13:04:29
[FVWM][main]:  with support for:  ReadLine RPlay Stroke XPM IMLIB Gnome Session

and the problem is still there.

I tried the "wish" example provided in the report and it does demonstrate the
problem.

---

From: Neil Bird <[email-masked]>
Date: Thu, 09 Mar 2000 09:17:25 +0000

Neil Bird wrote:
>   Nope, I've utterly failed to find the discussion I had about it,

  Check out "Window Position Change?" thread of Jan 2000 in the archives.
I sent a small demo. C prog. that illustrates the 'problem'.

  The thread died without a resolution.

-- 
=====================- http://www.racaldefence.com/ -===================
  Neil Bird                      |
                                 |            This .signature is
    mailto:[email-masked]  |          certified Y2K compliant
--
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: Tim Phipps <[email-masked]>
Date: Thu, 09 Mar 2000 11:27:18 +0000

I think fvwm is doing the corect thing at the moment. When a client
askes to be moved to a certain location fvwm does exactly that even
though it means that some of the border may go off screen. Making fvwm
do anything else would require it to guess what the client intended.
Some clients may want a full screen window that really is full screen,
others may want the size and position adjusted so that the border
remains visible. In your case this is complicated further by the
toolkit. I think Sun are right in not attempting to second guess what
the window manager will do with a SetLocation, after all they can't tell
which window manager is running.

All is not doom and gloom though, we could implement a new style that
would make the behaviour of fvwm controllable by the user. The default
would be the current way.

Any takers?

Cheers,
Tim.

---

From: Neil Bird <[email-masked]>
Date: Thu, 09 Mar 2000 12:31:29 +0000

> do anything else would require it to guess what the client intended.

  I think that /a/ problem is that CreateWindow & MoveResize are
inconsistent: if one creates a window at 100x100+50+50, then moves it to
same, it does actually move!

  This 'bodge' is probably because almost *all* apps. expect that opening
a new window at (say) (0,0) puts it's border at top-left, not off screen.
But then, of course, moving the window puts it elsewhere.

> would be the current way.

  Sounds like a plan.

  Out of curiosity, what are the other WMs strategies in this area? What
does ICCCM (?) recommend?

---

From: Dan Espen <[email-masked]>
Date: Thu, 09 Mar 2000 16:38:12 -0500

> Subject: Re: 1.1.6 Java Bug 

I'd like to at least look at the problem.  When I run the supplied code,
the window places itself in the first open space it finds.

When I make 0/0 available and run again, the frame is at 1/1.
That doesn't seem to match up with the problem report.

I'm running jdk 1.1.6.

Is placement policy an issue?  I use:

Style "*" ActivePlacement, SmartPlacement

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Mar 2000 07:50:31 +0100

> hopes that maybe something can be done on FVWMs side to fix this very annoying

Sorry if I don't refer to the previous answers directly
(too many mails to answer after my vacation).  I won't
reply to this bug report directly, if somebody is interested
in helping the Java folks, here is the reason:

 - When windows are *created*, fvwm moves them according to
   their gravity so that the complete window with borders is
   at the right position.
 - When existing windows are moved by the application itself,
   fvwm assumes the application is using client window
   coordinates.  I think this is ICCCM compliant.

The right way to prevent this problem is to create the window
at the correct location with the correct size hints set.
Moving the window afterwards or changing its size hints is
almost guaranteed to cause problems with one window manager
or the other.  The ICCCM is not very clear about the right
way to handle this situation.  Since Java windows shouldn't
need to change their position at all it should be simple to
fix this by creating the window at the proper place.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
The adjuration to be "normal" seems shockingly repellent to me; I see neither
hope nor comfort in sinking to that low level.  I think it is ignorance that
makes people think of abnormality only with horror and allows them to remain
undismayed at the proximity of "normal" to average and mediocre.  For surely
anyone who achieves anything is, essentially, abnormal.
                -- Dr. Karl Menninger, "The Human Mind", 1930

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Mar 2000 07:59:41 +0100

> would be the current way.

Granted, a style option could solve this, but I wouldn't want
to encourage such a large class of applications like Java applets
to use a protocol that most window managers won't understand.
I'm quite sure that most free window managers do it the fvwm way.

Bye

Dominik ^_^

---

From: [email-masked]
Date: Thu, 16 Mar 2000 08:30:26 -0500 (EST)

> I'm quite sure that most free window managers do it the fvwm way.

I don't know if this is the correct attitude.  This isn't an academic "this
might happen" but a realistic "this IS happening."

Java programmers do not have any choices about this behavior when writing
programs.  The problem is in the class libraries.  I don't see how making
arrangements for them to work properly is "encoraging such a large class of
applications."  (A Java applet is NOT the same thing as a Java application, by
the way.)

And you wouldn't just be penalizing users running Java programs, but those
that potentially run other types of programs (the tcl/tk wish shell shows the
same behavior).

I don't think that users are going to care if this is a strange protocol for
the window manager to understand, or who has got it correct. They notice that
their program seems to work right under Motif/CDE/OpenLook and it doesn't seem
to work right under fvwm2 (and possibly some other window managers).

I would actually understand an answer like "we are in feature freeze, so we
might consider it for a future release, but not now."

-- 
Larry Gensch                                          [email-masked]

                  "May I have ten thousand marbles, please?"

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 25 Mar 2000 11:22:43 +0100

> to work right under fvwm2 (and possibly some other window managers).

And what would an option help here?  They would still see that it
works under Motif/CDE/OpenLook but not with fvwm.  The difference
would be only that the few users that studied the man page carefully
may be able to get it working right.  I'd really prefer if this
java stuff would stick to the way virtually all other applications
work (i.e. they fix java).

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 25 Mar 2000 08:53:36 -0500

> work (i.e. they fix java).

I'm not advocating any solution.  Heres an an excerpt from the mwm man
page:

     positionIsFrame (class PositionIsFrame)
             This resource indicates how client  window  position
             information  (from  the WM_NORMAL_HINTS property and
             from configuration requests) is to  be  interpreted.
             If  the  resource  value is True, the information is
             interpreted as the position of the MWM client window
             frame.   If the value is False, it is interpreted as
             being the position of the client area of the window.
             The default value of this resource is True.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 27 Mar 2000 10:59:21 +0100

> work (i.e. they fix java).

The chances of Java changing to fix this is virtually zero. An option
might be useful if the windows in question have a recognizeable class or
resource, in that case a `Style Java* PositionMeansBorder' might be a
useful default.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 29 Mar 2000 11:45:02 +0200

> resource, in that case a `Style Java* PositionMeansBorder' might be a

If you say so I trust you, Tim.  I had the impression they were eager
to fix this.  On the other hand I'm probably too naive (I still believe
that people are trying to write good softwars :-) ).  My main concern
about a new option is/was that it would be unwieldy.  Is it possible to
recognise java windows reliably? (class or resource?)

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Bob Woodside <[email-masked]>
Date: Wed, 29 Mar 2000 10:25:08 -0500

Dominik Vogt wrote:
> that people are trying to write good softwars :-) ).

	Actually, I believe they are trying to. But then maybe I'm too naive.

>                                                       My main concern

	Under 1.2, at least (um, pardon me, "Java 2"), it looks like they all
have a class of "VendorShell" (not terribly useful), and a resource of
"AWT*" ("AWTapp", "AWTdialog", etc.). I just checked this on a variety
of Java apps, both Swing and non-Swing. I suspect that the same was true
under 1.1.

Cheers,
Bob