Re: @StaticResource was: Icons cleanup

On Mar 8, 2017, at 09:34, Jens Hofschröer wrote: > > Am 07.03.2017 um 14:58 schrieb Jaroslav Tulach: >> Please note that there already is a safe way to access icons by a key - it is >> the resource path. > Yes. And this ended up with a lot of PNG images named "*.gif". This only > worked since th

Re: Icons cleanup

On Mar 8, 2017, at 07:50, Neil C Smith wrote: > > Hi, > > On 7 March 2017 at 11:58, Jens Hofschröer wrote: >> https://github.com/nigjo/NBResourceManager >> >> this is only a quick attempt to outline the idea. Some parts are not finally >> done. >> >> - All (icon) resources are registered via

Re: Icons cleanup

On 8 March 2017 at 12:50, Neil C Smith wrote: > 2) Multiple resourceIDs, arranged from specific to general, a bit like > CSS font-variant. By which I of course meant font-family! Neil -- Neil C Smith Artist & Technologist www.neilcsmith.net Praxis LIVE - hybrid visual IDE for creative coding

Re: @StaticResource was: Icons cleanup

Am 07.03.2017 um 14:58 schrieb Jaroslav Tulach: Please note that there already is a safe way to access icons by a key - it is the resource path. Yes. And this ended up with a lot of PNG images named "*.gif". This only worked since the ImageIO does not care about name extentions. I don't think

Re: Icons cleanup

Hi, On 7 March 2017 at 11:58, Jens Hofschröer wrote: > https://github.com/nigjo/NBResourceManager > > this is only a quick attempt to outline the idea. Some parts are not finally > done. > > - All (icon) resources are registered via XML Layer > - The "resourcePath" Attribute can be done as "met

@StaticResource was: Icons cleanup

Please note that there already is a safe way to access icons by a key - it is the resource path. In addition to that there is http://bits.netbeans.org/8.2/javadoc/org-netbeans-api-annotations-common/org/ netbeans/api/annotations/common/StaticResource.html annotation which makes sure the icons a

Re: Icons cleanup

Hi Am 06.03.2017 um 15:19 schrieb Wade Chandler: This sounds like a good/interesting approach; resource IDs. Is this something you could put together as a simple RCP example and share on Github, less any other code? i.e. permission to share that specific module, and then maybe it could be loo

Re: Icons cleanup

Agree with this. Wade On Mar 6, 2017 10:35 AM, "Emilian Bold" wrote: > Single place for icons doesn't work well with respect to modularity. Sure, but the Platform is a self-contained entity. I don't believe Platform clients would mind having openide-icons or something like that with the most c

Re: Icons cleanup

It seems it would be good to be able to then override icons by key. Such a concept could also allow more unique mechanisms for looking up icons better matched to resolutions or relative sizes (small, medium, large) per resolutions automatically. I think it would be best to see some implementations

Re: Icons cleanup

> Single place for icons doesn't work well with respect to modularity. Sure, but the Platform is a self-contained entity. I don't believe Platform clients would mind having openide-icons or something like that with the most common icons they could reuse / brand. > Re-using icon from a different m

Re: Icons cleanup

Jens, This sounds like a good/interesting approach; resource IDs. Is this something you could put together as a simple RCP example and share on Github, less any other code? i.e. permission to share that specific module, and then maybe it could be looked at, and then perhaps merged into NB prope

Re: Icons cleanup

Why not using Lookup and an interface for this? The default icons should be auto registered allowing other modules to register or override.

Re: Icons cleanup

Hi We had a similar approach in our RCP with a central "resource module" but dismissed it. It running into having every application specific icon in this central repository whether it was needed or not in other parts of the application. We ended up with a "central registration" (we called it

Re: Icons cleanup

Hi We had a similar approach in our RCP with a central "resource module" but dismissed it. It running into having every application specific icon in this central repository whether it was needed or not in other parts of the application. We ended up with a "central registration" (we called it

Re: Icons cleanup

Single place for icons doesn't work well with respect to modularity. Re-using icon from a different module establishes an API contract between the providing and using module. Not many providers were willing to accept backward compatibility constraints of such contracts. Of course having duplica

Re: Icons cleanup

Hi Emilian, I have also observed , Many Icons are duplicated in different NetBeans modules. Central place for a Icon is great idea. So not only the platform module but also the NetBeans plugin can reuse it easily. +1 Thanks and kind regards, Gaurav Gupta

Icons cleanup

Hello, It seems to me the same icon is duplicated all over in NetBeans. For example the warning icon is: * twice here https://nextbeans.com/retina/websvccommon * at least twice here https://nextbeans.com/retina/platform/3 https://nextbeans.com/retina/platform/2 * again here https://nextbeans.com