You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Emilian Bold <em...@gmail.com> on 2017/03/06 12:58:35 UTC
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/retina/php/4
I wonder if it wouldn't be better to have some set of icons in a central
place and then reused.
For example, IntelliJ has the auto-generated AllIcons class
https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/icons/AllIcons.java
This allows you to use an icon programatically, without actually knowing
the resource path and without copying it in your module:
AllIcons.General.NotificationWarning
All the icons are in
https://github.com/JetBrains/intellij-community/tree/master/platform/icons/src
Having some unique icons for generic file types, actions and other
'subjects' would really help with branding and would be appreciated by
plugin writers too. It would also unify the look of the application.
Speaking of branding, moving icons might be a problem. The icon path and
name is a public API of sort and if we just change the code to use some
other resource, all the existing branding is ignored.
--emi
Re: Icons cleanup
Posted by Jaroslav Tulach <ja...@oracle.com>.
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 duplicated icons in the code base isn't nice. In a discussion
with Jirka (few years ago) I offered "copy-during-build" solution - have the
icon only once in the Hg/Git repo, but copy it into private space when doing
the build. That doesn't impose any backward compatibility restrictions and
avoids duplication.
My 2 Kč.
-jt
On pondělí 6. března 2017 14:58:35 CET Emilian Bold wrote:
> 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/retina/php/4
>
> I wonder if it wouldn't be better to have some set of icons in a central
> place and then reused.
>
> For example, IntelliJ has the auto-generated AllIcons class
> https://github.com/JetBrains/intellij-community/blob/master/platform/util/sr
> c/com/intellij/icons/AllIcons.java
>
> This allows you to use an icon programatically, without actually knowing
> the resource path and without copying it in your module:
> AllIcons.General.NotificationWarning
>
> All the icons are in
> https://github.com/JetBrains/intellij-community/tree/master/platform/icons/s
> rc
>
> Having some unique icons for generic file types, actions and other
> 'subjects' would really help with branding and would be appreciated by
> plugin writers too. It would also unify the look of the application.
>
> Speaking of branding, moving icons might be a problem. The icon path and
> name is a public API of sort and if we just change the code to use some
> other resource, all the existing branding is ignored.
>
> --emi
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/
@StaticResource was: Icons cleanup
Posted by Jaroslav Tulach <ja...@oracle.com>.
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: Icons cleanup
Posted by Wade Chandler <wa...@apache.org>.
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 first before judging
either pattern over the other along with weighting use cases. The NB RCP is
exactly about making domain specific apps, so if something in the platform
can help solve that problem in a common way, that would be useful if it is
a clean pattern in my opinion.
Wade
On Mar 6, 2017 10:35 AM, "Emilian Bold" <em...@gmail.com> wrote:
> 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
This is ingenious but a bit complicated. I wouldn't want it for all the
icons of the Platform modules. A static class like the IntelliJ AllIcons
would be sufficient for icons like warning, print, new, file, folder, etc.
For something more domain-specific it makes sense to have a design like
this.
On Mon, Mar 6, 2017 at 4:19 PM, Wade Chandler <wa...@apache.org>
wrote:
> 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
> proper if others agree after review etc? Jarda, did you all look at such
an
> approach before?
>
> Thanks,
>
> Wade
>
>
>
> > 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
> >
> >
> > Am 06.03.2017 um 14:11 schrieb Gaurav Gupta:
> >> 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
> >> <https://twitter.com/intent/follow?original_referer=https%
> 3A%2F%2Fabout.twitter.com%2Fresources%2Fbuttons&ref_src=
> twsrc%5Etfw®ion=follow_link&screen_name=jpamodeler&tw_p=followbutton>
> >> <http://jpamodeler.github.io/> <https://www.youtube.com/JPAModeler>
> >>
> >>
> >>
> >>
> >> On Mon, Mar 6, 2017 at 6:28 PM, Emilian Bold <em...@gmail.com>
> wrote:
> >>
> >>> 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/retina/php/4
> >>>
> >>> I wonder if it wouldn't be better to have some set of icons in a
> central
> >>> place and then reused.
> >>>
> >>> For example, IntelliJ has the auto-generated AllIcons class
> >>> https://github.com/JetBrains/intellij-community/blob/
> >>> master/platform/util/src/com/intellij/icons/AllIcons.java
> >>>
> >>> This allows you to use an icon programatically, without actually
> knowing
> >>> the resource path and without copying it in your module:
> >>> AllIcons.General.NotificationWarning
> >>>
> >>> All the icons are in
> >>> https://github.com/JetBrains/intellij-community/tree/
> >>> master/platform/icons/src
> >>>
> >>> Having some unique icons for generic file types, actions and other
> >>> 'subjects' would really help with branding and would be appreciated by
> >>> plugin writers too. It would also unify the look of the application.
> >>>
> >>> Speaking of branding, moving icons might be a problem. The icon path
> and
> >>> name is a public API of sort and if we just change the code to use
some
> >>> other resource, all the existing branding is ignored.
> >>>
> >>> --emi
> >>>
> >>
> >
> > --
> > http://blog.nigjo.de/netbeans
> >
>
>
Re: Icons cleanup
Posted by Wade Chandler <wa...@apache.org>.
Agree with this.
Wade
On Mar 6, 2017 10:35 AM, "Emilian Bold" <em...@gmail.com> 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 common icons they could reuse / brand.
Re: Icons cleanup
Posted by Emilian Bold <em...@gmail.com>.
> 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 module establishes an API contract between
the
providing and using module. Not many providers were willing to accept
backward
compatibility constraints of such contracts.
Yes, but then again, any icon establishes an API from a branding
perspective which I don't find very good as you become stuck.
> 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
This is ingenious but a bit complicated. I wouldn't want it for all the
icons of the Platform modules. A static class like the IntelliJ AllIcons
would be sufficient for icons like warning, print, new, file, folder, etc.
For something more domain-specific it makes sense to have a design like
this.
--emi
On Mon, Mar 6, 2017 at 4:19 PM, Wade Chandler <wa...@apache.org>
wrote:
> 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
> proper if others agree after review etc? Jarda, did you all look at such an
> approach before?
>
> Thanks,
>
> Wade
>
>
>
> > 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
> >
> >
> > Am 06.03.2017 um 14:11 schrieb Gaurav Gupta:
> >> 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
> >> <https://twitter.com/intent/follow?original_referer=https%
> 3A%2F%2Fabout.twitter.com%2Fresources%2Fbuttons&ref_src=
> twsrc%5Etfw®ion=follow_link&screen_name=jpamodeler&tw_p=followbutton>
> >> <http://jpamodeler.github.io/> <https://www.youtube.com/JPAModeler>
> >>
> >>
> >>
> >>
> >> On Mon, Mar 6, 2017 at 6:28 PM, Emilian Bold <em...@gmail.com>
> wrote:
> >>
> >>> 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/retina/php/4
> >>>
> >>> I wonder if it wouldn't be better to have some set of icons in a
> central
> >>> place and then reused.
> >>>
> >>> For example, IntelliJ has the auto-generated AllIcons class
> >>> https://github.com/JetBrains/intellij-community/blob/
> >>> master/platform/util/src/com/intellij/icons/AllIcons.java
> >>>
> >>> This allows you to use an icon programatically, without actually
> knowing
> >>> the resource path and without copying it in your module:
> >>> AllIcons.General.NotificationWarning
> >>>
> >>> All the icons are in
> >>> https://github.com/JetBrains/intellij-community/tree/
> >>> master/platform/icons/src
> >>>
> >>> Having some unique icons for generic file types, actions and other
> >>> 'subjects' would really help with branding and would be appreciated by
> >>> plugin writers too. It would also unify the look of the application.
> >>>
> >>> Speaking of branding, moving icons might be a problem. The icon path
> and
> >>> name is a public API of sort and if we just change the code to use some
> >>> other resource, all the existing branding is ignored.
> >>>
> >>> --emi
> >>>
> >>
> >
> > --
> > http://blog.nigjo.de/netbeans
> >
>
>
Re: Icons cleanup
Posted by Wade Chandler <wa...@apache.org>.
On Mar 8, 2017, at 07:50, Neil C Smith <ne...@googlemail.com> wrote:
>
> Hi,
>
> On 7 March 2017 at 11:58, Jens Hofschröer <ap...@nigjo.de> 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 "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.
>
> Just catching up with this thread. This looks really interesting, and
> similar to something I've been thinking, around splitting up resource
> IDs and how they're provided, and making this all pluggable to support
> non-file / non-bitmap icon providers, etc.
>
> My thoughts possibly have two differences -
>
> 1) Splitting out the idea of resourceID from resource, such that a
> module can register as a provider of a resourceID and/or as a
> consumer, but that they are separate things.
>
> 2) Multiple resourceIDs, arranged from specific to general, a bit like
> CSS font-variant.
>
> For example, the platform base might specify that all icon providers
> have to provide a certain core set of icons. A module might request
> an icon for -
>
> "open-maven-project", "open-java-project", "open-project", "open-folder", "open"
>
> where "open" is a required icon, and the icon provider provides the
> most specific icon it has.
>
> Apologies if that's a use pattern that's covered and I missed it.
>
Yes, these are some of the sorts of things I’m thinking. The path to a specific resource itself isn’t as simple, and the branding could probably be much simplified with some better nuances. This can more easily support a notion of the “right size at the right time” without having to have a specific preset image for each pattern and path combination etc which ties into DPI etc as mentioned by Jens. I don’t think this is as easily supported by the platform today.
Wade
Re: Icons cleanup
Posted by Neil C Smith <ne...@googlemail.com>.
On 8 March 2017 at 12:50, Neil C Smith <ne...@googlemail.com> 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 - www.praxislive.org
Re: Icons cleanup
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
On 7 March 2017 at 11:58, Jens Hofschröer <ap...@nigjo.de> 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 "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.
Just catching up with this thread. This looks really interesting, and
similar to something I've been thinking, around splitting up resource
IDs and how they're provided, and making this all pluggable to support
non-file / non-bitmap icon providers, etc.
My thoughts possibly have two differences -
1) Splitting out the idea of resourceID from resource, such that a
module can register as a provider of a resourceID and/or as a
consumer, but that they are separate things.
2) Multiple resourceIDs, arranged from specific to general, a bit like
CSS font-variant.
For example, the platform base might specify that all icon providers
have to provide a certain core set of icons. A module might request
an icon for -
"open-maven-project", "open-java-project", "open-project", "open-folder", "open"
where "open" is a required icon, and the icon provider provides the
most specific icon it has.
Apologies if that's a use pattern that's covered and I missed it.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Icons cleanup
Posted by Jens Hofschröer <ap...@nigjo.de>.
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/
Re: Icons cleanup
Posted by Wade Chandler <wa...@apache.org>.
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 proper if others agree after review etc? Jarda, did you all look at such an approach before?
Thanks,
Wade
> 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
>
>
> Am 06.03.2017 um 14:11 schrieb Gaurav Gupta:
>> 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
>> <https://twitter.com/intent/follow?original_referer=https%3A%2F%2Fabout.twitter.com%2Fresources%2Fbuttons&ref_src=twsrc%5Etfw®ion=follow_link&screen_name=jpamodeler&tw_p=followbutton>
>> <http://jpamodeler.github.io/> <https://www.youtube.com/JPAModeler>
>>
>>
>>
>>
>> On Mon, Mar 6, 2017 at 6:28 PM, Emilian Bold <em...@gmail.com> wrote:
>>
>>> 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/retina/php/4
>>>
>>> I wonder if it wouldn't be better to have some set of icons in a central
>>> place and then reused.
>>>
>>> For example, IntelliJ has the auto-generated AllIcons class
>>> https://github.com/JetBrains/intellij-community/blob/
>>> master/platform/util/src/com/intellij/icons/AllIcons.java
>>>
>>> This allows you to use an icon programatically, without actually knowing
>>> the resource path and without copying it in your module:
>>> AllIcons.General.NotificationWarning
>>>
>>> All the icons are in
>>> https://github.com/JetBrains/intellij-community/tree/
>>> master/platform/icons/src
>>>
>>> Having some unique icons for generic file types, actions and other
>>> 'subjects' would really help with branding and would be appreciated by
>>> plugin writers too. It would also unify the look of the application.
>>>
>>> Speaking of branding, moving icons might be a problem. The icon path and
>>> name is a public API of sort and if we just change the code to use some
>>> other resource, all the existing branding is ignored.
>>>
>>> --emi
>>>
>>
>
> --
> http://blog.nigjo.de/netbeans
>
Re: Icons cleanup
Posted by Javier Ortiz <ja...@gmail.com>.
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
Posted by Jens Hofschröer <em...@nigjo.de>.
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
Am 06.03.2017 um 14:11 schrieb Gaurav Gupta:
> 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
> <https://twitter.com/intent/follow?original_referer=https%3A%2F%2Fabout.twitter.com%2Fresources%2Fbuttons&ref_src=twsrc%5Etfw®ion=follow_link&screen_name=jpamodeler&tw_p=followbutton>
> <http://jpamodeler.github.io/> <https://www.youtube.com/JPAModeler>
>
>
>
>
> On Mon, Mar 6, 2017 at 6:28 PM, Emilian Bold <em...@gmail.com> wrote:
>
>> 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/retina/php/4
>>
>> I wonder if it wouldn't be better to have some set of icons in a central
>> place and then reused.
>>
>> For example, IntelliJ has the auto-generated AllIcons class
>> https://github.com/JetBrains/intellij-community/blob/
>> master/platform/util/src/com/intellij/icons/AllIcons.java
>>
>> This allows you to use an icon programatically, without actually knowing
>> the resource path and without copying it in your module:
>> AllIcons.General.NotificationWarning
>>
>> All the icons are in
>> https://github.com/JetBrains/intellij-community/tree/
>> master/platform/icons/src
>>
>> Having some unique icons for generic file types, actions and other
>> 'subjects' would really help with branding and would be appreciated by
>> plugin writers too. It would also unify the look of the application.
>>
>> Speaking of branding, moving icons might be a problem. The icon path and
>> name is a public API of sort and if we just change the code to use some
>> other resource, all the existing branding is ignored.
>>
>> --emi
>>
>
--
http://blog.nigjo.de/netbeans
Re: Icons cleanup
Posted by Jens Hofschröer <ap...@nigjo.de>.
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
Am 06.03.2017 um 14:11 schrieb Gaurav Gupta:
> 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
> <https://twitter.com/intent/follow?original_referer=https%3A%2F%2Fabout.twitter.com%2Fresources%2Fbuttons&ref_src=twsrc%5Etfw®ion=follow_link&screen_name=jpamodeler&tw_p=followbutton>
> <http://jpamodeler.github.io/> <https://www.youtube.com/JPAModeler>
>
>
>
>
> On Mon, Mar 6, 2017 at 6:28 PM, Emilian Bold <em...@gmail.com> wrote:
>
>> 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/retina/php/4
>>
>> I wonder if it wouldn't be better to have some set of icons in a central
>> place and then reused.
>>
>> For example, IntelliJ has the auto-generated AllIcons class
>> https://github.com/JetBrains/intellij-community/blob/
>> master/platform/util/src/com/intellij/icons/AllIcons.java
>>
>> This allows you to use an icon programatically, without actually knowing
>> the resource path and without copying it in your module:
>> AllIcons.General.NotificationWarning
>>
>> All the icons are in
>> https://github.com/JetBrains/intellij-community/tree/
>> master/platform/icons/src
>>
>> Having some unique icons for generic file types, actions and other
>> 'subjects' would really help with branding and would be appreciated by
>> plugin writers too. It would also unify the look of the application.
>>
>> Speaking of branding, moving icons might be a problem. The icon path and
>> name is a public API of sort and if we just change the code to use some
>> other resource, all the existing branding is ignored.
>>
>> --emi
>>
>
Re: Icons cleanup
Posted by Gaurav Gupta <ga...@gmail.com>.
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
<https://twitter.com/intent/follow?original_referer=https%3A%2F%2Fabout.twitter.com%2Fresources%2Fbuttons&ref_src=twsrc%5Etfw®ion=follow_link&screen_name=jpamodeler&tw_p=followbutton>
<http://jpamodeler.github.io/> <https://www.youtube.com/JPAModeler>
On Mon, Mar 6, 2017 at 6:28 PM, Emilian Bold <em...@gmail.com> wrote:
> 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/retina/php/4
>
> I wonder if it wouldn't be better to have some set of icons in a central
> place and then reused.
>
> For example, IntelliJ has the auto-generated AllIcons class
> https://github.com/JetBrains/intellij-community/blob/
> master/platform/util/src/com/intellij/icons/AllIcons.java
>
> This allows you to use an icon programatically, without actually knowing
> the resource path and without copying it in your module:
> AllIcons.General.NotificationWarning
>
> All the icons are in
> https://github.com/JetBrains/intellij-community/tree/
> master/platform/icons/src
>
> Having some unique icons for generic file types, actions and other
> 'subjects' would really help with branding and would be appreciated by
> plugin writers too. It would also unify the look of the application.
>
> Speaking of branding, moving icons might be a problem. The icon path and
> name is a public API of sort and if we just change the code to use some
> other resource, all the existing branding is ignored.
>
> --emi
>