Community
Participate
Working Groups
I was in the debug perspective and had most of the debug views open, but I was wondering what else was available. It would be nice if the entries under the Debug category were hidden or displayed in gray text if they were already visible.
I assume you mean any view that's open, not just debug views...
We don't want to hide or remove the open views from the view menu. People, particularly people who cannot use the mouse, need to be able to use this to show existing views as well. It might be useful to indicate which ones are already shown, e.g. bold the ones not shown, as is done for editor and view management. MenuItem doesn't currently support this, but this could be done in the Other... dialog currently. Care to supply a patch?
<B>PLEASE! NOT MORE BOLD!</B> Menuitem supports Checkbox style, but then you'd have to allow the menuitem to close the view, which is not a bad idea.
That's not the desired behaviour. If an existing view is selected, it should be shown, not closed.
Reassigning bugs in component areas that are changing ownership.
Created attachment 48856 [details] gray_out_open_views.diff Here is a little patch to improve the Show View Dialog. It adds an IColorProvider to the current LabelProvider to gray out all open views of the workbench. Hope this makes some people happy :)
Ben: I wonder if there is a potential leak as you are not disposing the color. Acquiring a system color might be better approach like in: Display.getCurrent().getSystemColor(SWT.COLOR_GREY) .SWT.COLOR_TITLE_INACTIVE_FOREGROUND may be even better as it would be a system color. And it could be called directly in the in setforeground...and would not need to be cached. Those colors would not (rather should not) have to be disposed, AFAIK. This would give something like: + public Color getForeground(Object element) { + if(element instanceof IViewDescriptor) { + IViewPart part = PlatformUI.getWorkbench().getActiveWorkbenchWindow(). + getActivePage().findView(((IViewDescriptor) element).getId()); + if(part != null) { + Color color = Display.getCurrent().getSystemColor(SWT.COLOR_TITLE_INACTIVE_FOREGROUND); + return color; + } + } + return null; + } Just some thoughts. I did not make any tests, just looked at you patch.
Caching would not be abig deal anyway, and may be desirable... but using a system color, and delaying acquiring it as late as possible might be better
Sure, you're right. I forgot to use the system colors because I was so happy that i found out how to set the foreground of non-TreeItems ;) An update of the patch has to wait, because I'm now at work. Maybe this evening I can provide a new one which uses the system color.
(In reply to comment #9) > Sure, you're right. I forgot to use the system colors because I was so happy > that i found out how to set the foreground of non-TreeItems ;) > An update of the patch has to wait, because I'm now at work. Maybe this evening > I can provide a new one which uses the system color. You may want to wait for Boris's input and not take my word for it anyway :-)
I'm afraid this will have to be a color that can be changed in the preferences (for accessibility). SWT.COLOR_TITLE_INACTIVE_FOREGROUND cannot be used because it is for titles, not items in a tree or table. For an example how to do this, see SearchLabelProvider.fPotentialMatchFgColor in JDT/UI. It is lazily created, properly disposed of, and appears in the preferences. I would also prefer that the workbench window is passed from ShowViewHandler through ShowViewDialog to ViewLabelProvider so that you don't have to use PlatformUI.getWorkbench() in ViewLabelProvider.getForeground().
Making this customizable for this alone seems overkill. Can we generalize the problem such that we're defining a systemwide "lo-light" color that can be used by any view/control/monkey to de-emphasize content?
(In reply to comment #12) Yes.
What a confusing bug report. Nick and I start talking about what the menus are supposed to do when I originally was discussing a dialog, not the Show View submenu. As far as accessibility, CTRL+F7 provides a way to get to already open views. As do assigning keybindings. I doubt anyone (intentionall) invokes Other... to activate an already open view. So anyway, can the Window -> Show View -> ... submenu be improved in some way too? Maybe a preference that disables already opened menuitems. There is no SWT support for colors or fonts on menus :-(.
(In reply to comment #12) > Making this customizable for this alone seems overkill. Can we generalize the > problem such that we're defining a systemwide "lo-light" color that can be used > by any view/control/monkey to de-emphasize content? Can you just take the control's FG color, and blend it 25% with the background color? That should work regardless of system colors.
> Can you just take the control's FG color, and blend it 25% with the background > color? That should work regardless of system colors. Good idea. 60% foreground and 40% background worked best for me. Fix released to HEAD >20060829.
reopening so that I can re-assign
Benjamin, please verify this bug during our 3.3 M2 test pass. Thanks!
[I20060920-0010] Verified on Gentoo Linux / GTK
