Yes, there are cases where the changes to the preference are assumed
to happen directly via the UI (preference page) rather than by
listening to the preference itself change. That's unfortunate...
Cheers,
Ed
On 09/01/2015 2:51 PM, Wim Jongman
wrote:
Just an FYI as well...
What often is overlooked in preference managers is that
there can be additional things done besides just changing
a preference value.
For example, when changing the preference "Plug-in
Development/Include all plug-ins from target in Java search"
a job is activated that updates the java search scope. You
can see this for yourself when you open the progress view
and flip the value. When this preference is set directly
through the preference store then this job is not activated
which obviously is very confusing.
In other words, preferences like this cannot be managed
correctly by Oomph, the Workspace Mechanic and now the
Preference spy.
Since the preference pages are all manually coded UI
panels, there is no way in knowing what things are managed
beside the actual preference.
Just an FYI... The Oomph project has an EMF model that wrap
Eclipse's preferences. This allows all preferences to be
inspected (and even changed), including secure preferences.
When the model is opened in an editor, that editor will
select any preference that changes. This aspect is very
crude compared to what's in the blog, but we often use it
like a "spy" to figure out where preferences changed via the
UI are actually stored in the preference store. The primary
purpose of this preference model is for use in other Oomph
models...
We at the vogella GmbH already use this Preference Spy a
lot, especially for the saneclipse project.
Olivier Prouvost already gave the Preference Spy a try
and explained how to embed the Preference Spy as
official E4 SpyPart.