Community
Participate
Working Groups
In order to provide a more generic zoom implementation, it would be good to create an interface that allows to access the font definition (as named in theme and JFaceResources.getFontRegstry) and to have most text-based parts/page implement this interface or adapt to it. The interface would only contain a "getFontPropertyName" method. Identified implementations/adapters would be AbstractTextEditor, TextConsole, CompareEditor...)
We're past API Freeze, so it's probably not going to happen for 4.6. Targetting 4.7.
Too late for 4.7, and it's currently far away in my todo list for me to commit on implementing it soon enough. Removing target in general. If anyone else wants to work on it, feel free, that would be welcome.
(In reply to Mickael Istria from comment #0) > In order to provide a more generic zoom implementation, it would be good to > create an interface that allows to access the font definition (as named in > theme and JFaceResources.getFontRegstry) and to have most text-based > parts/page implement this interface or adapt to it. > The interface would only contain a "getFontPropertyName" method. > > Identified implementations/adapters would be AbstractTextEditor, > TextConsole, CompareEditor...) Presumably it should be a getFontPropertyNames() method (plural), to cater to parts using different fonts. Or perhaps the zoom implementation should just change all fonts that can be set via preferences--not sure if that might be too expensive. (And it would also affect dialog fonts and navigators and whatnot... if the idea was to zoom really only text viewer fonts, then some adapter mechanism might make sense, or would there be a way to base it not on workbench parts but on TextViewers?)
(In reply to Thomas Wolf from comment #3) > Presumably it should be a getFontPropertyNames() method (plural), to cater > to parts using different fonts. +1 > Or perhaps the zoom implementation should just change all fonts that can be set via preferences--not sure if that might be too expensive. (And it would also affect dialog fonts and navigators and whatnot...) I'm not sure it's the desired behavior of a user doing Ctrl+ in a text editor, but that wouuld probably worth trying. The issue I foresee is that many views/dialogs and so on won't react immediately to font size change (as they don't place listeners on the registry), so some parts would react immediately, some other won't change and then closing and reopening the parts would show the font size changed. It doesn't sound very nice for end-users. > if the idea was to zoom really only text viewer > fonts, then some adapter mechanism might make sense As we initiated this feature, the only real-life issue we were trying to fix is for people in conferences, showing code, who where forced to get to the preference page to make the code readable to the audience. So yes, Text Editor was the main and only target initially. Now, it seems like some other views such as Console are valid targets as well. > or would there be a way > to base it not on workbench parts but on TextViewers?) That would be nice, but I believe the TextViewer is one layer too low to interact with the theme directly.