Community
Participate
Working Groups
This is a follow on to bug #257956 which was closed as fixed. As with the requestor, I don't understand why the contributed config items cannot be deleted. Is there a technical issue with the fact they're contributed via extension? Or just that we have no way of getting them back? I'm ok with treating them differently such that they can't be deleted, but then we really should support "Revert" so that they can be restored to factory state. Or, they're considered disposable freebies we give the user to get started, in which case they should be delete'able. Either they're "special" in some way and so we don't want to lose them, or they're not. That to me is the decision. Thus, A) If 'special', must support Revert. B) If 'throw away', must support Delete.
(In reply to comment #0) It would be matter of marking them as deleted and probably a little more trick. But IMO, 1) there would not be a simple way of getting them back. A full restore on the filter configurations would be needed. 2) Seeing from a contributor's perspective it may be confusing (and possibly undesirable) when a contributed config is deleted. The idea about 'revert/restore' might be similar to Bug 269869(?). But agree with 'Revert/restore'. PS: I was under the notion that it was a general rule to disallow deletion(/hiding) of contributions.
(In reply to comment #1) > It would be matter of marking them as deleted and probably a little more trick. > But IMO, > 1) there would not be a simple way of getting them back. A full restore on the > filter configurations would be needed. Agree we'd need a way of restoring them, which adds complication. The concept of "Hide" might be better than "Delete". But in any case I'm not strongly arguing we should allow delete, but rather that if we do not, then there are implications: 1) Provide Revert 2) Ideally denote those which are contributed and thus 'special' and cannot be deleted. > 2) Seeing from a contributor's perspective it may be confusing (and possibly > undesirable) when a contributed config is deleted. Hard to say. > The idea about 'revert/restore' might be similar to Bug 269869(?). But agree > with > 'Revert/restore'. That's my vote. > PS: I was under the notion that it was a general rule to disallow > deletion(/hiding) of contributions. We're inconsistent. Mostly we avoid it because we get all in a fuddle along the lines discussed here. But we do provide it in a few places, e.g. File Associations pref. I don't think there's anything particularly 'deep' about the marker configs which prevent their removal (bad things won't happen, you can easily reconstruct them by hand). They're more conveniences. However, I recognize that I'd rather a consistent policy wrt deletion of contributed items and this is arguably not the place to start 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. 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.
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.
