This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Please look the screenshot attached. You will see that it's not more possible to see the amount of memory. It's hidden by a black rectangle. The size of the black rectangle is depending of the size of the progression bar on his left.
Created attachment 12171 [details] how much memory is used by NetBeans ? Seems that netbeans team want to hide that information ;-) It seems censured .
I guess it is probably about some color used as backgrou (which is black in this moment)... passing first to our UI to eval whether we affect it.
AFAIK winsys don't affect this. Passing to Jesse, he did some modifications that may cause this. (Hrebejk said so :-)
Probably a Win L&F issue - on Metal it shows gray background, light blue progress bar, black text, which is fine. Need to use different UIManager colors, probably. Tim do you feel like tweaking this, since you have an XP box and I don't? It's in org.openide.actions.GarbageCollectAction. Not very complicated: private static final class MemButton extends JButton /*...*/ { // ... protected void paintComponent(Graphics g) { Dimension size = getSize(); g = g.create(); g.clearRect(0, 0, size.width, size.height); g.setColor(UIManager.getDefaults().getColor("Button.focus")); g.fillRect(0, 0, (int)(size.width * proportion), size.height); super.paintComponent(g); } }
*** Issue 36711 has been marked as a duplicate of this issue. ***
Created attachment 12413 [details] My first patch, I only took the old file
Created attachment 12414 [details] only set the Background Color to SystemColor.control
My first small changes to the "Big one"
Uh, STARTED is probably what you meant, not WORKSFORME which means that a bug in unreproducible.
martins - Please don't reformat code in a patch. The patch should show only lines that you actually needed to change. Otherwise it is impossible to tell what it is doing (and if applied it would screw up cvs annotate, etc.). Details: http://www.netbeans.org/community/contribute/patches.html Also be very careful with UIManager.get* calls - remember that they can always return null, and on some L&Fs such as WinXP and GTK, they *do* return null when you least expect it. [BTW you need to add yourself as a CC to an issue report whenever you add a comment (or attachment etc.) to it, unless you are the reporter or it is assigned to you. Otherwise you will never see anything that happens to the issue.]
Still broken on Windows Classic L&F. Bumping prio to P2, it must be fixed for the release. I don't quite understand the motivation for the changes to GarbageCollectAction. The standard Memory toolbar provides two actions, MemoryMeterAction which displays the heap status (ok, the numbers are shown in the tooltip only), and the GarbageCollectAction, which used to be a simple button only, but now it duplicates the graphical information provided by MemoryMeterAction (and does it wrong for most Windows users). I don't see any reason to display the same graphical info twice, so either the recent changes in GarbageCollectAction should be reverted (as I understand it, it's basically what Martin Schlegel's patch does), or GarbageCollectAction should be fixed and replace the MemoreMeterAction completely.
Well I don't have a Win machine to even develop a fix on, so unless a trimmed version of martins' patch becomes available quickly that someone else with a Win machine can verify, I will probably just back out the new GCA appearance (except perhaps with an optional system property) for 3.6 and leave it for later.
Fixed in trunk. Checking in Bundle.properties; /cvs/openide/src/org/openide/actions/Bundle.properties,v <-- Bundle.properties new revision: 1.95; previous revision: 1.94 done Checking in GarbageCollectAction.java; /cvs/openide/src/org/openide/actions/GarbageCollectAction.java,v <-- GarbageCo llectAction.java new revision: 1.19; previous revision: 1.18 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans. org)
Verified on Win NT4 and W2k. Thanks, Tim. However, two minor issues still persist: 1. The GarbageCollectAction presenter resizes with the width of the displayed text. In my case it displayed something like "9.3/23.9Mb" then, it jumped to "10.1/23.9Mb" while resizing to accomodate the wider text. Should the memory heap size grow further (e.g. "100.0/128.0Mb", ok I know 96 megs is the default now), it probably wouldn't fit into the Memory toolbar space. IMO, the width of the button should be fixed and wide enough to accomodate text in the "999.9/999.9Mb" format. 2. As mentioned earlier, there are currently two action presenters -- MemoryMeterAction and GarbageCollectAction displayed side by side when the default Memory toolbar is on. This can be easily customized, of course. Nevertheless, only one of them (GarbageCollectAction?) should be on by default.
Re. #2 - I will fix shortly, just need to check it in. Re. #1 - actually the code *does* set the size of the component to whatever is needed to display 999.9/999.9Mb. Did it actually fail to work for you, or are you just presuming it wouldn't? I usually keep the action in my menu bar, not toolbar, but I am not aware of any problem.
For #2: committed Up-To-Date 1.54 core/ui/src/org/netbeans/core/ui/resources/layer.xml
Re: "actually the code *does* set the size of the component to whatever is needed to display 999.9/999.9Mb" You may be right, there seems to be just enough space to display "999.9/999.9Mb" without shuffling the toolbars. However, the border (not sure if it's the actual border of the component) does resize with the length of the text. It's always only that wide to display the currently displayed text and resizes when the length gets bigger or smaller. I'd prefer the border width to remain constant.
True, would be preferable to have a fixed border width.
Opened separate issue #39318 to track Honza's #1.
closed