Community
Participate
Working Groups
Created attachment 245959 [details] Inactive buttons In my RCP / plug-in training session I noticed that most "newcomers" fight with the buttons in the Runtime configuration. These are only active if the filter is not set. See screenshot I suggest to handle the button activation independently of the filter.
I am closing this as WONTFIX because I know that the filtered tree implementation used there is very fragile. If you want to work on a fix, you can reopen, but any change will require substantial testing. All of the disabled buttons affect the checked items, including those that are currently filtered. The solution may have to clear the filter, change the checked items, then reapply the filter, causing flashing in the UI. You find it common that users are entering a filter and not clearing that filter?
(In reply to Curtis Windatt from comment #1) > You find it common that users are entering a filter and not clearing that > filter? Yes, out of two reasons: 1.) I see it with my RCP / Plug-in trainees all the time. These days our PDE runtime exercise has two BIG warning issues reminding the people to remove the filter to avoid that issue in the exercises. 2.) Other Eclipse functionality works differently, e.g., the Target Editor from PDE does not require to delete a filter to work fine these days, see Bug 441561 or the p2 installation dialog does also not require that a filter is removed. I think the common assumption (and implementation in Eclipse) is that the filter filters the UI and that this does not affect the "model", e.g. the ability to add dependencies based on the current selection. > If you want to work on a fix, you can reopen, but any change will require > substantial testing. OK, I give it a try. Might get easier, once I fix Bug 440366, in this case we would have a "common" FilteredTree implementation.
(In reply to Lars Vogel from comment #2) > 2.) Other Eclipse functionality works differently, e.g., the Target Editor > from PDE does not require to delete a filter to work fine these days, see > Bug 441561 or the p2 installation dialog does also not require that a filter > is removed. > > I think the common assumption (and implementation in Eclipse) is that the > filter filters the UI and that this does not affect the "model", e.g. the > ability to add dependencies based on the current selection. > > > If you want to work on a fix, you can reopen, but any change will require > > substantial testing. > > OK, I give it a try. Might get easier, once I fix Bug 440366, in this case > we would have a "common" FilteredTree implementation. The target uses a filtered tree implementation I built from borrowed bits from p2. It is far better than the implementation used in the launch config and I still ended up with many subtle issues with running actions while a filter was applied. So good luck :)
Martin, something for you? This is a major usability issue IMHO?
(In reply to Lars Vogel from comment #4) > Martin, something for you? This is a major usability issue IMHO? Martin, are you available to have a look at this for M5?
yes, i think most probably i will be able to look at it
Note: AbstractPluginBlock contains the relevant code.
Is anybody active on this ticket? I think this is very inconvenient and it always confuses my students when they are starting to create their own launch configurations.
I'll take a look at it, but can't promise anything for M3.
(In reply to Julian Honnen from comment #9) > I'll take a look at it, but can't promise anything for M3. Thanks. There is no time pressure on this issue as current behaviour is not wrong. But a fix will significantly improve usability IMHO.
New Gerrit change created: https://git.eclipse.org/r/133002
Gerrit change https://git.eclipse.org/r/133002 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=f9c11238f01f83ebe90ebf17d74cf24e11c10a6f
Awesome, Julian. This solves the number #1 usability issue with PDE tooling I see in my RCP training sessions.
Julian/Lars, can you please verify this defect?
Verified on I20190106-1800
Please check bug 543416, which is possibly a regression from this fix.
*** Bug 220668 has been marked as a duplicate of this bug. ***
