[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [Dltk-dev] introduce IDKLTKDebugUILanguageToolkit?
|
Hi Jae,
I'm agree, introduce of IDKLTKDebugUILanguageToolkit is a good idea.
Andrei.
hello all -
i'm just about done with adding support for detail formatter
preferences but have run into an issue regarding storing their
preferences.
the detail formatters preference page implementation is based upon
the ScriptStepFilterPreferencePage which stores preferences in the
preference store returned from a call to
IDLTKUILanguageToolkit.getPreferenceStore(). the idea behind this is
good b/c it means the plugin implementor doesn't need to do anything
other then create the appropriate entry in the plugin.xml, however
there is an issue with how the defaults for the preferences are
initialized.
it seems that in order for me to properly initialize these values
under this implementation, i need to handle setting the defaults in
the preference initializer that is part of the ui plugin, which in
turn means that the ui plugin needs to depend on
org.eclipse.dltk.debug.ui in order to get access to the preference
constants. i tried creating an initializer implementation in my
debug.ui plugin, but it seems that the initializer is tied to the
preference store for that plugin and i don't see any way to associate
a preference initializer defined in the debug.ui plugin with the
preference store from the ui plugin. these are the potential solutions
i came up with:
- have the ui plugin depend on the org.eclipse.dltk.debug.ui and
handle the debug.ui preference initialization there. this is the
easiest approach, however all of the dltk plugin implementations do
limit their dependency needs, so this may not be favorable from that
stand point.
- introduce an IDKLTKDebugUILanguageToolkit interface that would work
in the same manner as the IDKLTKUILanguageToolkit.
- if there is a way to associate a preference initializer with a
specific preference store, this approach could be taken.
i think the creating an IDKLTKDebugUILanguageToolkit interface would
be the best approach as it would offer the same flexibility that the
other 'toolkit' interfaces provide. thoughts?
--
-jae
------------------------------------------------------------------------
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev