Community
Participate
Working Groups
Build Identifier: 20100917-0705 When exporting preferences, selecting "Export all" checkbox causes additional prefs to be exported compared to unchecking this checkbox and checking all the others. One essential preference that's only exported if "export all" is checked is workspace encoding (others are probably missing as well). This makes it impossible to selectively export prefs if you need workspace encoding to be exported as well. For example we're trying to generate a common preferences file that will be imported by all members of our team, and we would like to export only code style, compiler and SVN repos prefs, but it is mandatory that the encoding is also exported. Currently, we can only achieve this by exporting all prefs. Since these options are mutually exclusive, there should be a way of achieving the same result either way (i.e. the sum of the all the options should be equal to "export all"). Reproducible: Always Steps to Reproduce: 1.File > Export > General > Preferences 2.check "Export all", export to file prefs1 3.repeat #1, uncheck "Export all", click "Select all" and export to file prefs2 4. compare prefs1 and prefs2; prefs1 contains many preferences which were not saved to prefs2
What exactly is your request asking for? Are you trying to suggest that the user interface should perhaps have another checkbox to say something like "Other Preferences"?
The preference transfers are provided by a component as an exportable group that makes sense. But since preferences aren't required to belong to a preference transfer group, the sum of the preference transfers != all the preferences. This comes up occasionally. I'm not sure how we can make it clear that these preference transfers don't include everything, except perhaps adding a separate title (since it does look like Export All immediately leads into the preferences broken down into categories). PW
(In reply to comment #2) > This comes up occasionally. I'm not sure how we can make it clear that these > preference transfers don't include everything, except perhaps adding a separate > title (since it does look like Export All immediately leads into the > preferences broken down into categories). I'm pretty sure there's another bug open on this topic. In the past, I've considered completely disabling the bottom part if 'Export all' or 'Import all' was selected.
(In reply to comment #1) > What exactly is your request asking for? Are you trying to suggest that the > user interface should perhaps have another checkbox to say something like > "Other Preferences"? Yes, I guess that would be a solution. I don't know exactly what kind of preferences would be mixed on this option, so I can't say if further breakdown would be better, but even if it mixes oranges and apples, still it would be better than what's available today. Currently, if you want just some of the categories but also need at least one preference which is not on any of them (eg. workspace encoding, the reason why I filed this issue), you have no choice but going for the "all" checkbox, which is overkill.
(In reply to comment #4) > Currently, if you want just some of the categories but also need at least one > preference which is not on any of them (eg. workspace encoding, the reason why > I filed this issue), you have no choice but going for the "all" checkbox, which > is overkill. The specific contributing bundle has to decide "yes, I will let users individually export item X", this isn't really up to the preferences export wizard to decide.
(In reply to comment #5) > The specific contributing bundle has to decide "yes, I will let users > individually export item X", this isn't really up to the preferences export > wizard to decide. Mmmh... ok, I didn't know what's exported is specified by the bundles, I thought the wizard could pull whatever it wanted. Anyway, I don't think the point here is to individually manage single items, the "other preferences" approach you suggested on comment #1 would be enough IMHO. Considering how bundles and the wizard interact, is this possible?
(In reply to comment #6) > Mmmh... ok, I didn't know what's exported is specified by the bundles, I > thought the wizard could pull whatever it wanted. No, because the wizard is completely oblivious to what the string keys are for each individual preference. > Anyway, I don't think the > point here is to individually manage single items, the "other preferences" > approach you suggested on comment #1 would be enough IMHO. Considering how > bundles and the wizard interact, is this possible? I think it _might_ be technically feasible but not necessarily straightforward to implement as this would require a full export first of all preferences and then a "reverse" process of removing any string keys that were defined to be exportable individually (the existing categories you see in the page right now that actually have names) which the user has left unchecked.
(In reply to comment #7) > (In reply to comment #6) > > Mmmh... ok, I didn't know what's exported is specified by the bundles, I > > thought the wizard could pull whatever it wanted. > > No, because the wizard is completely oblivious to what the string keys are for > each individual preference. I see. It makes sense, actually, to delegate this to the bundles, it makes it more scalable (new bundles can be added without need to touch the wizard). > > Anyway, I don't think the > > point here is to individually manage single items, the "other preferences" > > approach you suggested on comment #1 would be enough IMHO. Considering how > > bundles and the wizard interact, is this possible? > > I think it _might_ be technically feasible but not necessarily straightforward > to implement as this would require a full export first of all preferences and > then a "reverse" process of removing any string keys that were defined to be > exportable individually (the existing categories you see in the page right now > that actually have names) which the user has left unchecked. Ouch, not ideal, indeed. Of course a more elegant solution would be better, but if that's the only choice, I'd still go for it. But, there's still a piece of the puzzle missing for me. How does the "export all" work? If it was through the iteration over each bundle, we wouldn't have these "extra" prefs. Where do they come from?
(In reply to comment #8) > How does the "export > all" work? If it was through the iteration over each bundle, we wouldn't have > these "extra" prefs. Where do they come from? Not every bundle defines a grouping of preferences to export (those are the checkboxes you see in the wizard). 'Export All' just goes for an all-in strategy and writes out all the preferences. There is nothing really "extra" about them. They're still preferences that have been defined by the individual bundles at the end of the day. Does that makes sense?
(In reply to comment #9) > Not every bundle defines a grouping of preferences to export (those are the > checkboxes you see in the wizard). 'Export All' just goes for an all-in > strategy and writes out all the preferences. There is nothing really "extra" > about them. They're still preferences that have been defined by the individual > bundles at the end of the day. > > Does that makes sense? Yes, it makes, thks for the explanations. Still, I guess this deserves at least a RFE because, as I pointed on the issue description, it prevents us from standardizing some mandatory settings by sharing only compiler, code style and workspace (more specifically, encoding -- for legacy reasons we still need to use ISO-8859-1 on all our projects) preferences among different teams. The way it is currently implemented forces us to unnecessarily share all prefs, and lots of unneeded (and sometimes unwanted) prefs go along. I always gets complaints when people import our "global" prefs file and inherit my workspace history on their own projects. A definitive and maybe easier solution would be having more specific categories, but IMHO having a "other prefs" checkbox would be an improvement anyway. Is it reasonable to turn this into a RFE? Or should I just forget about it? ;-) BTW: I'll be out for the next 2 weeks, so I won't be able to comment until I come back.
(In reply to comment #10) > Is it reasonable to turn this into a RFE? We can certainly adjust that. You may also be interested in the Workspace Mechanic for Eclipse from Google. http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
(In reply to comment #11) > (In reply to comment #10) > > Is it reasonable to turn this into a RFE? > > We can certainly adjust that. > > You may also be interested in the Workspace Mechanic for Eclipse from Google. > http://code.google.com/a/eclipselabs.org/p/workspacemechanic/ Thank you very much, Remy =) I'll take a look at Workspace Mechanic, it seems promising. Still, I hope this RFE gets somewhere, I believe it would improve the wizard.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
