Community
Participate
Working Groups
Created attachment 287715 [details] A screenshot showing the filter dialog, highlighting the scope area MarkerSupportView and its parent ExtendedMarkersView allows RCP applications to implement their own view similar to the problems view, tasks view, etc... The filter used by this view has the problem that the scope area cannot be customized. Not all of the options are relivant for every rcp application. There should be a way to remove some of these radio button options. For reference these are the hard coded options in ScopeArea used to filter on scope. /** * Constant for any element. */ static final int ON_ANY = 0; /** * Constant for any element in same container. */ static final int ON_ANY_IN_SAME_CONTAINER = 3; /** * Constant for selected element and children. */ static final int ON_SELECTED_AND_CHILDREN = 2; /** * Constant for any selected element only. */ static final int ON_SELECTED_ONLY = 1; /** * Constant for on working set. */ static final int ON_WORKING_SET = 4;
Patches are welcome : https://wiki.eclipse.org/Platform/How_to_Contribute
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/191618
I submitted a gerrit patch but the build is failing for some reason I dont understand. Would someone with knowledge of the build system be able to help out debugging the error ? [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:2.7.0:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.e4.ui.workbench.renderers.swt: Version have moved backwards for (org.eclipse.e4.ui.workbench.renderers.swt/0.15.300.v20220302-1518). Baseline has 0.15.400.v20220308-0630) with delta: 0.0.-100 -> [Help 1] note: I didn't modify any code in the plugin mentioned above. https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/191618
The build is passing now after doing a rebase.
Which radio buttons are you willing to remove concretely and why? If this is about application configuration and not a feature addition, I'm not sure an extension point is best; instead it would be simpler to use preferences and let RCP customize them in their plugin_configuration.ini .
(In reply to Mickael Istria from comment #5) > Which radio buttons are you willing to remove concretely and why? > If this is about application configuration and not a feature addition, I'm > not sure an extension point is best; instead it would be simpler to use > preferences and let RCP customize them in their plugin_configuration.ini . Please ignore that comment, I think given the amount of config in markerSupport.exsd, it's better to keep everything there.
(In reply to Mickael Istria from comment #5) > Which radio buttons are you willing to remove concretely and why? > If this is about application configuration and not a feature addition, I'm > not sure an extension point is best; instead it would be simpler to use > preferences and let RCP customize them in their plugin_configuration.ini . There is already an extension point markersupport (which is flagged experimental). Enda has added an extra attribute to this extension point to control the display of these variables. No new extension point was added.
(In reply to Mickael Istria from comment #6) > (In reply to Mickael Istria from comment #5) > > Which radio buttons are you willing to remove concretely and why? The use-case is described in the initial comment. What other clarification are you looking for? > it's better to keep everything there. What do you mean by that?
(In reply to Wim Jongman from comment #8) > The use-case is described in the initial comment. What other clarification > are you looking for? I'm looking for information in term of usability, to evaluate whether visibility of the radio components can be decided automatically according to the context. Also, I'm actually not sure the grain is correct: rather than tweaking the content of the dialog in such a fine grain, it might be better to just let extenders override the ScopeArea from their specific view implementation, or maybe even consider a dedicated Problem Filter dialog.
(In reply to Mickael Istria from comment #9) > (In reply to Wim Jongman from comment #8) > > The use-case is described in the initial comment. What other clarification > > are you looking for? > > I'm looking for information in term of usability, For example: We don't use working sets in our application so 'working sets' is not needed. We have the concept of a single active project in the workspace and don't want to show markers for non active projects. So 'On any Element in the same project' isn't relevant. > to evaluate whether > visibility of the radio components can be decided automatically according to > the context. I think it should be application specific, at least the concept of an active project is not in eclipse. > Also, I'm actually not sure the grain is correct: rather than tweaking the > content of the dialog in such a fine grain, it might be better to just let > extenders override the ScopeArea from their specific view implementation, The problem with this is that there is a lot of internal code in this area. e.g. FilterConfigurationDialog is internal. Its ScopeArea implemtation is internal. ScopeArea is referenced as GroupFilterConfigurationArea in the FilterConfigurationDialog. GroupFilterConfigurationArea is also internal. GroupFilterConfigurationArea uses MarkerFieldFilterGroup which is also internal. > or > maybe even consider a dedicated Problem Filter dialog. This will face the same problem with internal code. Also, most of the problem filter dialog works for us.
I moved the patch to github as recommended in the Gerrit review: https://github.com/eclipse-platform/eclipse.platform.ui/pull/17
Is it possible for this to be merged ?
Can this be merged or is there further work required?
(In reply to Enda Fadian from comment #14) > Can this be merged or is there further work required? Hi Enda, could you move the change to a PR? If you do, please add me via cc so that I can review. ---------- From the Gerrit comment: This repository is now moved to GitHub: https://github.com/eclipse-platform/eclipse.platform.ui . Please immediately set you `upstream` repo url to use GitHub instead of Gerrit $ git remote set-url upstream git@github.com:eclipse-platform/eclipse.platform.ui.git If you're not planning to continue working on this patch; please mark this current Gerrit review as "Abandoned". If you're willing to transfer this issue to GitHub Pull Requests: 1. On GitHub Web Interface, fork the repository, and retrieve the URL for the fork eg `git@github.com:my-github-userid/eclipse.platform.ui.git` 2. $ git remote add origin git@github.com:my-github-userid/eclipse.platform.ui.git 3. Checkout this current patch (See the "Download" link on this Gerrit review page) 4. $ git push origin HEAD:refs/heads/a-meaningful-branch-name 5. As output of the push, Git shows a link to Create a Pull Request, follow this link and create the pull request. If some useful discussion took place on Gerrit, you may want to include a link to the Gerrit review on the GitHub pull request message, for reference. -------------
