Bugzilla – Full Text Bug Listing
| Summary: | Allow to use SymbolImageDescriptor in plugin.xml and e4 model fragments | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | laeubi, Lars.Vogel, mistria |
| Version: | 4.17 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=501491 | ||
| Whiteboard: | |||
| Bug Depends on: | 568194 | ||
| Bug Blocks: | |||
|
Description
Lars Vogel
I could provide the URI Handler but I'm not very familiar with the E4 / Plugin Editor part to judge how hard it would be to implement there. To implement that without having to add new fields to extension point, I think there are mostly 2 places to augment: * ResourceLocator.imageDescriptorFromBundle(...) should be able to take some description of the icon as input, and not only a path. The description of the icon could be directly 1 character (could be an emoji) and would be rendered with the default font for the context; or could be something more tricky like character[font-name]. * ImageDescriptor.createFromURL(...) could also support a new URL scheme such as character://font-name/character So it's all about adding conventions, which isn't trivial. It should probably be audited first how many extension point in Eclipse SDK take an icon or image as input; as it might be easier to just change all extension point schemas and consumers... (In reply to Christoph Laeubrich from comment #1) > I could provide the URI Handler but I'm not very familiar with the E4 / > Plugin Editor part to judge how hard it would be to implement there. The icon url can be manually set, so if the URI is supported at runtime that is fine. It seems that the "resource" type of plugin.xml only supports resources in the bundle and not urls. That would be nice anyways and should be possible without the need to change any extension points. to support this best, createResource(...) should be available for extension-points like it is for createExecutableExtension(...) for elements of type class About E4: sure one can input URLs by hand but I think users would be much more addicted to use this if there is a supporting dialog like the image selection, having a list of symbol names similar to [1], [2], [3], [4]... and i can search for example for 'cloudy' and get all matching symbols with a preview to simply select it. [1] https://en.wikipedia.org/wiki/Unicode_symbols [2] https://en.wikipedia.org/wiki/Miscellaneous_Symbols [3] https://unicode.org/emoji/charts/full-emoji-list.html [4] https://unicode.org/emoji/charts/full-emoji-modifiers.html (In reply to Christoph Laeubrich from comment #4) > About E4: sure one can input URLs by hand but I think users would be much > more addicted to use this if there is a supporting dialog like the image > selection, having a list of symbol names similar to [1], [2], [3], [4]... > and i can search for example for 'cloudy' and get all matching symbols with > a preview to simply select it. Definitely. Once this is supported at runtime we should enhance the editor to do auto-selection. The selection dialog itself is basically only SWT and JFace so I don't think there is a lot of special knowledge required to enhance it. One "watch out" is that our first attempt of using unicode as "icons" resulted in different rendering issues on different platforms. See Bug 501491. Of course it always depends. To make things looks similar we need at least some kind of logical-fonts as suggested in Bug 568520. Even better would be if we would have some cross-platform fonts available for this particular purpose, Mickael already state that SWT seems not the right place for this, but maybe Jface can have such thing and its not very complex to archive beside that wee need to negotiate with EMO what font-license would be compatible with EPL. (In reply to Christoph Laeubrich from comment #7) > maybe Jface can have such thing and its not very > complex to archive beside that wee need to negotiate with EMO what > font-license would be compatible with EPL. I still think JFace is some widget-logic (or more specifically some MVC or other patterns to manipulate widgets), while the fonts to include and the image to show are more part of application logic and would make more sense in Platform UI Workbench for instance. The problem is: The higher in the stack you place things the harder it is to use them. of course one can argue that the user can simply install a nice font into his system... There are so much valuable things in "platform" that simply can't be reused (e.g. in plain RCP apps) because they are exclusively crafted for platform use an one has to pull in a myriad of conflicting dependencies. But anyways I'm just sharing some ideas how it could work and if including a few bytes a binary resource would improve usefulness, why not? :-) (In reply to Christoph Laeubrich from comment #9) > But anyways I'm just sharing some ideas how it could work and if including a > few bytes a binary resource would improve usefulness, why not? :-) It basically breaks the design of SWT (and JFace) which is about delegating things to native toolkit while *enabling( customization; so it introduce a design inconsistency which will lead to more expensive maintenance issue down the road. Separation of concerns allows to scale well. For the same reason, we don't put in JFace the Platform images for new files, folders, copy... They do not fit the purpose of SWT or JFace, they fit the purpose of its consumer: the Eclipse workbench, so they're in the workbench and maintained by the workbench without impacting users of plain SWT/JFace. And that's fortunate, because if you look at other successful SWT apps that don't use the workspace, they're very happy to not see 20 years-old icons in their applications! SWT/JFace are about integrating with the OS and adding customization capabilities to consumers; they're not to become a fonts/images/color... gallery; as those are really depending on the application. Just the fact that a (common) font or icon is included does not mean it must be used by an application and in fact JFace does include some icons already [1], it includes some "logical fonts" including names for fonts of operation system that one can really call a 'maintenance nightmare' as most probably none of the comitter has still access to these platforms, and soon there will be people that even have never heard of them. What you call strength I would call weakness, SWT/JFace is just a software-dinosaur and its inability to adapt to modern technologies simply hinders innovations. One of the things why I rarely would use SWT and happy in the same sentence from a developers point of view ;-) Anyways it will still work to include some font some where else in any other platform repository that can then be used to have font-icons look similar across platforms. [1] eclipse.platform.ui/bundles/org.eclipse.jface/icons/full |