Bugzilla – Full Text Bug Listing
| Summary: | [Preferences] Preferences dialog should have link to export/import | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kevin McGuire <Kevin_McGuire> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | hanriseldon, john.cortell, neal.johnson, remy.suen, sandakith |
| Version: | 3.4 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Kevin McGuire
To be more precise its File->Export->General->Preferences (so even more hidden). +1 for the proposal, we definitely need some link from preferences dialog to show that we can import/export preferences from File->Export/import->General->Preferences I don't think this is hard to implement, but where should it go? Top right next to the arrows? Actually that is not a bad place. Before we had it at the bottom. It is subtley harder than you think though. If I export from the preferences dialog which preferences to I export? The current working copy as used by the dialog or the ones that are already saved. I can see both being useful. On top of that changing some preferences can change others (like the JRE for example). How do you handle that? (In reply to comment #4) > It is subtley harder than you think though. If I export from the preferences > dialog which preferences to I export? The current working copy as used by the > dialog or the ones that are already saved. I can see both being useful. True. Presently though we only provide (via export) the ability to retain the ones already saved, so the simple answer is that is still all we provide, we just give you an easier way to get to it (the link). That's the problem we're trying to solve. Possible solutions are 1) the save link is disabled if the preferences are modified, or 2) clicking the link would offer to save them first (or cancel and no save and no export either). My preference is for the latter (2). My preference is also on [2], and if we cant go for that even we can print a banner at the preferences that the import/export can be done to the preferences at the File -> import/export. Thanks Lahiru I can't figure out how one would check if any of the preference pages are dirty. I know I can call getWorkingCopyManager().applyChanges() to save all changes but I presume we don't want to prompt about saving if there aren't any changes to begin with. There isn't. There is no concept of dirty in the current API. Well, that's a problem. Unless we prompt to "save" even though nothing's been changed. Ok, I see this has P5 priority, but it would be cool to actually have the link in the place where it would be most logical to find it. I'm using Eclipse 3.5 M4, so I'm looking at approximately the newest code out there, and the prefferences are still exported and important through the wizards. Anyways, it should be simple to add. Cheers. Eugen. I don’t think this goes far enough. The link to export is a good idea, but the export its self is not give you all the export option required. For example I work on multiple projects and each project has its own set of standards that I must obey, the source control for each project does not assume any IDE as it should do. So when I check out the project into eclipse I have to then configure several different preference panels in order to comply with the project standards. If every plug-in that adds a panel to preferences had to implement export/import with an option for project or global then this problem could be solved. I think that this issue has gone off track, I don’t care where in the application this option sites I care more about its functionality. At the moment export does not even work for some of the core application preferences, for example “code style” not in the export options but does have its own export format? My original post was not a "I don’t know where this feature is" merely that it does not work as advertised. I think that any preference that is added to the application should implement some kind on interface that denotes it can be exported. That way the export wizard can determine if any preference has an export feature regardless of file format, each preference can then have a method called on it if it implements the interface, the format of the4 export can then be preference specific. For the import the same process can be followed. I think that this issue has gone off track, I don’t care where in the application this option sites I care more about its functionality. At the moment export does not even work for some of the core application preferences, for example “code style” not in the export options but does have its own export format? My original post was not a "I don’t know where this feature is" merely that it does not work as advertised. I think that any preference that is added to the application should implement some kind on interface that denotes it can be exported. That way the export wizard can determine if any preference has an export feature regardless of file format, each preference can then have a method called on it if it implements the interface, the format of the4 export can then be preference specific. For the import the same process can be followed. (In reply to comment #13) > I think that any preference that is added to the application should implement > some kind on interface that denotes it can be exported. That way the export > wizard can determine if any preference has an export feature regardless of file > format, each preference can then have a method called on it if it implements > the interface, the format of the4 export can then be preference specific. For > the import the same process can be followed. We have the preferenceTransfer extension point for this though I'm not familiar with it enough to say whether it covers all use cases or not. Then again, what does? +1 We are looking at adding this to our eclipse sources and would like to see this added in the community. The reason is exactly what has been stated here. File->Export->General->Preferences is hidden and not intuitive when you're in the Preferences dialog and you start wondering "how do I get these pref tweaks into another workspace", or "how do I bring in tweaks that I made in my other workspace". You should be able to figure that out right in the dialog. We'll contribute a patch. It would be nice to know where committers stand on this, particularly if there are objections or concerns. It appears import/export options were available in this dialog years ago, so some insight into why they were removed would be very helpful. Update: I've spent a few hours on a prototype implementation. It turns out this really can't be implemented in an ideal way. At best, we can add import/export links/buttons/menus, but the best we can do on an import click is offer to close the dialog for the user and open the Import Preferences wizard. The reason is that there is nothing in the preferences API for getting a page to reset its UI based on new data. There's support for the page detecting that the Restore Defaults has been hit, but the reaction is entirely up to each page. I.e., each page subclass has to reset its GUI based on what it knows to be its default values. This is all particular to Restore Default, and not a general mechanism for updating the GUI to an arbitrary set of values. What this means is that if we invoke the Import Preferences wizard while the preferences dialog is open, when the user has finished with the wizard, the preference store will contain the imported values, but the preferences UI will be stale. Again, there's nothing in the API that would allow us to force the page(s) to update, and belatedly introducing such API enhancements would, at best, be pointless. Not sure if we're going to see enough value in the non-ideal solution to pursue, but if we do, we'll contribute it. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie. |