Subject: Notification: incoming/496

From: [email-masked]
Date: Sun, 24 Oct 1999 23:02:12 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/496

Message summary for PR#496
	From: [email-masked]
	Subject: NoPPosition java/Swing bug
	Date: Sun, 24 Oct 1999 23:02:10 -0500 (CDT)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 27 Oct 1999 18:37:26 +0200

On Sun, Oct 24, 1999 at 11:02:12PM -0500, [email-masked] wrote:
> >From [email-masked]  Sun Oct 24 23:02:11 1999
> Received: from localhost (localhost [127.0.0.1])
> 	by larry.math.uh.edu (8.9.1/8.9.1) with ESMTP id XAA06296
> 	for <[email-masked]>; Sun, 24 Oct 1999 23:02:10 -0500 (CDT)
> Message-Id: <[email-masked]>
> To: [email-masked]
> Full_Name: kris wehner
> Version: 2.2.2
> CVS_Date: 
> OS: Solaris 7
> X_Server: Native
> Submission from: (NULL) (128.174.244.67)
> 
> 
> If you set:
> Style "*" NoPPosition
> Java2/Swing applications have weird rendering problems. A good example is 
> standard dialogs (from JOptionPane) will draw with the OK/Cancel buttons
> partially obscured or not rendered. I've tried a few other window 
> managers (vtwm, dtwm) and have only been able to exhibit the bug with
> fvwm2 with this option set. 

This is something you should report to the developers of the
application you mention.  An application must not require the
window manager to honour the position hint it requests (that's
why it's called a hint).  An application that fails to draw
itself properly is broken. 

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: Bob Woodside <[email-masked]>
Date: Wed, 27 Oct 1999 13:22:57 -0400

Dominik Vogt wrote:
> > Java2/Swing applications have weird rendering problems.
> 

	Sounds like the "application" is the JDK itself. Bummer.

	Kris -- Dominik is absolutely right. But before rushing to report a bug
to Sun - have you searched through Sun's outstanding patch list to see
if there might be anything applicable here (I don't have the URL handy)?
I've not used Solaris-7 yet, but my suggestion is based on experience
with past out-of-the-box Solaris releases.

	Brad -- I seem to recall that you've done a lot of Java work...(am I
remembering correctly, or is there another Brad Giaccio running around
the Net trying to confuse people?) Ever run into this sort of problem?
If not, do you use NoPPosition?

	Dan -- We were discussing a while back the wisdom (or lack thereof) of
switching the default from UsePPosition to NoPPosition. Maybe we were
wise to wait a bit. You were going to switch your setup to specify Style
* NoPPosition and see if anything went haywire. What results did you
have?

Cheers,
Bob

---

From: Kris Wehner <[email-masked]>
Date: Wed, 27 Oct 1999 14:48:24 -0500

> 	Sounds like the "application" is the JDK itself. Bummer.

yes, undoubtedly.

> if there might be anything applicable here (I don't have the URL handy)?

My machine is all patched up (as of last week some time), and the JDK is
the latest stable.

I thought before I had nailed it down to NoPPosition, but it is actually
intermittant. I turned off NoPPosition and the bug went away, but I just
turned it back on and it was fine. I also have experienced the bug with
NoPPosition off. I suspect it's some sort of inconsistancy with what sun
expects from dtwm in certain fringe cases. I may try and take a poke at 
it myself if I can nail down the cause more firmly.

kris
-- 
kris wehner ([email-masked])
 Tcl tends to get ported to weird places like routers.
 	-Larry Wall
--
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, 27 Oct 1999 16:06:54 -0400

> * NoPPosition and see if anything went haywire. What results did you

So far, I haven't detected any PPosition problems.

I don't run any Java applications.

During startup I'm seeing wireframes for offdesk windows making me
click the mouse, but thats just 2.3.10 with any PPosition setting.

--
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: Danek Duvall <[email-masked]>
Date: Wed, 27 Oct 1999 15:52:49 -0700

> > 	Sounds like the "application" is the JDK itself. Bummer.

I'll echo that.  The source of Java's windowing stuff is absolutely
littered with crap to work around bugs in dtwm.  They assume that you're
running dtwm or olwm as your window manager and if you're not, well, that's
not supported.  They've closed several bugs of mine with exactly that
explanation.  So I wouldn't rely on the right fix ever being made.

> it myself if I can nail down the cause more firmly.

I've been having this problem myself recently, but in my case it's not at
all related to {Use,No}PPosition.  Instead, it only occurs on naked
transients.  If I turn DecorateTransients on for the windows it has
problems with, the problem disappears.  Switch back to NakedTransients, and
it's there.  Every time.

Re-reading the original bug report, it may not be clear what exactly is
going on here (though of course, I may be suffering from something slightly
different).  What's happening to me is that the (naked) window is being
drawn the correct size.  However, the bottom of the window has a portion
where the contents of the window aren't drawn.  The height of this piece is
about the height of a title bar.

Sometimes the window contents are displayed in the correct location w.r.t
the top left corner, and the bottom of the contents are clipped, and
sometimes the window contents are clipped off the top, and the blank space
at the bottom doesn't cover everything.  In the latter case, there seems to
be some left-right displacement as well.

I can make snapshots if anyone thinks it would help, and I have a code
snippet so you can reproduce it.

This only happens on descendants of JOptionPane, as near as I can tell.

HTH,
Danek

---

From: Kris Wehner <[email-masked]>
Date: Wed, 27 Oct 1999 18:58:01 -0500

> problems with, the problem disappears.  Switch back to NakedTransients, and

Yes, this is the cruft of the problem.
However, /sometimes/ naked transients work for me, and /sometimes/ they
don't.  If it's not working, it actually degrades each time you call 
setVisible() on the window (less and less of it draw, until eventually you
just get a gray blob). If decorate transients works, I'll use that for a
workaround.

thanks
kris

---

From: Bob Woodside <[email-masked]>
Date: Wed, 27 Oct 1999 23:09:47 -0400

Danek Duvall wrote:
> running dtwm or olwm as your window manager 
> * and if you're not, well, that's not supported. *

<soapbox humor=bile>
	Seems to me that it's downright fraudulent for them to claim to support
a Java implementation for the X Window system in that case.
</soapbox>

> This only happens on descendants of JOptionPane, as near as I can tell.

	I don't know about anyone else, but I'd personally like to see
screenshots and a code snippet.

Cheers,
Bob

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 28 Oct 1999 07:36:45 -0400

> screenshots and a code snippet.

Well Bob the good news is your memory isn't failing (At least in this
instance anyway).  I'm as far as I know the only bgiaccio running
around at there.  But anyway you are all quite correct sun does make
assumptions about your window manager and your xlibs as well, as a
matter of fact if you install jdk1.2.x they tell you you need to path
your xserver but if you look close they are patching /usr/openwin/lib
not just the x server.  So my advice is to try this in your java code
where you can consitenttly reproduce the problem, add one line of code.

<window>.validate(); 

This will force all of its children which are marked invalid to get
validated.  And when you first create a window everything is invalid.
The problem is Sun changed the code for show so it nolonger does this on
its own, the programmer needs to do it.  Well let me know if this fixes
it or not otherwise pass me the sample code and I'll take a look.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Kris Wehner <[email-masked]>
Date: Thu, 28 Oct 1999 11:01:28 -0500

> screenshots and a code snippet.

http://www.cow.org/~wehner/decorate-transient.gif
http://www.cow.org/~wehner/naked-transient.gif

I have noticed that while the decorate/naked transient will consistantly
trigger the bug, if you make your window borders "thin enough", it will
sometimes crop up as well.

The code for this is:
private void handle_file_open_click()
{
  if(!handle_file_close_click())
    return;
  
  if(open_file_dialog == null)
    {
      open_file_dialog = new JFileChooser();
      open_file_dialog.setCurrentDirectory(new File("."));
    }

(which is outside of the JOptionPane, as well).

kris

---

From: Danek Duvall <[email-masked]>
Date: Thu, 28 Oct 1999 10:34:54 -0700

> a Java implementation for the X Window system in that case.

People at Sun seem to have forgotten about X, and know only about two
beasts: OpenWindows and CDE.  No matter that they're both just layers on
top of X.  It's really quite sad.

> screenshots and a code snippet.

I've attached Test.java, which you can compile and run.  It requires either
Swing or Java 1.2.

I've put pictures up on

    http://www.emufarm.org/~duvall/fvwm/

There are the good and bad results from the test code, plus the good and
two bad results I tried to describe yesterday.

I've also noticed that when the code is run under Linux, using blackdown's
1.2 jre, it works just fine.  I may have to compare source bases.

HTH,
Danek

---

From: Danek Duvall <[email-masked]>
Date: Thu, 28 Oct 1999 11:44:33 -0700

On Thu, Oct 28, 1999 at 07:36:45AM -0400, Brad Giaccio wrote:

> So my advice is to try this in your java code where you can consitenttly
> reproduce the problem, add one line of code.
> 
> <window>.validate(); 
> 
> validated.

I've put up a second test program that lets you do that, rather than using
the canned JOptionPane.showXXXDialog().  I've tried validate() on all three
components in that program, and nothing doing.  I also tried a pack() on
the dialog, but again ...

Now, if I put the JOptionPane directly inside of a JFrame, and call pack()
on the frame before I show() it, then there are no problems.

Danek

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 29 Oct 1999 08:24:24 -0400

Unfortunatelly you are right with the canned dialogs it is next to
impossible to get them to paint correctlly.  I've noticed it happens
less frequentlly with jdk1.2.2 however maybe you could give that a shot.
But I'm afraid the short answer is there is nothing fvwm could do about
it.  I suppose you could set up fvwmEvent to resize the window 1pixel
wider on an add window (since a resize force the validation) to get it
right.

Brad

On Thu, Oct 28, 1999 at 11:44:33AM -0700, Danek Duvall wrote:

> > So my advice is to try this in your java code where you can
> > consitenttly reproduce the problem, add one line of code.
> >
> > <window>.validate();
> >
> I've put up a second test program that lets you do that, rather than
> using the canned JOptionPane.showXXXDialog().  I've tried validate()
> on all three components in that program, and nothing doing.  I also
> tried a pack() on the dialog, but again ...
>
> Now, if I put the JOptionPane directly inside of a JFrame, and call
> pack() on the frame before I show() it, then there are no problems.
>
> Danek