--- Comment #1 from roman at kennke dot org 2008-02-26 08:56 ---
Hi,
When using java.awt.image.BufferedImage; the corresponding program fails to
run
when no X display is available although it does not make use of the display.
I've tried to set -Djava.awt.headless=true
--- Comment #4 from roman at kennke dot org 2006-12-14 08:47 ---
(In reply to comment #3)
(In reply to comment #2)
I disagree. TimesRoman etc are not logical font names, but 'physical' font
names. (Logical names are Serif, SansSerif, Monospaced, Dialog, and
DialogInput
--- Comment #4 from roman at kennke dot org 2006-12-08 22:36 ---
I agree that theoretically there should be more syncs on methods that walk the
hierarchy. Let me think about this a little and play with Sun and IKVM. I think
I remember that there was a good reason to do so. Now when you
--- Comment #2 from roman at kennke dot org 2006-10-30 20:58 ---
That's a dupe.
*** This bug has been marked as a duplicate of 28933 ***
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #2 from roman at kennke dot org 2006-10-30 20:58 ---
*** Bug 29346 has been marked as a duplicate of this bug. ***
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #1 from roman at kennke dot org 2006-10-23 17:18 ---
Yeah, these are similar to the NPEs that we have seen in JTree lately. I'll
look at those and fix them.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #16 from roman at kennke dot org 2006-10-19 09:09 ---
Ok thanks. That is a similar NPE that I had before. Somehow the JTree code
tries to pass a null Rectangle into JComponent.repaint(). This leads (rightly
so) to an NPE (the JDK throws NPE in such a case too). So I think I
--- Comment #10 from roman at kennke dot org 2006-10-18 15:25 ---
Hi Norman,
The NPE seems to be caused by unnecessary code in JTree.TreeSelectionRedirector
that repaints although it most likely should not. That's probably easy to fix.
I am not sure about the resetting. I will put
--- Comment #2 from roman at kennke dot org 2006-10-18 16:06 ---
Confirmed. I recently worked in this area. Will fix it asap.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #12 from roman at kennke dot org 2006-10-18 16:09 ---
Thanks David. I can see the problem now. I think I know what the problem might
be.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #4 from roman at kennke dot org 2006-10-18 16:22 ---
The above patch fixes the situation for me. Are you able to retest, or should I
close the bug for now?
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #4 from roman at kennke dot org 2006-10-16 10:13 ---
The Window resizing issue is solved. What remains is the inability to close a
window by pressing the X button of the window manager decorations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29448
--- Comment #3 from roman at kennke dot org 2006-10-16 10:42 ---
I also get this when running with LANG=C:
(after doing
./autogen
./configure --with-escher=/home/roman/workspace/escher-0.2.3 \
--prefix=/home/roman --with-ecj --with-glibj=both \
--with-vm=/home/roman/bin/jamvm --enable
--- Comment #2 from roman at kennke dot org 2006-10-13 12:41 ---
Even worse, it seems we can't close Windows by clicking the X button of the
window. We can't release that crap ;-) I suspect some problems in the event
dispatching code. I'll take care of it.
--
roman at kennke dot org
--- Comment #2 from roman at kennke dot org 2006-10-12 10:43 ---
Fixed in CVS HEAD.
--
roman at kennke dot org changed:
What|Removed |Added
Status
--- Comment #3 from roman at kennke dot org 2006-10-10 19:32 ---
I am sorry that these issues frustrate you that much. I think you face several
unrelated issues here, (a copyArea() bug, image handling bug and problems in
the JTree layout). I will try to look into these, but I'll create
: classpath
Version: 0.92
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: swing
AssignedTo: roman at kennke dot org
ReportedBy: roman at kennke dot org
BugsThisDependsOn: 28769
http://gcc.gnu.org/bugzilla/show_bug.cgi
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: awt
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at kennke dot org
BugsThisDependsOn: 28769
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29419
Product: classpath
Version: 0.92
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: awt
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at kennke dot org
BugsThisDependsOn: 28769
http://gcc.gnu.org/bugzilla
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #3 from roman at kennke dot org 2006-10-10 20:15 ---
Issues 1 2 and 4 seem to be solved already. There's still missing support for
custom tooltips.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #2 from roman at kennke dot org 2006-10-10 20:19 ---
AFAICS, this is fixed in CVS HEAD.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #2 from roman at kennke dot org 2006-10-08 21:36 ---
At the moment I can't get this thing to run. I always get a segfault here with
JamVM, and cacao doesn't work either. I strongly suspect a bug in the
JSplitPane UI. I am going to look into this asap.
--
http
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: classpath
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at kennke dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29345
--- Comment #1 from roman at kennke dot org 2006-10-04 13:21 ---
I should add that in the fresh ubuntu install I had no g++ package installed,
and after installing it the compilation worked. Also, I don't think that g++ is
needed in all configurations. configure should of course only
: UNCONFIRMED
Severity: normal
Priority: P3
Component: classpath
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at kennke dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29346
___
Bug-classpath
--- Comment #7 from roman at kennke dot org 2006-10-04 13:35 ---
I think this is fixed some time ago. Closing.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #2 from roman at kennke dot org 2006-08-16 19:34 ---
Should be fixed. Please retest and close.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #15 from roman at kennke dot org 2006-06-15 15:07 ---
Well, looking at the specs this behaviour isn't actually wrong. It only says
something about what happens (or rather should happen, so it's really only a
hint) when this flag returns true. It doesn't say that when it's
--- Comment #4 from roman at kennke dot org 2006-06-09 10:17 ---
Can you check if the mauve tests for the ElementBuffer are affected by your
patch? BTW, Lillian and Tony also did quite some work on the ElementBuffer
class. This class is very fundamental and unfortunately not at all
--- Comment #5 from roman at kennke dot org 2006-06-06 15:43 ---
Fixed in CVS.
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from roman at kennke dot org 2006-05-03 20:42 ---
So the implementation should be adjusted to cope with null icons. That sounds
logical. External code (in this case, LF impls) can set the icons to null,
which should still work.
--
roman at kennke dot org changed
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
roman at kennke dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #2 from roman at kennke dot org 2006-03-25 18:57 ---
On my machine the drawing problem is only visible for a very short period of
time, that is until the next repaint() is triggered by the caret updating
itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26839
: classpath
Version: 0.21
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: swing
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at kennke dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26368
--- Comment #1 from roman at kennke dot org 2006-01-18 10:27 ---
Created an attachment (id=10667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10667action=view)
Testcase for this bug
This demonstrates the problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25843
--- Comment #3 from roman at kennke dot org 2005-11-22 15:19 ---
I fixed this in CVS head by splitting the String up at \n boundaries and
creating multiple JLabels inside the JOptionPane.
--
roman at kennke dot org changed:
What|Removed |Added
--- Comment #27 from roman at kennke dot org 2005-11-10 15:56 ---
Ok I think I have solved part of the problem. What we did before when painting
overlapping components (like popupmenus over the GUI) is to paint all
components in the stack, from the bottom to the top, regardless
Product: classpath
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: awt
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at kennke dot org
http://gcc.gnu.org/bugzilla
--- Comment #25 from roman at kennke dot org 2005-11-09 15:30 ---
Subject: Re: JMenu layout problem with nested menus
Hi Norman,
Am Mittwoch, den 09.11.2005, 13:44 + schrieb hendrich at informatik
dot uni-hamburg dot de:
--- Comment #24 from hendrich at informatik dot uni
--- Comment #3 from roman at kennke dot org 2005-11-03 14:48 ---
Could you put together a small testprogram?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24651
___
Bug-classpath mailing list
Bug-classpath@gnu.org
http://lists.gnu.org
47 matches
Mail list logo
