Bugzilla – Full Text Bug Listing
| Summary: | [Markers] Improvement requests to Problems View / Configure Contents dialog | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Robert Konigsberg <konigsberg> | ||||||
| Component: | UI | Assignee: | Hitesh <hsoliwal> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | daniel_megert, emoffatt, Kevin_McGuire, markus.kell.r | ||||||
| Version: | 3.4.1 | ||||||||
| Target Milestone: | 3.5 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Robert Konigsberg
Good idea! I think that I'd prefer to see the second one. This approach maintains the distinction between the ones we supply and the ones that the User creates. BTW, I've just started using the 'Duplicate' on the launch config dialogs and like it a lot. Created attachment 120433 [details]
Patch 1
Eric, the duplicate button is certainly helpful.
Attaching a patch for the same.
So frustrating: I keep replying to bugzilla emails, thinking they get applied to the conversations, but I'm wrong. So, hey, here's my comment from a few days ago: What is important about maintaining the distinction between Eclipse-supplied configurations and non-Eclipse-supplied configuratioins, and what prevents me from merely deleting them to begin with? Given the large amount of unused real-estate on the right side of the list, I can't imagine there's that much of a cost for providing both features. Just because you can rename by doing COPY + DELETE, it's still a kind of yucky thing to do. I guess I wonder: why not just have both? PS without looking at the details, the patch looks nice. (In reply to comment #3) > So frustrating: I keep replying to bugzilla emails, thinking they get applied > to the conversations, but I'm wrong. So, hey, here's my comment from a few days > ago: > Your input is appreciated. > What is important about maintaining the distinction between Eclipse-supplied > configurations and non-Eclipse-supplied configuratioins, and what prevents me > from merely deleting them to begin with? > The system configurations are the ones provided by plug-ins. In my opinion, deleting(/editing certain things for) such a configuration would require changing plug-in code contributing that configuration. > Given the large amount of unused real-estate on the right side of the list, I > can't imagine there's that much of a cost for providing both features. Just > because you can rename by doing COPY + DELETE, it's still a kind of yucky thing > to do. > > I guess I wonder: why not just have both? > About the rename option, that would probably require two mouse clicks less than what you have mentioned. The rename, would require a button that would open up an InputDialog, take a valid name, refresh the list. Eric, what do you think about this for non-system configurations? > The system configurations are the ones provided by plug-ins.
> In my opinion, deleting(/editing certain things for) such
> a configuration would
> require changing plug-in code contributing that configuration.
Are you saying that those configurations should not be edited? Because it seems to me that it's really easy to edit those configurations. I mean, once I get the environment set up, removing those configurations should be a no-brainer, super easy.
> > What is important about maintaining the distinction between Eclipse-supplied > configurations and non-Eclipse-supplied configuratioins, and what prevents me > from merely deleting them to begin with? > (In reply to comment #6) > > The system configurations are the ones provided by plug-ins. > > In my opinion, deleting(/editing certain things for) such > > a configuration would > > require changing plug-in code contributing that configuration. > Read again,you cannot delete these ==> deleting(/editing certain things[Read name, and others] for) > Read again,you cannot delete these
> ==> deleting(/editing certain things[Read name, and others] for)
>
Ah, I see now, that those cannot be deleted. Perhaps another enhancement giving a visual indicator about this? Because that wasn't clear at all.
On which attribute does this depend? Its name? Or an ID?
Even if we cannot rename a problem configuration because it's read-only, we can do the same with the delete button: disable it.
Hitesh, I've just gone over your patch for the 'Duplicate' button and it looks fine except for two issues that I can see... There's a commented line in 'createNewFilter' (line 436) that looks like a leftover from the patch development and should be removed. Also, I was initially confused about the name of the 'applyChanges' method. When it's used in the 'okPressed' the name makes sense but it's a bit confusing when used in the 'createNewFilter' method because there have been no changes (we're creating a new one...). How about renaming it to something like "captureStateInto' with the javadoc stating that it updates the given item with the values showing in the dialog's GUI. I think it'd then make sense in both places we use it. Created attachment 120663 [details]
Patch 2
Thanks Eric. I have updated the patch.
Thanks Hitesh, looks good now. Committed in >20081222. Applied the past patch from Hitesh. Hi, this is not actually fixed yet, as my request was for both clone and rename. I understand that for some configurations, you can't rename them, but for some you can. Just like you can delete. There's plenty of real estate on the screen for it, why not include it? -- Thanks. Robert, I'm leery of doing the rename (see comment #2). Doesn't this fix give you all of the new functionality that you you looking for, the only side-effect being that the original eclipse-supplied filter remains? Well, let's say okay for now and see how it goes. I can always bring it up again, or be a nag at EclipseCon. (kidding!) Verified in I20090429-0800. I'm kind of with Robert on this one. I believe we need to support "rename". I've opened a new bug for this rather than reopening this one: Bug #275018 - [Markers] Problems View / Configure Contents dialog should support rename Also I believe we need to think more about delete. I've opened: Bug #275021 - [Markers] Problems View / Configure Contents dialog - either provide Restore or allow deletion of contributed items Kevin, there's some conceptual overlap here between these and Perspectives; they both may start life as contributions but we allow 'local' customization... This implies that we need 'Reset...' as well (for contributed content definitions). The dialog could also use a close look at its layout; to me there's not enough horizontal space for the tree and no way to adjust it. P.S. should we make a single uber defect where we can carry on the general conversation? Pasting to an already VERIFIED defect seems odd... (In reply to comment #17) > Kevin, there's some conceptual overlap here between these and Perspectives; > they both may start life as contributions but we allow 'local' customization... Good observation you're right. > This implies that we need 'Reset...' as well (for contributed content > definitions). Yes agree, that was one of my suggestions in bug #275021. > The dialog could also use a close look at its layout; to me there's not enough > horizontal space for the tree and no way to adjust it. Let's log a new bug for that. > P.S. should we make a single uber defect where we can carry on the general > conversation? Pasting to an already VERIFIED defect seems odd... I prefer different bugs for different aspects but we could create a tracking bug and make them all dependent if you'd like to keep them grouped together. We now have two new bugs (listed comment #16) plus a proposed third to be added on layout. +1 That way we can keep the various conversations about UI specifics for each case separate while still keeping a handle on all the different defects that should be addressed while we're working in the area... This patch causes a mnemonic conflict: I can no longer toggle the description using Al+'D', see bug 275809. |