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.
Summary: | Change default for Show File Extensions to true | ||
---|---|---|---|
Product: | platform | Reporter: | dmartin01 <dmartin01> |
Component: | Window System | Assignee: | issues@platform <issues> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | asunhachawee, dsimonek, jchalupa, jglick, jmzourek, jskrivanek, lhasik, mmirilovic |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 12641, 27444 | ||
Bug Blocks: |
Description
dmartin01
2004-01-15 23:57:37 UTC
Though it would be nice to have a fix to issue 12641 (though not as convinced as issue 27210), I don't think these fixes need to coincide. Raising priority to get this on the radar for next release (3.6?) Notice, at this date, it is essentially #3 in the ranking of votes (since other issues that have higher votes like issue 21425 and issue 22625 have already been addressed). Also here's link to the discussion on nbui: http://www.netbeans.org/servlets/ReadMsg?msgId=659218&listName=nbui This issue has implications for icons as well, so the sooner we can commit to a release to fix it by, the better (we need to tap into visual design and probably HIE/UI resources) Dafe, do you think it would be possible to make this change between Beta and FCS of 3.6? CC'ing Honza and me, because implementing this "feature" our GUI tests will broken. I object to this change. We're past the feature freeze for 3.6 and this is an enhancement, not a bug fix. As Marian pointed out, the change would break many of the existing UI tests, which were considered frozen for 3.6 too. Just wondering - what is our priority? A good IDE with good features or a set of passing tests? I would vote for the first option. Tests should be fixed quite easily (I know, golden file based tests not so easily). Also I object the opinion it is an enhancement. It is just a change in default settings, nothing more. IMHO very far from new feature implementation. From core dev point of view, techically it's not a problem to change the defaults, it's really minimal change - although it might break some dependencies (anybody depends on anything in this world, right?) it will have minor impact I think. However requests that violate our schedule planning are frequent these days, and together they create uplanned extra burden for developers, which *will* lead to more buggy 3.6 release than it could be. What is the estimated effort for making this change (including dependencies)? If its 3 days or less I would vote for this change. Estimated effort for actually making the change (not including updates to GUI-mode tests) is roughly nothing: in DataNode.java where it says /** should file extensions be displayed? */ private static boolean showFileExtensions = false; change 'false' to 'true'. :-) We have had a GUI-visible option to show file extensions for many releases now (perhaps going back to 3.0, I don't remember), and AFAIK it has been a supported setting at least for the last few releases. This is only about changing the default. If there were some problems that manifested themselves with Show File Extensions on, they *should* have been found and fixed years ago, since the option is supported. And I do in fact remember finding, reporting, and fixing or confirming fixes of some minor problems associated with showing file extensions - a couple of years ago or more. The real questions are: 1. Have so few people ever turned this setting on that it has just not gotten adequate real-world testing to be on by default for a release? I am guessing no, that quite a lot of people have found the option where it is hidden in the Options dialog and turned it on and left it on and not had problems; but I'm not sure. 2. Are there other aspects of our current UI that make it look really bad to show file extensions, embarrassing enough to offset the positive impact of the change for most users? E.g. the fact that you cannot rename file extensions currently, so F2 shows just the base name (issue #27210); or showing too long of a display name in the Explorer and/or Editor esp. when also using a VCS system with verbose status annotations; etc. Re. issue #12641, I think showing extensions by default improves the situation a bit. With extensions hidden by default, you might type in "page.jsp" in the New wizard and you will see "page.jsp" in the Explorer as expected and may be very confused later on when you see "page.jsp.jsp" on disk. With extensions shown by default, you would immediately see "page.jsp.jsp" in the Explorer and realize that something was wrong and hopefully infer that you should have typed only "page" in the New wizard. The effort on the QA side would mean reviewing existing UI tests (hundreds of them) and updating all references to node display names (plenty). This is definitely something we haven't planned to do this late in the game. I'm wondering why this becomes such an urgent issue now. The file extensions have been off by default for 5 subsequent releases or so. As Jesse mentions, users can easily configure this. If they prefer to see the extensions, it's a simple one-time change. Don't get me wrong. I'm not saying that changing the default value is a bad idea. I just don't want to do that now -- 4 weeks after the UI freeze for 3.6. I'll leave the question as to whether this should be fixed for NB3.6 between the rest of the team (marketing, eng, qa), though of course my position as HIE is that it should be, as resources allow =) To address some of Jan C's comments though: No, this option is *not* easy to find.. as Jesse Glick mentioned it is "hidden". I have most recently seen Sun Java Studio engineers who couldn't find this option, embarassingly in front of customers who were asking why isn't it on by default. It's yet another small barrier that turns ppl away from NB.. Well, the default is changed in the trunk (as of build system merge), and no one has complained loudly so far... *** Issue 40898 has been marked as a duplicate of this issue. *** *** Issue 40898 has been marked as a duplicate of this issue. *** Verified. This issue had *8 votes* before move to platform component |