[Bug AWT/20014] New: BufferedImage.getGraphics() aborts
Trying to call BufferedImage.getGraphics() aborts on my Linux system. Tested with both in gcc-4.0-20050130 snapshot and a fresh CVS checkout of gcc-gui-branch-20050128 as of 20050209. I have recommended/current versions of all dependencies including cairo-0.30. Testcase attached. Using gij with or without -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D does not help. -- Summary: BufferedImage.getGraphics() aborts Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20014
[Bug AWT/20014] BufferedImage.getGraphics() aborts
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-16 18:26 --- Created an attachment (id=8205) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8205&action=view) testcase jfig-gcc/jfig> gij PR20014 -I- started... -I- got a buffered image: [EMAIL PROTECTED]: type=2 java.awt.image.DirectColorModel[pixel_bits=32, [EMAIL PROTECTED], transferType=3, transparency=3, hasAlpha=true, isAlphaPremultiplied=false, redMask=ff, greenMask=ff00, blueMask=ff, alphaMask=ff00] java.awt.image.WritableRaster[(0,0), 50 x 50,java.awt.image.SinglePixelPackedSampleModel[scanlineStride=50, mask[0]=0xff, mask[1]=0xff00, mask[2]=0xff, mask[3]=0xff00],[EMAIL PROTECTED] Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20014
[Bug SWING/20015] New: JMenu stays open but should not
Showing a JMenu works. However, clicking outside the JMenu to close the menu does not - the JMenu patiently stays open until one of its JMenuItems is selected (clicked). For compatibility with the JDK/JRE and all major GUI environments, a JMenu should close when the user clicks the inside the current application but outside the JMenu. Testcase attached. -- Summary: JMenu stays open but should not Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: graydon at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20015
[Bug SWING/20015] JMenu stays open but should not
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-16 18:50 --- Created an attachment (id=8206) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8206&action=view) testcase Compile and run, then select a JMenu. The JMenu stays open until one of its (active or inactive) JMenuItems is selected, but not when the user clicks outside the JMenu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20015
[Bug AWT/21660] New: FileDialog.SAVE broken
FileDialog does not allow saving files.
A FileDialog created with FileDialog.SAVE mode still comes up
in FileDialog.LOAD ("open file") mode. The wrong title is no
real problem, but without a textfield there is no way to select
a new (non existing) filename...
testcase and screenshot attached.
gij (GNU libgcj) version 4.1.0 20050424 (experimental)
--
Summary: FileDialog.SAVE broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21660
[Bug AWT/21660] FileDialog.SAVE broken
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-05-19 08:14 --- Created an attachment (id=8927) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8927&action=view) screenshot showing the SAVE-mode filedialog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21660
[Bug AWT/21660] FileDialog.SAVE broken
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-05-19 08:17 --- Created an attachment (id=8928) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8928&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21660
[Bug AWT/19838] New: Repaint-Loop due to setBackground()
Calls to setBackground() inside paint() cause an infinite repaint-loop, because setBackground() unconditionally causes a repaint(). This does not occur with JDK 1.1 .. 5.0 We might want to check whether the background color changes... -- Summary: Repaint-Loop due to setBackground() Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/19839] New: Repaint-loop due to createImage() and non-null ImageObserver
Calling Graphics.drawImage( image, x, y, observer ) results in an endless repaint loop when observer is non null and the image was retrieved via Component.createImage(width,height). Note: this does not happen for Image's created via Toolkit.getImage()... Testcase follows -- Summary: Repaint-loop due to createImage() and non-null ImageObserver Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug AWT/19838] Repaint-Loop due to setBackground()
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:22 --- Created an attachment (id=8148) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8148&action=view) Demonstrates the repaint loop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/19839] Repaint-loop due to createImage() and non-null ImageObserver
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:24 --- Created an attachment (id=8149) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8149&action=view) Demonstrates the repaint loop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug AWT/19839] Repaint-loop due to createImage() and non-null ImageObserver
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:27 --- Changing the call to drawImage( image, x, y, null ) makes the program work. However, an Image create by createImage(width,height) should be completely initialized at once: there is no image data to read asynchronously... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug AWT/19840] New: drawImage bug
The attached program demonstrates the (wrong) behaviour of the
'synchronous' variants of java.awt.Graphics.drawImage when
asked to draw to 'negative' offsets. Both Canvas'es should look
the same, but current libgcj does shift the image to the bottom right
instead of to the upper left...
--
Summary: drawImage bug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot
org,java-prs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug AWT/19840] drawImage bug
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:30 --- Created an attachment (id=8150) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8150&action=view) testcase for the bug, both images should look the same -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug java/19841] New: Inner classes problem
gcj fails to compile the following testcases, while jikes, javac, and Eclipse
allow the code. (Might be a duplicate of existing inner classes problem
reports.)
/* GCJ inner class problem */
import java.awt.*;
public class SSS extends Canvas {
int state = 0;
public class Selector extends Dialog {
public Selector( Frame parent ) {
super( parent );
}
public void foo() {
state = 42;
}
}
}
--
Summary: Inner classes problem
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19841
[Bug AWT/19842] New: MouseEvent ignores Button2 and Button3
The attached testcase demonstrates the java.awt.event.MouseEvent internally knows about the middle and right mouse buttons (because the correct data shows up in event.toString()). However, querying those values via getButton() or getModifiers() or InputEvent.isAltDown() / isMetaDown() always returns false. This makes it impossible to detect middle/right button clicks in user programs. Testcase usage: compile and run, then try mouse-clicks on the frame using all mouse buttons and the (shift/alt/meta/control)-key+button1 variants. Might use java.awt.Robot to automate... -- Summary: MouseEvent ignores Button2 and Button3 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug AWT/19842] MouseEvent ignores Button2 and Button3
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:39 --- Created an attachment (id=8152) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8152&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug AWT/19843] New: AWT program ignores System.exit()
On my system, the attached testcase (actually the same testcase as used for bug 19839) randomly fails to terminate despite the calls to System.exit() at the end of the main() method. This occurs approximately on every tenth invocation of the program on my system. I suspect some thread-issue related to the high repaint()-load created by the program. (Linux 2.4.20, SuSE 8.2, gcc-4.0-20050130 snapshot) -- Summary: AWT program ignores System.exit() Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19843
[Bug AWT/19843] AWT program ignores System.exit()
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:44 --- Created an attachment (id=8153) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8153&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19843
[Bug AWT/19844] New: Swing components ignore key events
non-text Swing components seem to ignore key-events completely. No small testcase yet. Can be demonstrated via the program attached to http://gcc.gnu.org/ml/java/2005-02/msg00016.html (The main ImageCanvas never receives its key events). -- Summary: Swing components ignore key events Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19844
[Bug AWT/19845] New: Swing ToolTipManager and getLocationOnScreen
javax.swing.ToolTipManager causes (eternal) NullPointerExceptions when JToolTips are enabled on non-showing JComponents, e.g. on not-yet-shown dialog windows or just-closed dialog windows. If the bug happens, Swing is unusable, because the main GUI thread never recovers from the NPEs. ToolTipManager should probably ignore non-showing components and should be more robust... I have no small testcase, but a typical stack trace looks like this: Exception during event dispatch: java.awt.IllegalComponentStateException: component not showing at java.awt.Component.getLocationOnScreen() (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.SwingUtilities.convertPointFromScreen(java.awt.Point, java.awt.Component) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.SwingUtilities.convertPoint(java.awt.Component, int, int, java.awt.Component) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.SwingUtilities.convertPoint(java.awt.Component, java.awt.Point, java.awt.Component) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.ToolTipManager.getContentPaneDeepestComponent(java.awt.event.MouseEvent) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.ToolTipManager.mouseExited(java.awt.event.MouseEvent) (/opt/gcc40/lib/libgcj.so.6.0.0) -- Summary: Swing ToolTipManager and getLocationOnScreen Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19845
[Bug AWT/19846] New: AWT Toolkit.createImage very slow
Loading images from files, inputstreams, or URLs via the variants of Toolkit.getImage( ... ) is incredibly slow in gcc-4.0-20050130. Even creating a few small icons incurs noticable overhead (some seconds) on my Athlon 2600+. Loading JPG-images of ~800x600 pixels can take over ten seconds. No seperate testcase, but you can use the testcase for bug 19839 (supply a bigger image instead of the small 64x64 icons) or the program attached to http://gcc.gnu.org/ml/java/2005-02/msg00016.html -- Summary: AWT Toolkit.createImage very slow Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19846
[Bug AWT/19840] drawImage bug
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 10:15 --- Created an attachment (id=8154) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8154&action=view) demo image for the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug AWT/19847] New: AWT drawImage fails to render transparent GIFs
Try running the testcase for bug 19840 (DrawImageBug) with the small 2-color transparent GIF image attached to this report. (Rename updatemodebutton.gif to jfig.gif for the program to find the image or edit the testcase). The image is not drawn at all; this seems only to occur for transparent black-and-white (2 colors) GIFs. Might be a bug in drawImage() or getImage(). -- Summary: AWT drawImage fails to render transparent GIFs Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19847
[Bug AWT/19847] AWT drawImage fails to render transparent GIFs
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 10:20 --- Created an attachment (id=8155) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8155&action=view) demo image for testcase rename to 'jfig.gif' and run 'DrawImageBug' from bug 19840. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19847
[Bug AWT/19849] New: Swing: ActionEvent.getActionCommand null
In order to avoid the overhead of individual event-listeners for every button or menu-item, my application uses a central ActionListener which uses ActionEvent.getActionCommand() to distinguish between the several (hundred) event sources. Unfortunately, ActionEvents created by Swing components in libgcj always return null for getActionCommand(). Testing with the JDKs (1.1 .. 5.0) reveals, that the JDKs return getText() for standard AbstractButtons like JButton or JMenuItem. I suggest that gcj also returns the value of getText() for these components. See attached testcase; compile and run with gcj and a JDK/JRE for comparison. -- Summary: Swing: ActionEvent.getActionCommand null Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19849
[Bug AWT/19849] Swing: ActionEvent.getActionCommand null
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 13:05 --- Created an attachment (id=8156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8156&action=view) testcase for the bug, run with gcj and java for comparison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19849
[Bug AWT/19860] New: Swing JOptionPane and multiline texts
JOptionPane fails to render multiline text in the 'standard' dialogs.
Testcase attached; tested with gcc-4.0-20050130 snapshot and current
gui-branch-20040128 cvs.
(the location of the JButtons is sub-optimal, too.)
/* MultilineJOptionPane.java
*
* demonstrates GCJ doesn't display multiple lines of text in a JOptionPane
*
* (C) 2005 FNH
*/
import java.awt.*;
import javax.swing.*;
public class MultilineJOptionPane {
public static void main( String args[] ) {
JFrame frame = new JFrame( "just a frame" );
frame.setSize(50,50);
frame.show();
String s =
"The first line of text, five to follow...\n"
+ "A second line of text,\n"
+ "and the third,\n"
+ "fourth,\n"
+ "and fifth line of text. Click ok to exit.\n"
;
JOptionPane.showMessageDialog( frame, s );
System.exit( 0 );
}
}
--
Summary: Swing JOptionPane and multiline texts
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19860
[Bug AWT/19861] New: Swing JOptionPane without parent frame
The following testcase shows a (subtle) problem in the Swing rendering strategy.
A JOptionPane dialog without any parent works fine, but a JOptionPane
attached to a non-showing parent (e.g. JFrame) fails with an
IllegalComponentStateException. Because the Exception blocks the Swing
redraw thread, there is no way to recover from the illegal state.
(both dialog windows work fine under JDK 1.4.2, not tested with other versions).
/* NoParentJOptionPane.java
*
* demonstrates GCJ doesn't like dialogs without visible parents...
*
* (C) 2005 FNH
*/
import java.awt.*;
import javax.swing.*;
public class NoParentJOptionPane {
public static void main( String args[] ) {
String s = "Testing JOptionPane w/o parent...";
System.out.println( "The first call works: null parent:" );
JOptionPane.showMessageDialog( null, s );
// JDK1.4+ runs this, gcj complains about:
// java.awt.IllegalComponentStateException: component not showing
// at java.awt.Component.getLocationOnScreen()
// at javax.swing.SwingUtilities.convertPointToScreen(java.awt.Point,
java.awt.Component)
// at javax.swing.SwingUtilities.convertPoint(java.awt.Component, int, int,
java.awt.Component) (/usr/lib/lib-javax-swing.so.0.0.0)
// ...
JFrame frame = new JFrame( "just a hidden frame" );
System.out.println( "The second call is broken: frame parent" );
JOptionPane.showMessageDialog( frame, s );
System.exit( 0 );
}
}
--
Summary: Swing JOptionPane without parent frame
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19861
[Bug AWT/19862] New: Swing JTextField fails with StringIndexOutOfBoundsException
Entering text into a JTextField fails with an StringIndexOutOfBoundsException, triggered by a problem in GapContent or AbstractDocument.getText(). Tested with gcc-4.0-20050130 snapshot and a current (2005.02.09) cvs checkout of gui-branch-20040128: java.lang.StringIndexOutOfBoundsException at java.lang.StringBuffer.substring(int, int) (/usr/lib/libgcj.so.6.0.0) at javax.swing.text.GapContent.getString(int, int) (/usr/lib/lib-javax-swing.so.0.0.0) at javax.swing.text.AbstractDocument.getText(int, int) (/usr/lib/lib-javax-swing.so.0.0.0) at javax.swing.text.FieldView.getPreferredSpan(int) (/usr/lib/lib-javax-swing.so.0.0.0) Testcase attached. Note that the calculator functionality is stripped off to make the testcase shorter. (This is slightly unfair for gcj, because the expression parser does work with gcj.) -- Summary: Swing JTextField fails with StringIndexOutOfBoundsException Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19862
[Bug AWT/19862] Swing JTextField fails with StringIndexOutOfBoundsException
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 17:43 --- Created an attachment (id=8158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8158&action=view) testcase Just compile the class, then try entering an expression into the JTextField on the bottom of the main window and press or press the button. Note that the program also triggers a few other bugs; it can be tricky to tranfer the keyboard focus to the textfield in the first place -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19862
[Bug SWING/19863] New: Swing JMenus appear at wrong locations
On my computer, JMenus and especially nested JMenus appear on wrong locations, sometimes shifted right across the screen. Tested with gcc-4.0-20050130 snapshot and current cvs gui-branch-20050128 checkout (as of 2005.02.09). Note: this problem may be WindowManager dependent; I used ctwm on XFree 4.3. Testcase: please compile and run the program I submitted for bug 19862 (InteractiveCalculator.java) and try the menus. The problem also concerns JPopupMenus, for a testcase see the program I attached to http://gcc.gnu.org/ml/java/2005-02/msg00016.html. -- Summary: Swing JMenus appear at wrong locations Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: graydon at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19863
[Bug AWT/19880] New: Frame.setIconImage broken
It seems that Frame.setIconImage() is broken in current gcj-gui-branch-20050128, fresh cvs checkout on 20050209. Seems to be a regression, because the same code used to work (at least, didn't die instantly, never really tested to iconify the windows) under gcc-4.0-20050130 snapshot. Testcase attached; I create two windows to allow easy testing whether the call fails due to Toolkit initialization problems (showing the Frame first should ensure that Image loading works). However, both variants fail with for the gui branch. -- Summary: Frame.setIconImage broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19880
[Bug AWT/19880] Frame.setIconImage broken
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-10 20:50 --- Created an attachment (id=8163) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8163&action=view) testcase Note that you also require an image to be loaded. I attach 'jfig.gif' (64x64 gif) as a demo, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19880
[Bug AWT/19880] Frame.setIconImage broken
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-10 20:51 --- Created an attachment (id=8164) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8164&action=view) demo icon image -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19880
