Bug 483921 - A common interface for page/parts to declare used font definitions
Summary: A common interface for page/parts to declare used font definitions
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.5   Edit
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks: 483472 483877 507169
  Show dependency tree
 
Reported: 2015-12-08 10:57 EST by Mickael Istria CLA
Modified: 2017-09-11 06:33 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mickael Istria CLA 2015-12-08 10:57:43 EST
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...)
Comment 1 Mickael Istria CLA 2016-03-25 11:30:12 EDT
We're past API Freeze, so it's probably not going to happen for 4.6. Targetting 4.7.
Comment 2 Mickael Istria CLA 2017-03-08 08:40:37 EST
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.
Comment 3 Thomas Wolf CLA 2017-07-06 04:42:29 EDT
(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?)
Comment 4 Mickael Istria CLA 2017-07-06 04:59:30 EDT
(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.