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.

Bug 47290 - Use font style & color to indicate documents modified, read only
Summary: Use font style & color to indicate documents modified, read only
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: PLAN, UI
: 44592 58049 (view as bug list)
Depends on: 175546 171428 199007
Blocks: 50354
  Show dependency tree
 
Reported: 2004-08-17 03:27 UTC by _ tboudreau
Modified: 2011-06-02 22:22 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
editor tabs screen shot (9.67 KB, image/png)
2008-05-21 11:38 UTC, Stanislav Aubrecht
Details
Screen shot of NB with mac-specific patches (474.37 KB, image/tiff)
2008-05-21 14:32 UTC, _ tboudreau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2004-08-17 03:27:48 UTC
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
Comment 1 Jan Chalupa 2004-11-01 16:50:39 UTC
Re-assigning Tim's issues to Dafe.
Comment 2 David Simonek 2005-05-09 11:50:06 UTC
...possibly into 4.2.
Comment 3 Stanislav Aubrecht 2008-05-21 11:38:01 UTC
Created attachment 61669 [details]
editor tabs screen shot
Comment 4 Stanislav Aubrecht 2008-05-21 11:39:54 UTC
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
horizontal space.

reassigning to our hie guru for evaluation
Comment 5 jrojcek 2008-05-21 12:50:08 UTC
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.
Comment 6 _ tboudreau 2008-05-21 14:31:26 UTC
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 
mac editors.

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?
Comment 7 _ tboudreau 2008-05-21 14:32:22 UTC
Created attachment 61685 [details]
Screen shot of NB with mac-specific patches
Comment 8 Stanislav Aubrecht 2008-05-21 14:44:01 UTC
what should i be looking at in that screenshot? looks like a regular mac os l&f to me....
Comment 9 _ tboudreau 2008-05-22 03:31:17 UTC
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.
Comment 10 _ tboudreau 2008-05-22 03:34:59 UTC
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.
Comment 11 jrojcek 2008-05-22 14:50:52 UTC
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?
Comment 12 _ tboudreau 2008-05-25 19:51:51 UTC
"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).

Comment 13 mslama 2009-08-10 14:46:50 UTC
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.
Comment 14 Jesse Glick 2009-08-10 16:10:11 UTC
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.
Comment 15 Jesse Glick 2009-08-10 16:10:26 UTC
*** Issue 58049 has been marked as a duplicate of this issue. ***
Comment 16 _ tboudreau 2009-08-10 17:00:53 UTC
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.
Comment 17 Ondrej Langr 2009-08-12 14:38:15 UTC
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).
Comment 18 Jesse Glick 2009-08-14 17:39:57 UTC
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.
Comment 19 Jesse Glick 2009-08-14 18:49:04 UTC
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.
Comment 20 Quality Engineering 2009-08-15 06:29:07 UTC
Integrated into 'main-golden', will be available in build *200908150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/7b7d80faf360
User: Jesse Glick <jglick@netbeans.org>
Log: Working on #47290: better impl of nb.tabnames.html=true.
Comment 21 Ondrej Langr 2009-08-17 13:39:03 UTC
> 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,
for example.
Comment 22 Jesse Glick 2009-08-17 23:53:43 UTC
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
Comment 23 Quality Engineering 2009-08-21 06:15:36 UTC
Integrated into 'main-golden', will be available in build *200908210201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e63e21a0d1d0
User: Jesse Glick <jglick@netbeans.org>
Log: Working on #47290: better impl of nb.tabnames.html=true in popup switcher.
Comment 24 Antonin Nebuzelsky 2009-09-03 16:19:53 UTC
> 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.
Comment 25 Jesse Glick 2009-09-03 16:23:38 UTC
OK, I can do it.
Comment 26 Jesse Glick 2009-09-03 22:18:23 UTC
core-main #9a7cd7835265

Now on by default, but can still be turned off with -J-Dnb.tabnames.html=false if there are problems or for purposes of
comparison.

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
test with.
Comment 27 _ tboudreau 2009-09-03 22:31:03 UTC
Re color issues:  VCS annotations should be using UIManager keys for their markup, e.g.
<font color="!controlShadow">
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).
Comment 28 Jesse Glick 2009-09-03 23:13:20 UTC
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).
Comment 29 Quality Engineering 2009-09-07 17:04:52 UTC
Integrated into 'main-golden', will be available in build *200909071104* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/9a7cd7835265
User: Jesse Glick <jglick@netbeans.org>
Log: Issue #47290: enable italic & bold rendering of document r/o and modified status.
Comment 30 Jesse Glick 2009-10-20 17:17:17 UTC
*** Issue 44592 has been marked as a duplicate of this issue. ***
Comment 31 _ tboudreau 2011-06-02 08:25:27 UTC
> UIManager keys are probably not enough here, since we need blue, green, maybe
> others.

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.
Comment 32 Jesse Glick 2011-06-02 17:42:50 UTC
(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.
Comment 33 _ tboudreau 2011-06-02 19:37:37 UTC
Probably only really interesting to people who prefer and routinely use dark themes.
Comment 34 Jesse Glick 2011-06-02 19:51:17 UTC
(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.
Comment 35 _ tboudreau 2011-06-02 22:22:42 UTC
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).