Community
Participate
Working Groups
As suggested in Bug 567898 it would be nice to support "Font-Icon", that means that a symbol from a given font can be used as icon images in buttons/toolbars/menus and so on. The advantage is that these kind of images can scale to whatever size is requested when true-type fonts are used.
I'll provide a Gerrit for this as a first simple starting point.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/171215
Created attachment 284557 [details] Example Project Example Project to demonstrate usage
Created attachment 284558 [details] Example Screenshot with different states Find a Screenshot attached that shows a toolbar using symbol icons.
(In reply to Christoph Laeubrich from comment #4) > Created attachment 284558 [details] > Example Screenshot with different states > > Find a Screenshot attached that shows a toolbar using symbol icons. Do you plan to support this also in e4 application contributions via the icon uri in the model?
(In reply to Lars Vogel from comment #5) > Do you plan to support this also in e4 application contributions via the > icon uri in the model? this is not E4 specific, next step (if basic support is there) would be to add an URI handler to jface that support URLs of the following format: symbol-icon://😁@16px/<an optional font name>#FF0000 if that is done, maybe someone with E4-Editor skills can enhance the e4-model editor to even support this with a specialized dialog.
(In reply to Christoph Laeubrich from comment #6) > (In reply to Lars Vogel from comment #5) > > Do you plan to support this also in e4 application contributions via the > > icon uri in the model? > > this is not E4 specific, next step (if basic support is there) would be to > add an URI handler to jface that support URLs of the following format: > > symbol-icon://😁@16px/<an optional font name>#FF0000 That would be great. Please open a bug report for this, depending on this bug. > symbol-icon://😁@16px/ 16px is for the default font size? I would assume the font will adjust to the HDPI setting, correct? > if that is done, maybe someone with E4-Editor skills can enhance the > e4-model editor to even support this with a specialized dialog. This would be nice but low priority. Supporting font icons in toolbar would already be a big archivement even without a dialog to select it.
(In reply to Lars Vogel from comment #7) > > symbol-icon://😁@16px/ > > 16px is for the default font size? I would assume the font will adjust to > the HDPI setting, correct? Its the initial image size (font sizes are smaller but are dynamical calculated according to requested image size). The descriptor will adjust to any zoom factor requested. of course the 16px is not fixed as shown in attached screenshot that shows a toolbar with much larger image size.
@Lars, Add me to the cc if you want me to notice it. This looks nice. FYI, Nebula has FontAwesome support [1]. [1] https://wiki.eclipse.org/Nebula_FontAwesome
Before we go into increasing the amount of code in Platform for that, do we already have a real use-case in Platform for that? I think we need to avoid Platform to grow as a collection of unused APIs that make maintenance harder, and we should first have agreement on a use-case to consume the API inside Platform before providing it.
(In reply to Mickael Istria from comment #10) > Before we go into increasing the amount of code in Platform for that, do we > already have a real use-case in Platform for that? > I think we need to avoid Platform to grow as a collection of unused APIs This is chicken-egg. How can platform use it if it is not available? Let's meet midway an put it in internal so that we can at least start using it. > that make maintenance harder, and we should first have agreement on a > use-case to consume the API inside Platform before providing it. The use case is the move to native SVG support and eventually get rid of all that icon@2x complexity.
The class itself is already package private and only available through static factory methods (like for URLs and files). I don't know if there is an official "definition" or something like this for what platform is, but if I just take what generally is assumed to be a platform (something other people can build up and share common concepts) it makes sense to provide things that seems useful for a greater audience and even if (not yet) the platform code itself uses it it makes sense to offer it if there is larger interest, there's always a world outside Eclipse :-) Font-Based icons are just a de-factor standard in modern (web) UIs and JFace/SWT is in my opinion really lacking some basic features to create UIs that don't look like your stuck in the 90's... but maybe RCP was meant to mean Retro-Client-Platform anyways?! :-) This will become even more useful if we can convince SWT to provide some platform independent fonts, see Bug 568520 and yes SVG support is also on the list but this has become more complicated than I initially thought an thus will take some time, but this is independent from the SVG story IMO.
The change should at least at some unit tests.
(In reply to Wim Jongman from comment #11) > Let's meet midway an put it in internal so that we can at least start using > it. I disagree here. Let's just add it when it's necessary. Platform won't be healthier if it's just a library of untested code. As long as there is no consumer for it in Platform, it's better to remain on Gerrit, then consumers can already start building on top of the Gerrit patch; and we get everything merged at once when a user-story is better covered by this addition. (In reply to Christoph Laeubrich from comment #12) > I don't know if there is an official "definition" or something like this for > what platform is, but if I just take what generally is assumed to be a > platform (something other people can build up and share common concepts) it > makes sense to provide things that seems useful for a greater audience and > even if (not yet) the platform code itself uses it it makes sense to offer > it if there is larger interest, there's always a world outside Eclipse :-) Sure, but Platform as a project can difficulty cope with the trouble of all its extenders. The general rule is that Platform only hosts code it does consume ("dogfooding"), it's not supposed to be a library of random utility code that we don't have in the IDE any use-case for. > Font-Based icons are just a de-factor standard in modern (web) UIs and > JFace/SWT is in my opinion really lacking some basic features to create UIs > that don't look like your stuck in the 90's... but maybe RCP was meant to > mean Retro-Client-Platform anyways?! :-) I'm all for font-based icons; but here my concerns are not really the question of *what* can be API or not; but more of *how*. Something that is not used inside Platform (or JDT or PDE) is usually a sign that it's immature to become part of Platform. Now. whenever Platorm/JDT/PDE gets improved thanks to a new API, we can consider adding the API and the consume in a row.
(In reply to Mickael Istria from comment #14) > Now. whenever Platorm/JDT/PDE gets improved thanks to a new API, we can > consider adding the API and the consume in a row. I agree with your arguments, but can you explain how we can improve without providing the code first?
(In reply to Wim Jongman from comment #15) > I agree with your arguments, but can you explain how we can improve without > providing the code first? Concretely, please submit with this same Gerrit or as a new Gerrit some code consuming this new code to improve something Platform or JDT or PDE. If we get agreement on the value, then we can more easily consider adding the utility that enables it.
(In reply to Mickael Istria from comment #16) > (In reply to Wim Jongman from comment #15) > > I agree with your arguments, but can you explain how we can improve without > > providing the code first? > > Concretely, please submit with this same Gerrit or as a new Gerrit some code > consuming this new code to improve something Platform or JDT or PDE. If we > get agreement on the value, then we can more easily consider adding the > utility that enables it. Unit test and JFace snippet should be ok to submit it. I believe once we have that we can start writing more code to use it, e.g. in plugin.xml to define icons or in the e4 model
(In reply to Lars Vogel from comment #17) > Unit test and JFace snippet should be ok to submit it. I believe once we > have that we can start writing more code to use it, e.g. in plugin.xml to > define icons or in the e4 model FWIW, I disagree with that. If we start allowing any piece of code to get as API without having use-case for it in the Eclipse project, then we basically end up maintaining a collection of software pieces that we don't even know whether anyone use them. It's just going to grow the maintenance cost without demonstrating value. A consumer inside Eclipse project seems necessary to me if we want thing to keep healthy on long run. Most committers here can barely afford maintaining what we know is used, growing the list by adding APIs which may not be used would basically slow down the project development tremendously on mid-term.
(In reply to Lars Vogel from comment #17) > Unit test While I always try to add a unit-test whenever possible, its extremely hard to write one here as comparing an image of varying fonts is neither stable nor good to understand/debug and the SWT Image Interface is a real pain to test against as it uses native calls to retrieve pixel information that even vary on the same platform. But if anyone has an idea how to test this in an automated way I'll be happy to add a test of course.
I also agree that before accepting smth as API we should have gerrit with at least one (preferably few) usages so they can be seen in action . This is critical to solidify the API. E.g. for the unittest view (https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/171116) there is junit counterpart showing it in action (https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/171126) and a cdt one (https://github.com/vrubezhny/org.eclipse.unittest/tree/master/org.eclipse.unittest.cdt) and even a rust one (https://github.com/vrubezhny/corrosion/tree/rebased-unit-tesst-view). By doing that we have some confidence that we have taken wider usage criteria in account which still doesn't mean good API but it's at least a prereq. So what Mickael is asking here is showing such usages so we do not publish API that will have to be deprecated shortly after it's announced due to finding deficiencies when we start using it in real world.
I created Bug 568194 for the support of SymbolImageDescriptor in plugin.xml and the e4 model.
(In reply to Lars Vogel from comment #21) > I created xxxxxx for the support of SymbolImageDescriptor in plugin.xml > and the e4 model. That would be bug 568887
@Christoph: before we move on with this and have some consumers in Eclipse Platform and then can merge API; would you be interested in submitting this code as an example in org.eclipse.jface.snippets; so this code is in Platform and not "lost" on Gerrit and may be easier to retrieve later if we need it as API?
It seems there is not much interest in this.
