You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@oracle.com> on 2017/03/07 13:58:13 UTC
@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 are really where they should be when
building a module.
-jt
On úterý 7. března 2017 12:58:32 CET Jens Hofschröer wrote:
> 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 looked at, and then perhaps merged
> > into NB proper if others agree after review etc? Jarda, did you all look
> > at such an approach before?
> 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 "methodvalue" to allow
> complex resolving at runtime (decision made by OS, DPI, ...)
> - Layer entries are generated via a @ResourceRegistration annotation
> - A ResourceManager maps the resourceID to the actual resource path
> - Image loading is done by ImageUtilities class
>
> A sample module is attached and a Sample Dialog who displays all
> registered icons.
>
> Jens
>
> >> On Mar 6, 2017, at 08:29, Jens Hofschröer <em...@nigjo.de> wrote:
> >>
> >> 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 ResourceManager,
> >> like the UIManager of Swing) where every module can register its icons
> >> (with keys) so we can easy generate a overview dialog with all known
> >> resources. Other modules can access these icon via the resource key
> >>
> >> To use these resource keys within annotations and layer entries we
> >> registered an internal URI-Schema and URIResolver to map the keys to the
> >> "real" resource path.
> >>
> >> Greetings
> >> Jens Hofschröer
Re: @StaticResource was: Icons cleanup
Posted by Wade Chandler <wa...@apache.org>.
On Mar 8, 2017, at 09:34, Jens Hofschröer <ap...@nigjo.de> 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 the ImageIO does not care about name extentions.
>
> I don't think the path of a single file should be part of a modules API. You loose the ability to change or move the resource. With an ID you can change the icon as part of the Look&Feel or simply change the
> appearance of a folder icon in spite of the current user OS.
I agree with this, and to me this isn’t just about a static resource as much as a resource which is static at a particular context, which may have a specific rendering cached, but could provide different renderings depending on various factors including DPI etc, and could be re-obtained if contexts change; monitor unplugged, window moves to a new monitor etc. This is quite different from static resources, and can allow better scalability, and without having to understand all contexts ahead of time such as a 48x48 or 16x16 etc image.
>
>> In addition to that there is
>>
>> http://bits.netbeans.org/8.2/javadoc/org-netbeans-api-annotations-common/org/ <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 are really where they should be when
>> building a module.
> No complaint with this. We can change the @ResourceRegistration annotation to not use the field value as key than as the resource path and print a warning if @StaticResource is missing.
>
> Somthing like this:
>
> @StaticResource(relative = true)
> private static final String TEST_IMAGE = "images.png";
> @ResourceRegistration(resource = TEST_IMAGE)
> public static final String TEST_IMAGE_ID = "de.nigjo.nbm.rm.debugui.action";
>
> is hard to check for the processor since the "resource" parameter does not know about the other used field.
>
Yes, this would need some work I think because you’d want to hook into the actual static resource versus just its path right? Anyways, I may not be 100% understanding what you are wanting here, but it seems to give the key a resource link. I guess if it is a high enough resolution image it could be used by the mechanism to lookup a resource by ID could then scale it to various dimensions and resolution; is this perhaps some of the thought Jens?
Thanks,
Wade
Re: @StaticResource was: Icons cleanup
Posted by Jens Hofschröer <ap...@nigjo.de>.
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 the path of a single file should be part of a modules API.
You loose the ability to change or move the resource. With an ID you can
change the icon as part of the Look&Feel or simply change the
appearance of a folder icon in spite of the current user OS.
> 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 are really where they should be when
> building a module.
No complaint with this. We can change the @ResourceRegistration
annotation to not use the field value as key than as the resource path
and print a warning if @StaticResource is missing.
Somthing like this:
@StaticResource(relative = true)
private static final String TEST_IMAGE = "images.png";
@ResourceRegistration(resource = TEST_IMAGE)
public static final String TEST_IMAGE_ID =
"de.nigjo.nbm.rm.debugui.action";
is hard to check for the processor since the "resource" parameter does
not know about the other used field.
Jens
> -jt
>
> On �ter� 7. b\u0159ezna 2017 12:58:32 CET Jens Hofschr�er wrote:
>> 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 looked at, and then perhaps merged
>>> into NB proper if others agree after review etc? Jarda, did you all look
>>> at such an approach before?
>> 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 "methodvalue" to allow
>> complex resolving at runtime (decision made by OS, DPI, ...)
>> - Layer entries are generated via a @ResourceRegistration annotation
>> - A ResourceManager maps the resourceID to the actual resource path
>> - Image loading is done by ImageUtilities class
>>
>> A sample module is attached and a Sample Dialog who displays all
>> registered icons.
>>
>> Jens
>>
>>>> On Mar 6, 2017, at 08:29, Jens Hofschr�er <em...@nigjo.de> wrote:
>>>>
>>>> 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 ResourceManager,
>>>> like the UIManager of Swing) where every module can register its icons
>>>> (with keys) so we can easy generate a overview dialog with all known
>>>> resources. Other modules can access these icon via the resource key
>>>>
>>>> To use these resource keys within annotations and layer entries we
>>>> registered an internal URI-Schema and URIResolver to map the keys to the
>>>> "real" resource path.
>>>>
>>>> Greetings
>>>> Jens Hofschr�er
>
>
--
http://blog.nigjo.de/netbeans/