See issue 23806 for details - this is already implemented as a
hack, needs API in the form of
TopComponent.getHtmlDisplayName(). It is quite useful. To try
it, run with -J-Dnb.tabnames.html=true
Re-assigning Tim's issues to Dafe.
...possibly into 4.2.
Created attachment 61669 [details]
editor tabs screen shot
i've attached a sample screenshot showing what the editor tabs look like then.
i think this enhancement can be even merged with removing removing file extensions from editor tabs to save even more
reassigning to our hie guru for evaluation
I'm not sure about the bold font. I would suggest to do some visual change in the close button in case of modified file.
Reassigning to Ruda to evaluate it while working on the tabs update which would happen as part of the Mac OS X L&F related work.
Is there some Mac OS ui update planned? I have some local patches you might be interested in - not finished yet, but uses iTunes-style striped
backgrounds on trees and tables and proper gradients for selected items - and it gets all of these from the OS (they use a clever hack of using Border
instances to paint backgrounds, and you can get them from UIManager).
Also have patches to put the "modified" dot in the close button when a modified file is selected, and show the selected file's icon in the titlebar as do other
I was also thinking of using segmented mac buttons as cell renderers for the tabs - should look very mac-like, and the current rounded look is getting
kind of dated (Panther-esque).
I'll attach a screenshot. Is there an issue for Mac-related UI updates?
Created attachment 61685 [details]
Screen shot of NB with mac-specific patches
what should i be looking at in that screenshot? looks like a regular mac os l&f to me....
Note the Mac-specific gradient backgrounds on the selection in trees and lists and the striped background on them. That's the reason for the screen shot.
More to do still, of course.
Jano, re using bold font to indicate modification: I used a Mac for 3 years before I learned why sometimes the red close button in editors had a little dot in it
- and I only learned it by reading about it. So I think that may be one case where Apple made a choice that was a little too subtle. I do like the fact that if we
do not change the font style, it does not require tab resizing (although we could easily fix it so that didn't have to happen).
The nice thing about bolding the text is that it's instantly learnable, and will be visible in the tab selection popup as well.
That is very subjective IMO:
I personally got the meaning of the close button indication on Mac pretty quickly. ;-)
The bold font name indicates the selected tab in Visual Studio. I don't say it's the right thing to do. If the bold font was commonly used for modified files,
then no problem. The standard symbol seems to be the asterisk. So why do we want to change it?
"I don't say it's the right thing to do"
Did you mean that or that you don't say it's *not* the right thing to do?
The use of the * dates back to text-only apps like WordStar, WordPerfect and Turbo-Pascal in the 80's. While it is the convention, if we have an instantly
learnable and more usable alternative, I don't think there is much value in sticking with convention. Here are the reasons using a bold font is more usable:
- User does not have to scan the tab text to determine modified status - a simple glance is enough
- Less tab resizing which shifts tabs around whenever the modified status changes (should be a 1 to 2-line modification to the TabControl to have it
always compute tab widths based on the bold font size, even when bold is not used - I'd suggest making this settable on TabControl so it is not done
where not needed).
Colors are now used to indicate VCS status. Passing to Ondra to define suitable way if appropriate. It is necessary to
consider all combinations to avoid clashes.
There is no use of color except that currently the impl grays out r/o docs in addition to putting them in italic; I have
not seen any poor interactions with VCS (since r/o files are generally not under version control to begin with, rather
in src.zip etc.) but this could be made optional or compose with other colors.
More discussion in issue #58049. FWIW I have used this mode for years without problems and hate the standard mode.
*** Issue 58049 has been marked as a duplicate of this issue. ***
Yes, to make this crystal clear, it has nothing to do with color. This issue is simply:
- Show read-only tab names in italic
- Show modified tab names in bold
- No change for read-write, unmodified files
To see it in action, run NB with -J-Dnb.tabnames.html=true
Hard to believe it takes 5 years to do this.
Obviously, this is a controversial issue and there are no "standards". No matter whether we'll apply this change or not,
there'll be someone unsatisfied.
Visual Studio uses bold, Eclipse asterisks and IntelliJ no indication at all. Yes, asterisk is a hack dated back to IT
stone age, but it's widely recognized among developers. 'Bolding' on the other hand breaks the 'status quo', but should
be pretty easy to get.
As of now, the switch works incorrectly as in all other UI except for document tabs, modified files are still listed
with asterisk while in tabs they're displayed in bold. To make it more complicated, bold is often used to indicate the
active tab/file. This applies to document dropdown (on the right in tabs bar), Documents window and quick documents
switch available through Ctrl + Tab only.
From my viewpoint, breaking the link with stone-age makes sense, even though this may not be a popular change for
everyone at first.
Let's fix the issues mentioned above (use bolding also in documents window and documents dropdown) and get this into
trunk reasonably early in 6.8 milestones. This way, we'll get feedback from more people then those involved in this
discussion (and thus naturally biased).
On JDK 5/Ocean/Linux with no special flags, I see boldface used in the document dropdown for "active file", but not in
the quick switcher nor in the Documents window. Probably there is little value in this usage of boldfacing (if you
intend to switch documents then the active document is the _least_ relevant entry in the list) and it could just be
disabled if nb.tabnames.html=true.
In core-main #7b7d80faf360 I
1. Removed the hack from core.windows and put the impl in DataEditorSupport where it belongs. (Perhaps the hack was
written before messageHtmlName was created?)
2. Added tooltips to editor panes when modified or r/o in nb.tn.html mode.
3. Switched to plain <i>, no extra grey <font>, for r/o docs. Can consider adding back in greyness; would anyway be
overridden by any VCS status coloration, though that is unlikely to ever happen for a r/o file.
4. Fixed document dropdown in o.n.swing.tabcontrol to not specially mark the active file in nb.tn.html mode. Probably
needs a bit more work as it blots out all HTML in the list view selection which seems unnecessary.
The flag is still off by default.
Integrated into 'main-golden', will be available in build *200908150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: Working on #47290: better impl of nb.tabnames.html=true.
> Probably there is little value in this usage of boldfacing (if you
> intend to switch documents then the active document is the
> _least_ relevant entry in the list) and it could just be disabled
> if nb.tabnames.html=true.
The active document itself is not very relevant, but the position of the document searched for relatively to the active
document can be important for quick navigation (is it before or after the current document), especially as it is the
only way how to find it in tabs (left/right from the active tab). So let's keep some indication .. we can use underline,
Underline looks weird to me, but ← seems to work well. (Still not sure what the value of marking the active tab is,
since documents are not shown in the switcher in the same order they are shown in the tab row anyway... but that's a
separate issue.) Also disabling IMHO unnecessary suppression of HTML in selected item (again only with nb.t.h=true).
Tested on Ubuntu using both JDK 5/Ocean and JDK 6/GTK. core-main #e63e21a0d1d0
Integrated into 'main-golden', will be available in build *200908210201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <firstname.lastname@example.org>
Log: Working on #47290: better impl of nb.tabnames.html=true in popup switcher.
> Let's fix the issues mentioned above (use bolding also in documents window and documents dropdown)
> and get this into trunk reasonably early in 6.8 milestones. This way, we'll get feedback from more people then those
> involved in this discussion (and thus naturally biased).
Agreed to turn this new behavior on by default now.
Jesse or Marek, please do it.
OK, I can do it.
Now on by default, but can still be turned off with -J-Dnb.tabnames.html=false if there are problems or for purposes of
Cleaned up a number of module-specific problems in the fix for #171428, such as inconsistent display from *.form,
*.properties, and persistence.xml files.
One nit I know about: on XP L&F (or is it Win95 L&F?) the selection background is dark blue, so colored labels (e.g.
VCS-modified files in light blue) are harder to read while they are selected in the Ctrl-TAB switcher. Of course as you
cycle through the entries you can see the unselected ones more clearly. SwitcherTable.stripHtml could be used again if
necessary, though that then looks ugly on boldface/italic labels. The background in GTK L&F is a light orangish color
(at least on my Gnome desktop) so any darkish text shows up fine - the problem is only when the background is dark,
because you need to invert the color of text to make it look good. I do not have newer versions of Windows, or a Mac, to
Re color issues: VCS annotations should be using UIManager keys for their markup, e.g.
and so forth, as supported by org.openide.awt.HtmlRenderer.
Probably there should be key/value pairs installed by core.swing.plaf which will contrast properly with the current look
and feel, whatever it is.
If the VCS modules are hard-coding the colors used, file a bug there to switch to UIManager keys instead - then any
contrast issues are easy to fix on a per-L&F basis.
If the issue is just with selection, you might want to turn on stripping of font color tags in the popup switcher for
selected items only (we do something similar in explorer already for this reason).
UIManager keys are probably not enough here, since we need blue, green, maybe others. Anyway picking different colors,
even per L&F, would not suffice; the issue is that the selection background is dark as opposed to the normal light
background. No foreground color would look great with both. The L&F switches the foreground color for a selection if
HTML is not used.
The issue is just with selection. With nb.t.h=false, we strip off all HTML, which of course addresses the color issue. I
disabled this for nb.t.h=true because it looks bad with bold and italic labels: they switch from some special style to
plain style and back again as the selection passes over them.
Probably some complicated fix is possible, e.g. searching the text for <font> tags and editing the color to a
complementary color iff in selection mode and the background color for the current L&F is darker than some threshhold. I
don't have the expertise to do that, and would anyway need a broader range of operating systems to test on (since I
cannot simulate non-free L&Fs on Linux).
Integrated into 'main-golden', will be available in build *200909071104* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: Issue #47290: enable italic & bold rendering of document r/o and modified status.
*** Issue 44592 has been marked as a duplicate of this issue. ***
> UIManager keys are probably not enough here, since we need blue, green, maybe
We define custom UIManager keys for various colors in core.swing.plaf - it would be harmless to add more.
FWIW, I did some code a long time ago in that module for doing exactly this sort of thing - programmatically finding a color which contrasts sufficiently - look around somewhere for RelativeColor, which lets you install a UIManager value which computes its value based on the look and feel's color value for something else (e.g. control, textText, etc), and attempts to retain the requested hue.
So it's definitely doable if someone wants to do it.
(In reply to comment #31)
> programmatically finding a color which contrasts sufficiently
Might be useful for the "complicated fix" mentioned in comment #28, particularly if this were implemented in HtmlRenderer. Then it would suffice in the tab switcher to just never strip HTML when nb.t.h=true, since even colored text would be guaranteed to be readable while selected. I do not know if it is really worth the trouble, though.
Probably only really interesting to people who prefer and routinely use dark themes.
(In reply to comment #33)
> only really interesting to people who prefer and routinely use dark themes
Unfortunately the default L&F for some Windows variants makes some text produced by NB in this context (e.g. tab of VCS-modified file) hard to read.
My solution to this was to write contrib/tanui (which makes metal tolerable) and manually force NB to use metal (IMO we should block GTK L&F - it's very badly behaved still and AFAIK unmaintained).