orig synopsis:  "Window management fault with Forte under Linux (with KDE2)"




Unavailable to me now. The environment is the Sun released JDK1.3 (first final
release) running on a Mandrake Linux 7.2 / x86 computer.



Steps: Run Forte using JDK1.3 under Linux on KDE2.

Window management is completely messed up. Windows do not appear where they
should, and are not sized as they should (e.g. the main toolbar sometimes
appears in the middle of the screen and is a tenth of the screen width, the
explorer window appears anywhere on the screen and is often zero-size).

When moving between virtual desktops, moving back to the desktop with Forte
doesn't cause all the windows to appear again. One must find them in
the "taskbar" and open them.

The "find" dialog box has a special problem in that after one item is found,
subsequent tries to open the dialog box fails; the box does not show up. One
must go to another virtual desktop, and come back before the box appears,
underneath another window.


Forte (and other Netbeans binaries) executes fine on Windows, but have this
problem on Linux.
(Review ID: 112673) 
======================================================================




java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

Under KDE2 (linux ) and java 1.3 modal JDialogs are
created with unexpected sizes.  This appears
to occur only on the second dialog created.
This problem does not appear to be present
on jdk.1.2.  This problem does not appear to occur
on kde 1.x. It is present in  jdk1.3.0_01.

In the sample code below the first dialog appears
correct, but the second dialog is smaller in size
even though it is created identically to the first.


import javax.swing.*;

import java.awt.event.*;

public class Test {
    public static void main( String [] arg ) {

        JFrame frame = new JFrame();
        frame.setSize( 600, 400 );
        frame.setLocation( 20, 20 );
        frame.setVisible( true );
        

        final JDialog d = new JDialog( frame, "test2", true );
        JButton b = new JButton( "exit");
        b.addActionListener( new ActionListener() {
                public void actionPerformed( ActionEvent e ) {
                    d.setVisible( false );
                }
            }
        );
                    
        d.getContentPane().add( b );
        d.setSize( 200, 300 );
        d.setLocation( 50, 50 );
        d.setVisible( true );

        final JDialog d2 = new JDialog( frame, "test2", true );
        JButton b2 = new JButton( "exit");
        b2.addActionListener( new ActionListener() {
                public void actionPerformed( ActionEvent e ) {
                    d2.setVisible( false );
                }
            }
        );
                    
        d2.getContentPane().add( b2 );
        d2.setSize( 200, 300 );
        d2.setLocation( 50, 50 );
        d2.setVisible( true );
        

    }

}
(Review ID: 115103)
======================================================================




java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)

Attempting to run Netbeans Development Version under KDE 2.0, the first thing
that you'll notice is that the splash screen is reduced to a small dot on the
screen. Also, Netbeans (and Forte for Java 2.0 as well) has a very hard time
remembering the location of windows on the screen.
(Review ID: 117966)
======================================================================




java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)

If you open a JOptionPane and then a JFrame, the size of the JFrame is wrong.

Window manager is KDE2.

Here is a sample program. The second frame should have a size of 320x200, but
instead it has something like 16x10. The sample works with IBM's JDK.

import javax.swing.*;
 
public class Test {
  public static void main( String[] asParam ) {
    JOptionPane jop = new JOptionPane(
      "Message", JOptionPane.INFORMATION_MESSAGE
    );
    JDialog jd = jop.createDialog( null, "Title" );
    jd.setModal( false );
 
    jd.show(); // comment out this line to get the second frame right
 
    JFrame jf = new JFrame( "Frame" );
    jf.setSize( 320, 200 );
    jf.setVisible( true );
  }
}
(Review ID: 118797)
======================================================================




java version "1.3.1-rc2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc2-b23)
Java HotSpot(TM) Client VM (build 1.3.1-rc2-b23, mixed mode)

I cannot get a JDialog to redisplay after it has been hidden using. I have a
JFrame constructed and displayed, then popup a custom dialog.  If the user
presses cancel, I hide the dialog by calling hide().  If I would like to show
the dialog again, I call show() and it doesn't display.  It will show if I
minimize the dialog then maximize it again.

This only happens when I am using the KDE 2.X desktop.  It works correctly on
KDE 1.X.  So I am not sure if this is a KDE problem or JDK problem.

  To reproduce, run the code below on a system running Linux and KDE 2.X.
Choose File->show dialog from the menu.  Press the cancel button in the center
of the dialog.  Next, try to choose File->show dialog from the menu on the
JFrame again.  The dialog will not display until you minimize the JFrame and
maximize it again.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
public class MyFrame extends JFrame implements ActionListener {
 
  private JMenuItem dialogMenuItem, exitMenuItem;
  private JDialog dialog;
 
  public static void main( String[] args ) {
 
    MyFrame myFrame = new MyFrame();
    myFrame.show();
  }
 
  public MyFrame() {
 
    super("MyFrame");
 
    JMenuBar mb = new JMenuBar();
 
    JMenu fileMenu = new JMenu("File");
    fileMenu.setMnemonic(KeyEvent.VK_F);
    mb.add(fileMenu);
 
    // Login to Database
    dialogMenuItem = new JMenuItem("show dialog");
    dialogMenuItem.setMnemonic(KeyEvent.VK_I);
    dialogMenuItem.addActionListener(this);
    fileMenu.add(dialogMenuItem);
 
    exitMenuItem = new JMenuItem("Exit");
    exitMenuItem.setMnemonic(KeyEvent.VK_E);
    exitMenuItem.addActionListener(this);
    fileMenu.add(exitMenuItem);
 
    getRootPane().setJMenuBar(mb);
    setSize( 400, 300 );
  }
 
  public void actionPerformed(ActionEvent e) {
 
    Object o = e.getSource();
    if( o == exitMenuItem ) {
      System.exit(0);
    }
    else if( o == dialogMenuItem ) {
      if( dialog == null ) {
        dialog = new MyDialog(this);
      }
      dialog.setVisible(true);
    }
  }
}
 
class MyDialog extends JDialog implements ActionListener {
 
  private JButton cancelButton;
 
  public MyDialog(JFrame parent) {
 
    super(parent, "MyDialog", true);
 
    cancelButton = new JButton("Cancel");
    cancelButton.addActionListener(this);
 
    getContentPane().add(cancelButton);
 
    setSize( 200, 200 );
  }
 
  public void actionPerformed(ActionEvent e) {
 
    Object o = e.getSource();
    if( o == cancelButton ) {
      hide();
    }
  }
}
(Review ID: 123422)
======================================================================

Blackdown 1.3.0 FCS version of the JDK works. Something they're doing reads  the window locations properly. Perhaps they can assist.
(Review ID: 117966)
======================================================================

Should find out if this happens with RedHat Linux as well.  
If so, it sounds like something we need to fix.  
 xxxxx@xxxxx  2000-11-30

Reproducible on build 1.4.0-beta_refresh-b71 on RedHat 7.1
 xxxxx@xxxxx  2001-07-16  

Due to developer demand, I am committing this to Tiger.  I don't think we 
officially support kwin (which I assume is the WM in use), but it would be 
nice if the WM generalization we have planned also fixed this.  
 xxxxx@xxxxx  2001-07-30

Committing to hopper.
 xxxxx@xxxxx  2001-11-08 

Judging from the traffic on the JDC about this issue, there is a lot of 
developer interest in it.  I should report that our marketing department, 
specifically the Product Manager for Java2 SDK, Standard Edition, version 1.4, 
has decided that we won't support KDE/kwin.  Gnome/sawfish would be the only 
fully-supported configuration.  I don't know that this issue is likely to be 
completely fixed at any point.  
 xxxxx@xxxxx  2001-11-11 

We have had some feedback from developers that problems under KDE/kwin and 
Gnome/Sawfish is much improved in Merlin.  Here is an example: 
> I just downloaded JDK1.4 beta-3 for linux and the KDE defect disappeared
> completely. This is improvement since the first beta. I only checked
> this on Red Hat 7.1, KDE 2.1.1

 xxxxx@xxxxx  2001-11-13

Another developer comment:
> I had the same problems with the Wireless Toolkit running on SuSE 7.1 using
> KDE 2.2 but not when I use the Gnome desktop. Today I installed KDE 3.0 (QT
> 3.0) and everything worked fine!!!

We filed a number of bugs against kwin while working on window management 
issues for 1.4.  It may be that some of those have been fixed, resulting in 
better behavior with the new release of KDE/kwin.  
 xxxxx@xxxxx  2002-04-19




 xxxxx@xxxxx   2002-04-22

Insets problems are probably a duplicate of 4493724 and should have
been addressed for 1.4 by the fix for that bug.

Iconification of top-levels when switching workspaces is a duplicate
of 4388928 that should have been fixed for 1.4 too.

======================================================================
This bug has been open for a very long time now, gathering
lots of votes on the jdc. However, we (Sun's AWT team)
believe that the majority, if not all, of the issues were
resolved for 1.4. Some of the problems were caused by KDE
bugs that were fixed in KDE2.2 and KDE3. See, for example,
KDE Bug#15430:

 http://bugs.kde.org/show_bug.cgi?id=15430

and some other bugs were in Java.

The problem is that this report accumulates many different
issues that are not closely related to each other.

Now I've spent some time testing J2SE1.4.1 with KDE2.2-10,
and couldn't reproduce any of the problems mentioned in the
bug report. I have also tried to contact all the people
who were listed among the submitters, and those of them
who answered said that they were running 1.4.1 with KDE2.2
and KDE3 and that the problems didn't manifest there, i.e.
the bug is fixed.

Thus I am marking this report as fixed. Even if there
are other issues, developers seem to prefer voting for
this bug instead of filing separate ones.  Instead, we
request that people file separate/new bug reports.  
Any other issues with Window management under KDE, we
shall deal with via separate bug reports.
 xxxxx@xxxxx  2002-11-13

I have the same problem under SuSE 7.0

Please fix this!  The java.awt.PrintJob window shows up as
extremely large (many thousands of pixels) because of this
bug.  All of my users who run Mandrake 7.2 cannot print because of this!  I don't know if it is specific to Mandrake 7.2, or KDE 2, but non-Java programs have no problems!

Calling setSize(...) on these windows seems to have no effect.  Many windows show up with very incorrect sizes and are very annoying, but the PrintJob window is a show stopper.

The same problem appears in the 1.3.1 release beta!

I assume it is closely related to  4395578,
both seem to have the same reason

I don't know if this is helpful or not, but the IBM JRE 1.3.0 doesn't have this problem, so I have switched to using that for a little while.

Still the same problem with jdk1.3.1 and Redhat7.0.
Get Blackdown until SUN realizes this bug makes their jdk
unusable for swing and KDE2

Under SuSE 7.1 using 1.3.1 rc2 - the sizing problem now 
seems fixed but the problem with windows dissapearing does 
not! 

I see this problem too, I have Mandrake 8 with KDE 2.1.1. I 
can't use Jbuilder 5 with Sun JDK 1.3 and Sun JDK 1.4 beta, 
but with JDK 1.3.1 it works fine, but then i get another bug 
with autocompletion not working.

Problem of this kind also appears under fvwm/fvwm2.
I switched to ctwm, it appears to work better.

Occurs on RedHat 7.1, KDE 2.1.1, JDK 1.3.1.  Critical blocking problem for our project - development proceeding under Gnome, but customer base wants KDE.

This bug can also be seen when running either Forte 3 under 
Linux Mandrake 8.1 . The main window appears a lot too small
and is not usable(bad menu drawing,...)

It can also be seen but at a less problematic level with 
Together Control Center (www.togethersoft.com). 
When you show up the property window, switch to another 
desktop an then re-switch to Together, your property window 
doesn't appear anymore on the screen and all action to show 
it up via menu or shortcuts has no effect. You must 
minimize and then maximize Together again to make the 
property window show up again.

Those bugs are present on the j2sdk1.3 and j2sdk1.4.0 
downloaded from java.sun.com.

For reference my Linux system is hte following : 
Linux version 2.4.2-3mdk (jgarzik@no.mandrakesoft.com) (gcc 
version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) 
#1 Tue Feb 27 02:14:17 CET 2001

One possible workaround is to use Xnest and use the sawfish
 windowmanager in Xnest.
But pretty please fix this. KDE is a major player in the
desktop world on Linux.

Was JDK 1.3 even *tested* on KDE before being released? 
This is a pretty serious bug to have in production software.

I have similiar windowing grief with Java using fvwm2 on
Solaris 2.6 and Solaris 2.5.1 SPARC machines.  Switching to
CDE or WindowMaker solves the problem.  I suspect it's a
window manager issue and not solely a Java problem.

Please fix the KDE2 problems, there also seems to be a 
problem with JBuilder 5's Code Insight windows which do not 
always appear 'on top' (you need to click them to front by 
locating them in the list of windows).

I've the same problem under RedHat 7.1

A *lot* of people use KDE as desktop and KWin is part of 
core KDE.
Perhaps a KDE developer (look at bug 14732 in 
bugs.kde.org) can assist.

I'm using RedHat Linux 7.1 with KDE 2.2 When pressing the 
run button the size of the window that will appear is 
about .75"x.75" (inches). Then if you double click it the 
phone will appear but the window is close and open. I'm 
using blackdown 1.3.1. But in gnome 1.4 it is working 
properly.

For anyone interested, here's a workaround we're using for 
this bug. Unfortunately, you have to create a subclass of 
JDialog...

public class FixDialog extends JDialog
{
  private static final boolean IS_LINUX = System.getProperty
("os.name", "").indexOf("Linux") != -1;

  public void pack()
  {
    if ( IS_LINUX && !isResizable() )
    {
      packFix();
    }
    else
    {
      super.pack();
    }
  }

  private void packFix()
  {
    setResizable( true );
    super.pack();
    setResizable( false );
  }
}

This should be fixed.

A decision to not include a solution for this bug in version
1.4 could 
make Java unusable for our product on Linux.  Using the beta
1.4
release on fvwm causes our product to have numerous
windowing
problems (see 4472864).  I was hoping we could use KDE as a
temporary work-around, and now I see KDE also has similar
problems.

Can anyone at Sun tell us what window manager Java will
support on
the Linux platform?  The installation notes for 1.3.1:
          
http://java.sun.com/j2se/1.3/install-linux-sdk.html
make it sound like KDE/KWM are recommended.

had same problem. digging a bit deeper showed the following:

         window
         manager       WindowMaker     KDE     FVWM     twm
jdk
------------------------------------------------------------
jdk1.1.8(sun)          no              no      
jdk1.2.2(sun)          no              no      
jdk1.3.1_01(sun)       no              no      no       yes
j2sdk1.3.1(blackdown)  no              no
IBMJava2-13            yes             yes
-----------------------------------------------------------

now with IBMJava2-13 everything works fine for me.

<subject>Workaround</subject>

Hi folks:

I faced the same issue on my Linux box.
The current environment is:

Redhat Linux
Linux Kernel: 2.4.2-4
glibc 2.2.2-10
kde 2.1.x

The J2ME Wireless Toolkit seems to work fine with
SUN JDK 1.4.0 Beta but not with JDK 1.3.x!

Hope this work around would be helpful for some of you.

regards
Saifi Khan.

The marketing departments decision not to support KDE is
a very bad one, As KDE is the most complete desktop 
availabel on Linux today, and probably the most widely used.
Very sad indeed!

java1.3.x is requesting that un-resizable transient 
windows such as JProbe's splash screens and JBuilder 
code-insight popups are started in the iconified state, 
which kwin respects. Iconifying the application, and then 
de-iconifying it returns the windows to the appropriate 
(non-iconified) state. This is a very serious problem and 
is certainly a bug in java not kde (the iconify request is 
certainly wrong, and probably a hack for some other wm). 

Major problem for our application: JOptionPane comes up with 
no text in KDE 2.2.2 on Linux. If I use twm as the window 
manager on Linux JOptionPane works fine. If I use KDE 2.2.2 on 
Solaris it also works.

One bizarre thing is that if I first 
start a bare xsession (like with "xinit $(which xterm)") and 
load kwin, it works fine (JOptionPane shows text). I can load 
kdesktop and kicker and it still works. But if I load all of 
KDE with the startkde script (which loads ksmserver, don't know 
what that does), my JOptionPanes come up blank. They have the 
icon, but there is no button or text. I don't know how to 
explain to people that the readability of error messages in our 
app are window manager dependant! It seems ridiculous. 

Not support KDE!  *shakes head in disbelief*  Dumb, dumb, 
DUMB!  Fire the marketting manager, now!  (Has he ever even 
used a Linux desktop?)

Perharps SUN decides that a KDE user can't be a Java 
developer?!? 

It works fine with JDK1.4.0-rc an my Linux Box with
KDE2.2.1pre. So it seems that the Bug has been fixed in JDK
1.4.

This bug MUST be fixed!!

Strider <><

I know the decision not to support KDE/kwin is in part
political (Sun backs Gnome) and part pragmatic (there is
only enough resource to support so many wms), but this
is a serious problem for a very common desktop environment.

We deploy a java app on Linux, with JRE, and right now
we are using Blackdown 1.3.0 which does not have this
problem (though Blackdown 1.3.1 does). We'd like to use
a newer JVM and we may have to go with IBM if Sun does
not fix this.

Please give your marketing manager a Linux box to play with,
and she will understand eventually. In the mean time I would
recommend using the IBM JVM, which supports KDE and
WindowMaker. 

"I should report that our marketing department,
specifically the Product Manager for Java2 SDK, Standard
Edition, version 1.4,
has decided that we won't support KDE/kwin."

*WRONG* answer.  KDE is the standard in our shop, as it is
in many other places.  Modal dialog issues under 1.4 final
are keeping us from migrating from 1.3.1 to 1.4.

"I should report that our marketing department, 
specifically the Product Manager for Java2 SDK, Standard 
Edition, version 1.4, has decided that we won't support 
KDE/kwin.  Gnome/sawfish would be the only fully-supported 
configuration."

all religious wars aside, facts are KDE and Gnome really 
have about the same popularity (say 30-35 % each) and 
seeing Sun doing such a bad move is a frightening sight.

Please fix this bug!
I hope that news about sun decision to drop KDE support is 
false, it is simply frightening to me (and about 50% linux-
java community) I guess.

CodeInsight of JBuilder6 doesn't work with KDE 2.2.2 (SuSE 
7.3). I don't think I'm the first to report this...
I don't know if the following problem is also related:
The "About" dialogbox of a Swing App "generated" by 
JBuilder6 is just as big enough to show the "Ok" button. 
An attempt to resize it collapses it and it can't be 
accessed anymore at all. When I set "setResizable(false);" 
to "true", the dialogbox looks normal (but is resizable...)
Will go and get JDK 1.4 now...

I had the same problems with the Wireless Toolkit running on SuSE 7.1 using 
KDE 2.2 but not when I use the Gnome desktop. Today I installed KDE 3.0 (QT 
3.0) and everything worked fine!!! 
 

I'm running suse 8.0 / kde 3.0 / java1.3.1_02 and the toFront() method 
isn't working. one has to pick the window from the taskbar, which is highly 
undesirable. 
why is sun dropping the support for kde? i can't see any good in that move. 

does this bug occur on KDE 3, SUSe 7.0, with JRE 1.4.0_01 
too? in that case, it explains all the headache i've had from 
improperly sized windows! *damn*

sorry, I meany SuSE 8.0 =p

This issue shows up under Redhat Linux 7.x as well...

Using Mandrake Linux 8.2, KDE 3, and java 1.4.1 beta, I do
NOT see this problem.  So maybe there's hope.

Hi all,

I have found a entry in the forum about getInsets() 
(http://forum.java.sun.com/thread.jsp?
forum=57&thread=302473).  And a guy wrote there following: 

"On most systems, the size of decorations around a native 
window depends on external parameters which are not known 
to the program (accessibility, window manager configuration 
on unix systems, etc).

Because of that, the insets of the window is 0 until it 
becomes visible, at which point the inset is added to the 
current size.

Note that this is why most java programs incorrectly save the 
size to their main window:
- they save their size while being visible (including inset)
- they restore their size before setVisible(true), which does 
not include insets
- when becoming visible, their size increases."

I think that's interesting. Some guys here wrote that they 
haven't this problem under KDE3. May be in KDE3 will be 
the "insets" known before the window is displayed.

regards

Seeing a bug like this sticking around for a few years really 
makes me wonder what's going on at the headquarters at Sun.

I've been developing in Java since the early days and always 
loved the language, but it really makes me sad to see Sun 
wasting it all away by focusing on the wrong issues all the 
time. 

I'm also an avid Python user and when I compare Sun's 
behaviour with the development model of Python (where each 
user actually means something to the core team) I really think 
Sun has a few lessons to learn. If Java would have been an 
Open Source(TM) project, bugs like this would have been 
fixed in a few days. 

If Sun really want Java to succeed I think it is time they stop 
listening to their marketing department and start adressing 
the real issues.