Bug 42157 - [65cat] Make IDE Settings movable without import
[65cat] Make IDE Settings movable without import
Status: VERIFIED FIXED
Product: ide
Classification: Unclassified
Component: Import Settings
3.x
All All
: P2 with 3 votes (vote)
: 6.x
Assigned To: Jiri Skrivanek
issues@platform
http://wiki.netbeans.org/ExportImport...
: API_REVIEW, UI
: 60535 64028 118848 135747 152016 154125 159596 164350 (view as bug list)
Depends on: 41265 158618
Blocks: 17693 55647 58412 60750 75084
  Show dependency treegraph
 
Reported: 2004-04-20 08:50 UTC by klosels
Modified: 2012-08-28 15:31 UTC (History)
14 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch. (100.93 KB, text/plain)
2009-02-19 13:44 UTC, Jiri Skrivanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description klosels 2004-04-20 08:50:02 UTC
Currently whenever I install a new version of NB,
the things I have to do are: 
- modifiy the java editor abbreviations ('ab' and
  'im' are very common german words; comments 
  sound a bit confused with every 'im' being 
  replaced by 'implements')
- modify keyboard shortcuts which don't work on
  german keyboards
- adjust settings for Java Sources (e.g. Prescan 
  Sources off)
- adjust settings for Import Management tool 
  (well-known packages)
- adjust ToDo Settings (Task Tags)
- shuffle toolbar actions around
- ... some more

I'd really like to see a way to move these (and
more) settings from one installation to another,
but in some user-controlled way rather than by
letting the IDE try to import everything (which I
know didn't always work anyway but sometimes
resulted in the advice 'use a new user dir' or
'try a fresh install').
Comment 1 jvincent 2004-04-21 18:47:29 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'.
Comment 2 Jesse Glick 2004-04-28 03:57:04 UTC
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.
Comment 3 klosels 2004-04-28 10:35:17 UTC
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?
Comment 4 klosels 2004-04-28 10:36:00 UTC
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).
Comment 5 jvincent 2004-04-28 18:59:52 UTC
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.
Comment 6 chrisnielsen 2004-07-08 21:17:36 UTC
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.
Comment 7 javiercv 2005-03-26 06:46:12 UTC
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

Comment 8 Jesse Glick 2006-10-31 19:39:20 UTC
*** Issue 60535 has been marked as a duplicate of this issue. ***
Comment 9 randahl 2006-11-02 09:40:13 UTC
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
Comment 10 rsearjeant 2007-10-24 10:00:31 UTC
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.

Comment 11 Antonin Nebuzelsky 2008-04-15 17:19:26 UTC
Reassigning to new module owner jskrivanek.
Comment 12 Petr Jiricka 2008-08-01 08:29:26 UTC
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?
Comment 13 _ moser 2008-08-01 09:18:12 UTC
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.
Comment 14 ulfzibis 2008-08-01 09:33:27 UTC
> 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
Comment 15 jxt 2008-08-01 14:32:56 UTC
> 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.
Comment 16 Jiri Skrivanek 2008-10-13 14:15:33 UTC
*** Issue 64028 has been marked as a duplicate of this issue. ***
Comment 17 Jiri Skrivanek 2008-10-13 14:16:32 UTC
*** Issue 135747 has been marked as a duplicate of this issue. ***
Comment 18 Jiri Skrivanek 2008-11-03 07:50:09 UTC
*** Issue 152016 has been marked as a duplicate of this issue. ***
Comment 19 Jiri Skrivanek 2008-12-02 11:52:44 UTC
*** Issue 154125 has been marked as a duplicate of this issue. ***
Comment 20 Quality Engineering 2008-12-23 14:22:10 UTC
This issue had *26 votes* before move to platform component
Comment 21 Jiri Skrivanek 2009-02-19 13:43:15 UTC
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.
Comment 22 Jiri Skrivanek 2009-02-19 13:44:42 UTC
Created attachment 77156 [details]
Patch.
Comment 23 Vitezslav Stejskal 2009-02-19 15:36:57 UTC
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.
Comment 24 Jiri Skrivanek 2009-02-19 16:13:56 UTC
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?
Comment 25 Vitezslav Stejskal 2009-02-23 09:31:55 UTC
"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.
Comment 26 Jiri Skrivanek 2009-02-24 10:38:50 UTC
> "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.
Comment 27 Jiri Skrivanek 2009-03-03 07:34:02 UTC
I will integrate proposed patch tomorrow.
Comment 28 Vitezslav Stejskal 2009-03-03 16:37:26 UTC
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.
Comment 29 Petr Jiricka 2009-03-04 09:52:49 UTC
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.
Comment 30 Jiri Skrivanek 2009-03-04 10:23:30 UTC
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.
Comment 31 Jiri Skrivanek 2009-03-04 12:19:43 UTC
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.
Comment 32 Quality Engineering 2009-03-06 09:25:17 UTC
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.
Comment 33 Jiri Skrivanek 2009-03-06 09:55:22 UTC
*** Issue 159596 has been marked as a duplicate of this issue. ***
Comment 34 fommil 2009-03-07 11:32:52 UTC
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!
Comment 35 Jiri Skrivanek 2009-03-09 15:37:14 UTC
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.
Comment 36 fommil 2009-03-09 18:29:21 UTC
Short of remembering the settings, it would be highly useful to have "select/deselect all" button!
Comment 37 Quality Engineering 2009-03-17 08:32:42 UTC
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.
Comment 38 Filip Zamboj 2009-03-17 15:39:57 UTC
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)
Comment 39 rmatous 2009-04-08 17:17:00 UTC
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. 
Comment 40 Jiri Skrivanek 2009-04-10 08:17:35 UTC
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.
Comment 41 Tomas Mysik 2009-04-10 08:45:20 UTC
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?).
Comment 42 Ondrej Langr 2009-04-10 10:02:51 UTC
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.
Comment 43 Quality Engineering 2009-05-04 19:07:04 UTC
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.
Comment 44 Jiri Skrivanek 2009-05-05 10:14:53 UTC
*** Issue 164350 has been marked as a duplicate of this issue. ***
Comment 45 Milutin Kristofic 2012-08-28 15:31:59 UTC
*** Bug 118848 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo