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: | I18N - issue for source encoding setting | ||
---|---|---|---|
Product: | java | Reporter: | Masaki Katakai <masaki> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | jf4jbug, jglick, jrojcek |
Priority: | P2 | Keywords: | I18N |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Proposal for encoding note in project properties dialog |
Description
Masaki Katakai
2007-07-17 11:58:07 UTC
Tome, you've done the EncodingQuery and implementation in ant java projects, right? The issue has two parts, one is as designed and the second is already fixed. The first problem: Changing project encoding does not affect other existing projects, it affects the encoding in which the next project is created. This comes form the most used use case: developer creates all (or most of project) in the single encoding. So when the IDE is installed it creates project in UTF-8 (this is what we recommend) but the user can change this encoding to other (ISO-8859-2), next time (s)he creates a new project it already uses the ISO-8859-2 encoding. I am afraid that adding a new option for setting a default encoding will introduce a new UI somewhere in the advanced options which no one will find anyway. The second problem (probably the root problem): Project created in the NB 5.x used the default encoding, this was already changed, unfortunately after M10. The old project now uses fall back encoding which is the OS native encoding. > it affects the encoding in which the next project is
> created.
That's problem because the option setting UI is located on
project property dialog, not on global option dialog.
Users can not understand it will affect next created project setting.
If it will affect others, the setting UI should be provided on global
setting panel too. Only project specific settings are usually
located on project property dialog. I think many users will confused
by the UI.
I still think that it's better not to introduce the new UI and let the IDE to do this change automatically. For most of the users it will work out of the box and they will not need to change anything (they either do projects in UTF-8 or in other single encoding). If we introduce new UI they will probably not find it since it will be somewhere in the advanced options. Such a user will need to change the encoding everytime (s)he creates a project. But Jano (jrojcek) should decide this, he is an UI expert. lets keep in mind also that the new project encoding handling is meant for all projects that have implemented it, not just java project. it was based on requests from external users for a long time. and most project types of nb have implemented it. and its not just projects that have had this implemented but also related to files and then also how other operations handle determining encoding based on the project and file encoding. Since we are past feature freeze there is concern that changing this now could cause problems in that another set of code changes would be needed, specs would need to be rewritten, testing would need to be restarted, etc. Masaki, I can tell you more of the spec on this soon. of course your comments are appreciated; I just wanted to give a persective here in these comments. ken.frank@sun.com Thank you tzezula, I understand your concern but > options. Such a user will need to change the encoding everytime (s)he creates a project. I think these two scenarios (setting it on advanced option or on project property dialog each time) are not so painful tasks for users. > But Jano (jrojcek) should decide this, he is an UI expert. Yes, I agree. > lets keep in mind also that the new project encoding handling is meant for all projects that have I know. Was there any wrong points in my bug report? > Since we are past feature freeze there is concern that changing this now could cause problems > in that another set of code changes would be needed, specs would need to be rewritten, > testing would need to be restarted, etc. We know it will be painful to change such spec in future releases once it's implemented, documented and released. We now understand the current behavior will confuse users. So I think it's time to review the inconsistent UI and its behavior, and fix it. > Masaki, I can tell you more of the spec on this soon. Thank you. Any draft available? I'd like to review asap. >We now understand the current behavior will confuse users. So I think it's time to review
>the inconsistent UI and its behavior, and fix it.
This is what we don't know, I personally think that the current behavior is much less confusing than the proposed one.
As I explained above it fits to all common cases.
If we decide to change it we should do it as soon as possible because of the documentation and testing. I also think the current behavior is best. The IDE makes a reasonable guess as to which encoding you want for a new project; if it's wrong you can easily correct it and the IDE will remember that; you do not need to search through the Options dialog for a global setting (which many users might not even realize exists). Thanks jglick, But the problem is, the setting UI is provided on project property dialog now. Most users will think it's a setting for just current project, not for next created project. That's problem. Why the only encoding setting is affecting others? There is no such setting on project property dialog in 5.x. Will you confirm to Jano? HIE? Is it OK from the HIE point of view? Btw, Eclipse is providing two settings - global and project. The default value can be configured on global setting, project setting can overwrite the default value. Project setting will not affect others. The encoding is only for the selected project. It is used as a default initial value only, for the next project: whatever encoding you have last configured somewhere is used as an initial value since that is as good a guess as any. If it's wrong, just change it. If you had to go to the Options dialog to change the initial value for new projects you would in all cases be doing at least as much work as you do now, sometimes more, even if you knew this setting existed and where it was. Our general preference is to avoid having global options when they are not really necessary. By way of analogy: You are very lazy and like cookies. You keep a jar of cookies in the kitchen. While you are sitting in the living room reading, you get up to get a cookie from the kitchen. An hour later, you want another cookie, so you go into the kitchen again. The third time, you get annoyed, so you ask your friend to bring the cookie jar into the living room. You have one cookie. Later you move to the porch, and after a while you want a cookie. You go into the living room to get it. After a few times, you get annoyed and ask your friend to move the jar to the porch. Does this make sense? Of course not - it would be simpler to just bring the cookie jar with you whenever you get a cookie from somewhere else. That way, most of the time you would not have to get up just to get a cookie, but you do not have to do anything special to move the jar either, since you were up anyway. The risk is that even though usage is easier the way it is and the GUI is simpler, users expecting a global setting (e.g. because they are accustomed to Eclipse) will be persistently confused and irritated by the fact that there isn't one. There is of course no such GUI in 5.5 since file encoding was not really supported before 6.0. Hi jglick, Thanks for explaining. Yes, I understand your point. > and where it was. Our general preference is to avoid having global options when they are not really necessary. The problem is that few people are understanding the current behavior, Nobody can imagine it will affect at next time when they create a new project because - the setting UI on project property dialog - there is no information around the setting How do we tell this to users? How do we explain the encoding setting is completely different from other settings? If we continue using this, I want to ask you to consider these things, - describe the behavior on OLH I understand it will be done. but it would not be enough because many users do not read OLH carefully :( - How about putting some hints near the UI? "Encoding : UTF-8 (This setting will be the default when you create next project)" - or How about showing some useful message on status area of dialog when user select another encoding on the UI? All possibilities, but best left to Jano to comment. Masaki, yes there will be documentation, faq etc on this; it is a new feature, and its always been part of the plan to tell users about these new features and details, and that does include olh also. please remember that these features have been and are still in implementation phase and not all are done yet; and there are other details and things related to this than just project encoding. Please have a little patience. IMO the nb developers have done a very good job of meeting the requirements of this, based on the voc and votes of community members. I know your suggestions will be evaluated also as to showing info about this to users in the ui. ken.frank@sun.com For users who always use one encoding, the current behavior should be okay. A global setting would not help them as they need to change it exactly once. We just need to explain to users that the change in project properties would affect projects created afterwards, because I agree with masaki that it's a bit inconsistent with behavior of other project properties and therefor potentially confusing. I like that best using a note in the properties dialog saying something like: "The selected encoding will be used also for new projects." The note should show up next to the encoding combo box when the user changes the encoding. See the attached screenshot. For users who use different encodings in different projects, the current behavior is inefficient, because they have to always go and check the properties dialog as they probably don't remember what was the last change they did for encoding. A global setting would not help them either, as it's just a different place they need to go. Furthermore, they would have to think whether changing the setting at project level is enough for now, or they should rather go to the global place because they would use the same setting for a few new projects. If we want to really fix it for those users, we would need to add the encoding option into the New Project wizard. We probably don't want to do it for 6.0 if at all. Created attachment 45286 [details]
Proposal for encoding note in project properties dialog
I doubt that enough users care about setting the project encoding to merit its being placed directly in the New Project wizard. What proportion of our users really include non-ASCII characters in their source code? (*.txt, *.java, but not *.xml or *.properties which ignore project encoding.) I am guessing it is not very large. Consider that there are much more widely used project properties which should have priority in going into NPW: Java source level, compiler flags, etc. Currently we don't bother putting these into NPW (and cluttering it with extra controls) because we expect that the defaults are good enough for a lot of cases, and it is quick enough to change the settings after the project has been created. Maybe there should be some advanced part of the New Project Wizard containing the encoding. Button "Advanced" causing appearing of the advanced options in the Wizard. I'm fine with *not* adding the encoding setting into the NPW. How about adding the note into project properties? Is it okay from your point of view? Yes, I will do it. |