Re: [platform-text-dev] Preference reorganization

[Daniel Megert <daniel_megert@xxxxxxxxxx>]

Hi Amy,

see my comments below.

Dani

platform-text-dev-admin@xxxxxxxxxxx wrote on 09.12.2004 19:41:14:

> Perhaps I am misreading B).  You said:
> If you want to keep rolling your own editor-specific preferences, that's
> fine as well - but you may have to hide some property change events from
> your editor's super class (JavaEditor does that for the 'displayed tab
> width' value).
>
> But if you use the same preference keys in your preference store,
> then you do not need to hide property change events, correct?
Depends: you need to hide all cases where your editor already handles a
shared preference no matter whether you use the same or a different key. In
cases where you use the same key you can most likely remove the code and
let the super implementation take care of handling the property change
event. Take Tom's example with Java editor's display tab width: the Java
editor takes the value from the formatter preferences and hence must
prevent the super implementation from handling
AbstractDecoratedTextEditorPreferenceConstants.EDITOR_TAB_WIDTH.

> That actually makes me think..How about if the shared preferences
> were taken a step further.  Users could have the option of having
> the same shared preferences for all text editors OR they could set
> the preferences for each individual text editor.  Sort of like how
> font preferences are handled.
We didn't want to support such a generic preference UI, in fact the idea is
to reduce the number of preferences. However, the current setup allows,
e.g. with a geek tool (which has yet to come ;-), to override every shared
preference for a concrete editor.

> And for E) API extensions, this is good if editors want to control
> what preference pages to show, but how about also offering other
> preference page creators to add their own preference pages.  This
> could be done through an extension point where you associate a
> preference page id to editor id.  The downside is this could lead to
> more clutter if there are a lot of preference page contributors.
Sounds like a good idea. I suggest to file a feature request with a use
case example


>
> Tom Eicher <eclipse@xxxxxxxxxxxxxxx>
> Sent by: platform-text-dev-admin@xxxxxxxxxxx
> 12/08/2004 10:35 AM
>
> Please respond to
> platform-text-dev
>
> To
>
> platform-text-dev@xxxxxxxxxxx
>
> cc
>
> Subject
>
> [platform-text-dev] Preference reorganization
>
>
>
>
> We have reorganized the preferences and the preference pages in text
> land quite a bit, which will be of interest to editor implementors,
> especially those that have been matching the text and java editor or
> even have been using their preferences.
>
>
> Here we go:
>
> A) Removed Preferences (in the text & java editors):
> - Show overview ruler (overview ruler is always shown)
>
>
> B) Shared Preferences
> Some settings have been made shared, e.g. the settings are configured on
> the new 'All Text Editors' preference page and apply to all text based
> editors such as Java, Text, Properties files...:
>
> - All previous text editor settings:
>   - highlight current line (+color)
>   - print margin (+ color + column)
>   - show line numbers (+ color)
>   - selection fore- and background colors
>   - displayed tab width
>
> - All accessibility settings (moved to their own page):
>   - use custom caret (+ thick caret)
>   - quick diff character mode
>
> In a custom editor implementation you may or may not respect the shared
> preferences. If you do, you can remove all references on your preference
> pages and also from your code if:
> -  you inherit from AbstractDecoratedTextEditor, and
> -  you use a CombinedPreferenceStore to read preferences from your own
> preference store, but also from the preference store of the
> org.eclipse.ui.editors preference store. See
> JavaPlugin.getCombinedPreferenceStore for an example.
>
> If you want to keep rolling your own editor-specific preferences, that's
> fine as well - but you may have to hide some property change events from
> your editor's super class (JavaEditor does that for the 'displayed tab
> width' value).
>
>
> C) Moved & Shared Preferences
>
> Some settings previously only available in the Java editor have been
> pushed down to text land and made shared preferences.
>
> - hyperlink navigation (+ colors + modifier)
>    This is a bigger issue as the hyperlink navigation framework has
> been pushed down to text.
>    See the build notes.
> - editor fore- and background colors - disable overwrite mode
>
>
> D) Behavioral changes
>
> - Show quickdiff and Enable Folding now are global settings, no longer
> "defaults for new editors". So changing the preference (which you can
> also do from the ruler context menu now) is immediately reflected in all
> open editors.  This change is still being debated over.
>
> - AbstractDecoratedTextEditor now includes a 'Toggle Quick Diff' action
> in its set of pre-installed actions. There is no need any longer for you
> to contribute such an action to get in enabled per default.
>
>
> E) API extensions
>
> AbstractDecoratedTextEditor shows a 'Preferences...' action in both its
> context and ruler context menus. Once the preference page supports
> filtering, only a subset of 'interesting' pages will be displayed in the
> such opened preference dialog. You can change the set of pages by
> extending or replacing
> AbstractDecoratedTextEditor.collectContextMenuPreferencePages.
>
>
> _______________________________________________
> platform-text-dev mailing list
> platform-text-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-text-dev