Community
Participate
Working Groups
Build 20031029 I'm defining preference pages, categorized like so: org.eclipse.jdt.ui.preferences.JavaBasePreferencePage (from JDT UI) org.eclipse.jdt.debug.ui.JavaDebugPreferencePage (provided by me) org.eclipse.jdt.debug.ui.JavaStepFilterPreferencePage (provided by me) org.eclipse.jdt.debug.ui.JavaDetailFormattersPreferencePage (provided by me) I define an activity, "Debugging Java", with the pattern "org.eclipse.jdt.debug. *" Disabling this activity does not make my provided preference pages disappear. I define a similar activity "Debugging", which correctly makes the "Run/Debug" preference page disappear. There are two differences between the "Run/Debug" page and the "Java->Debug" pages that I imagine might be at fault. 1. Debugging's pattern is org.eclipse.debug, which shouldn't conflict with any other activities. But Debugging Java's pattern is "org.eclipse.jdt.debug.*" which might be conflicting with the Java Development activity's pattern, "org. eclipse.jdt.*" 2. The Run/Debug preference page isn't in a category (it's a top-level page), but the preference pages listed above are in the category of an active activity (Java Development).
Kim this may already be fixed - pelase verify
Our filtering logic (in general, not just for preference pages) says that if you match any enabled activity then you are shown. In this case, you're matching the base JDT pattern. We previously had the notion of inclusive or exclusive bindings. In this way you could override other bindings. With this mechanism you could provide an exclusive binding for the base JDT activity that excluded your debug contributions. But as I said, this was previously - this feature was removed for the sake of simplicity. I'll take a look at the reprocussions of showing an item if and only if ALL activities that it is bound to are enabled, but I'm thinking this might be too restrictive.
I've talked this over with Tod and we've decided that we're happy with our filtering logic the way it is now. We believe the correct course of action is to engineer pattern bindings to be as restrictive as needed. Ie: if the JDT pattern binding was org.eclipse.jdt.ui.* instead of org.eclipse.jdt.* then your problem should go away. If generalized bindings such as this are not possible due to plugin architecture then bindings to specific contributions will be required (or the plugin developer can refactor their plugin to have a layout compatible with these requirements in mind). Please try editing your pattern bindings with this in mind and see if it helps resolve this problem. If not, we can revisit.
