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: | [65cat] Make IDE Settings movable without import | ||
---|---|---|---|
Product: | ide | Reporter: | klosels <klosels> |
Component: | Import Settings | Assignee: | Jiri Skrivanek <jskrivanek> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, apireviews, chrisnielsen, deeptinker, dstrupl, fommil, hmichel, jfosterjr, lhasik, olangr, pjiricka, rmatous, tmysik, ulfzibis |
Priority: | P2 | Keywords: | API_REVIEW, UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://wiki.netbeans.org/ExportImportOptions | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 41265, 158618 | ||
Bug Blocks: | 17693, 55647, 58412, 60750, 75084 | ||
Attachments: | Patch. |
Description
klosels
2004-04-20 08:50:02 UTC
I would like to be able to share exported ide settings with other developers. Our project code is formatted w/ tabs = 4 spaces, expand tabs to spaces = false, etc. so that everyone sees the code in the same format. We also add a few non-standard file extensions to some of the indentation engines to get some syntax highlighting as we have a scripting language that is loosly based on 'C'. You *can* move such stuff around from install to install, just not using the GUI... need to copy relevant files from the $userdir/system/ folder. Unfortunately there is no centralized documentation on which file is which, so you have to experiment a bit. Some documentation on the structure of the settings files would indeed be helpful - be it in the online help, on nbusers list or on the website. On the other hand, I'd fear it to be out of date as soon as 4.0 beta 1 is released, anyway? NB: The fact that you *can* theoretically move these things if you ever found out how and where they are doesn't really help Joe-just-above-average-User. (Hopefully) 90% of NB users just want an IDE that does help them do their job. Fiddling with internal files is not an option for them. Therefore it would be nice to have an option in the import wizard at install time which gives you the choice to import specific categories of settings, e.g. Editor Settings or Execution Types or whatever (an option to automatically install modules corresponding to the ones installed on the old version would be another idea). I agree w/ Lars on the sub-category import and a wizard instead of mucking around in system files. However, I don't necessarily agree it should be on install. I would also submit that an "export" be allowed. As I previously mentioned, I would like to share a specific subset of settings w/ other developers so that code I develop can be viewed correctly by other developers. We would like to be able to create settings that all can use so all code developed under a specific project will maintain the same formatting and structure (Jalopy/code reformatting settings included). I would like to be able to configure tab stops, expand tabs to spaces, and Jalopy per project coding standards, then export them for others to share. I, too, change a myriad of settings every time I install NetBeans: tab sizes, compiler configurations, toolbars, indentation settings, form editor preferences, code completion database settings...and there are probably a few more that I cannot remember. As a NetBeans user since the 3.3 days, I am extremely impressed with the progression of the IDE through 3.6. The lack of an import/export facility for configuration info is -- IMHO -- one of the only glaring omissions at this point in time. p.s. Eclipse has had a settings import/export capability for some time now. So from a competitive perspective, there is also motivation for this feature. If there is any help I can provide, relative to development, please let me know...I would love to help. Even if Eclipse has managed to provide this (from my point of view) very important feature in team environments, they're still figuring out how to deal with various levels of preferences, and think they shouldn't be presented grouped only as components, but something closer to the user view of the things: "The UI should present preferences in such a way that users can readily discover them. Some preference settings have scopes (e.g., workspace-wide vs. per project). The UI should help the user to visualize these scopes." Check: https://bugs.eclipse.org/bugs/show_bug.cgi?id=71124 https://bugs.eclipse.org/bugs/show_bug.cgi?id=36965 *** Issue 60535 has been marked as a duplicate of this issue. *** I just installed NB 5.5 and this actually works very well at least to some extent now. My macros and abbreviations and also my font sizes and custom toolbar icons were imported and the IDE even started up with the same projects as my previous version. I cannot see if everything is migrated correctly but my experience with NB 5.5 met my expectations wonderfully. Thank you for fixing this. Randahl I've been using NB 6.0, both the official beta releases and the overnight builds. It's horrible having to copy (parts of) the folder structure manually, to migrate settings across versions. Worse, the folder structure mixes-up things which IMO should be managed separately, most notably editor preferences and libraries. It may well be that as a team, we want to share a common set of editor prefs (to reflect a house standard), but perhaps have different local library settings. NB appears to cache a lot of stuff below .netbeans\6.0beta1\var\, so copying the entire folder structure is both uneconomical (it's around 80MB on my system) and probably wrong because the cache is presumably a completely local thing. Copying folder structures around is just awful. This can't be a hard thing to fix, can it? I'll vote for this issue to be addressed. Reassigning to new module owner jskrivanek. Some significant aspects of this issue mentioned above are now solved in NetBeans 6.5: - ability to share libraries with other users (added in NB 6.1) - ability to attach code formatting settings to the project and share them with other users this way (added in NB 6.5 M2) (which allows to delete the NB settings directory without losing formatting settings) So, what are some other aspects of the setting migration that people would like to have solved? i.e. Macros, Code Templates, Keymaps, ToDo Task keywords, GUI Builder settings. The initial comment contains some more examples. In my opinion there are two use cases: 1) Sharing settings with others e.g. to force a corporate coding style. Obviously this does not make much sense for all settings. 2) Exporting/Importing all possible settings in a version independent format e.g. to allow backing up of settings before installing new modules or updating the IDE or to transfer settings to another computer. > So, what are some other aspects of the setting migration that people would like to have solved?
- Favourites
- Toolbar customization, E.g. additional buttons, E.g: issue 42335, importing from old settings is the only way to get
buttons, which are not reachable by the new options dialogue.
- Platform settings
> So, what are some other aspects of the setting migration that people would like to have solved?
The biggest thing for me is when moving from 5.x to 6.x betas, for example, I have to reconfigure all my settings.
That's bad enough, but worse, when moving from 6.x beta 1 to beta 2, I have to reconfigure the settings again, and
when moving to 6.x final, I have to reconfigure the settings AGAIN! Maybe some of that has been changed now, but it
sure seems like that is the way things used to be, back in 2004 when this issue was first created. For those of us
willing to test the betas, we need to be able to at least import settings between from beta installations and from
betas to the final release. Importing from a previous final release would be even better, though I understand why that
might not always be possible.
*** Issue 64028 has been marked as a duplicate of this issue. *** *** Issue 135747 has been marked as a duplicate of this issue. *** *** Issue 152016 has been marked as a duplicate of this issue. *** *** Issue 154125 has been marked as a duplicate of this issue. *** This issue had *26 votes* before move to platform component Please, review implementation of export/import options feature. The patch contains implementation in options.api module, changes in nbbuild/build.xml for generation of list of imports after installation and changes in layers of modules which had something to import in previous releases. Details are described in document mentioned in the url field. Created attachment 77156 [details]
Patch.
I'm sorry, but I don't think a fasttrack review is appropriate for a change of this caliber. This is going to affect pretty much every module that reads stuff from the system filesystem. I have serious doubts that such a generic approach can work effectively. For example some settings have to be exported/imported en block (eg. shortcut or coloring profiles) while other settings should be exp/imp per items (eg. code templates or macros). It is also unsure how exactly the export works - does it export stuff from a userdir (ie. user made changes to settings) or from the system filesystem (ie. full sets of settings; both IDE supplied and user changes). Each way has its pros and cons and I'm not sure which one is correct. Anyway, I don't want to block improvements in such an important and user sensitive area, but I think that this particular solution grossly underestimates the problem and in the end will not solve it. It will only lead to more defects reported by users who will feel like that they have been cheated. I personally would prefer going the way shown in http://ui.netbeans.org/docs/ui/keymap_option_panel/index.html#profiles, which btw was implemented in 7.0M1 as part of issue #123467. Thank you for comments. I pre discussed intended changes at nb-tech-council, so I didn't want to go through full review. Suggested implementation is based just on files in userdir. It imports or exports files to or from userdir. Keymaps or Font&Colors profiles are now ex/imported at once. But it would be possible to do it one by one. I think there is no reason to handle every single code template or macro individually. Could your please enumerate use cases and problems which are not solved by this approach? "I pre discussed intended changes at nb-tech-council, so I didn't want to go through full review." - That's ok. I just think that this change affects too much and so the fasttrack review is not suitable. Obviously, this is just my opinion and so if others are fine with fasttrack then so be it. "Suggested implementation is based just on files in userdir" - Which is not suitable for exporting coloring or shortcut profiles for example. "I think there is no reason to handle every single code template or macro individually" - Well, user requests we have had suggest otherwise. I know the IDE does not support it now, but for example DTD for codetemplates allows using unique IDs for each codetemplate so that when exp/importing the IDE could recognize new codetemplates from those that have already been imported. "Could your please enumerate use cases and problems which are not solved by this approach?" - Well, this issue originally complained about problems with importing user settings from previous versions. Your patch does __not__ solve these problems. It can't, because these problems are in modules and there is no way how to solve them centrally in the platform. Moreover your patch allows users to export/import settings at any time. So, it effectively exposes one of the IDE's weaknesses by providing GUI controls for something that is not properly implemented. IMHO if we integrate this change we are likely to receive a lot of complaints and defects. Technically this API is not suitable for modules either. Modules would ideally need a way how to register their own code for exporting/importing their settings instead of just having their settings files shoveled by the platform from one userdir to another. > "Suggested implementation is based just on files in userdir" - Which is not suitable for exporting coloring or > shortcut profiles for example. As I heard the problem is in default profiles. If user changes something, only diff against default profile is saved in userdir. So, it will work when profiles are compatible. Maybe default profiles should not be editable and user should be forced to clone such a profile and modify own copy. > ...so that when exp/importing the IDE could recognize new codetemplates from those that have > already been imported. It is true my implementation doesn't solve conflicts of import. It is up to user whether to import everything or not. He can export his options as a backup before importing. > ...problems with importing user settings from previous versions. For import are always allowed only files which are recognized by some of currently loaded modules. But if for example file format changes between versions, it is up to module to not accept obsolete settings > Modules would ideally need a way how to register their own code for exporting/importing... Yes, that was my original idea to have something like OptionsExportProvider and modules can implement it (see http://wiki.netbeans.org/ExportImportOptions?version=4). But if I want to do initial import of setting from previous release at the first start after installation, modules are not yet loaded and I need some declarative way of import. I was also considering import of options when IDE is fully initialized but with ergonomics IDE it is not possible. I will integrate proposed patch tomorrow. Just for the record. We discussed the change in person (jskrivanek, olangr and I) and we still seem to have different opinions about how this should work. None of my concerns were satisfyingly addressed or proven to be void. Although I am not strongly against the change I think it is not going to work well for editor settings. We may fix it in the future, but it is likely to require substantial amount of work on both sides (ie in the editor and also in this api). If this change results in too many complaints (bugs) about export/import of editor settings we will consider removing editor settings from the list of settings that can be exp/imported through this functionality. I must say that I don't understand why the standard API review was not held yet - Vita brought up some very valid and constructive input. Refusing to even hear other people's comments is a very immature attitude. To me, the most glaring flaw of the proposed solution is that for the keymap profiles, it will add another parallel implementation next to what we already have, so there will be two different and inconsistent approaches to do one thing. Another major flaw would be if the solution indeed does not address the user requirements we are hoping to solve - this is another thing that can be easily discussed at the standard review meeting. Fixed. Arbitrary export/import of user options can be done from the Options dialog. Layers of modules which provide something for export were updated, so we don't need centralized list anymore because initial import after installation is driven by list of patterns generated from these layers. http://hg.netbeans.org/core-main/rev/220781be1185 to pjiricka: I am sorry but I have read your comment too late. I have just pushed changes to the repository. I discussed objections with vstejskal but I am still convinced that my implementation is better than nothing. It goes along with previous approach that all user options stored in userdir were copied after installation of new IDE version. So, I think keymap profiles should be importable from userdir. In such a case user even don't need to explicitely export/import his profile if switching to newer IDE version but profiles are imported within other options. The main user requirement was to be able to share/backup/import/export settings. This requirement is fulfilled. I finished this review without official meeting because we discussed it and there were no strong opinions against it. Please, let me know if you want me to call a meeting now. Integrated into 'main-golden', will be available in build *200903060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/220781be1185 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #42157 - Enable arbitrary export/import of user options. Added UI to options.api module and updated layers of modules which provide something for export. Also initial import after installation is driven by list of patterns generated from layers. *** Issue 159596 has been marked as a duplicate of this issue. *** Just tried this in the nightly... there is no way to create a new zip file when exporting using the file browser in OS X, it's expecting me to select an existing zip file. Also, might be a local setting of mine, but all hidden files are being shown... that's not pretty. I've not been able to try this, but will NetBeans remember the buttons that I've clicked to export? I don't want to have to do that every time! Thank you for feedback. I fixed Mac issues with issue 159909. NetBeans doesn't remember selected items because we expected it is not an action someone will use everyday. If you are missing some feature like this, please, file a separate issue for it. Short of remembering the settings, it would be highly useful to have "select/deselect all" button! Integrated into 'main-golden', will be available in build *200903170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f5c059fb4158 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #42157 - Use new API with check boxes next to node. Set visible root node which allows to select/deselect all at once. verified according to http://wiki.netbeans.org/ExportImportOptions Product Version: NetBeans IDE Dev (Build 090317) Java: 1.6.0_13; Java HotSpot(TM) 64-Bit Server VM 11.3-b02 System: Linux version 2.6.27-11-generic running on amd64; UTF-8; en_US (nb) I don't like the fact that not all registered categories are visible in export/import dialog, but just those that really exists in userdir. If I was a user and I would open export/import dialog and wouldn't find Editor (category/node) I would expect that Editor setting can't be exported and I wouldn't open the dialog again. IMHO every category (folder in layer) in OD should be represented by one node in export/import dialog - no matter what was changed, it makes navigation in such tree easier. I think it is OK that if nothing is changed, nothing is available for export. Users will not try to export something if they don't change anything. From developers point of view it might be confusing that if you add some patterns to layer, there is no item in the export dialog. I will add a comment to the document but I don't plan to change it. Ondro, what is your opinion? Could you review once more whether UI and work flow is all right? Thank you. For me, it's a bit weird that one day I don't have some category in the Export dialog but the other day it's there; or that I don't have some category in my Export dialog but a colleague sitting next to me has it (IMHO I can hardly guess that it's because I changed something). I'm not UI expert but personally I would prefer the dialog to be the same all the time with some items disabled (maybe tooltip can tell the reason?). Agreed that this can be confusing. Better solution really seems to be to display the items which cannot be disabled and indicate this fact. Or at least state that "Only settings modified from the defaults can be exported" .. or something similar. Integrated into 'main-golden', will be available in build *200905041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/001c10b5e4b5 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #42157 - Show all options registered for export but disable not available ones. While importing show only available. *** Issue 164350 has been marked as a duplicate of this issue. *** *** Bug 118848 has been marked as a duplicate of this bug. *** |