Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SVG icon Illustrator file, scripts, and README #67

Merged
merged 1 commit into from
Jul 26, 2024

Conversation

eirikbakke
Copy link
Contributor

@eirikbakke eirikbakke commented Jul 25, 2024

This is a revised version of apache/netbeans#7465 , now moved to the netbeans-tools repository. See the list of changes further below. This latest version of the script was tested successfully in its new location.

Details:

  • Add a README file which documents the process for drawing and installing scalable SVG versions of the many old bitmap icons that are present in the NetBeans UI.
  • Add the Adobe Illustrator file with the around 70 icons that have been drawn to date. This Illustrator file also contains template artboards for icons that should be prioritized in the future. (For people who don't have Illustrator, it's possible to view this file in Inkscape. Use Inkscape 1.2 or above, which has multi-page support.)
  • Add the script, IconTasks that was used to find, organize, and install icons. A path to a checked-out NetBeans repo must be provided.
  • The IconTasks scripts can generate a HTML page summary of the icon. This HTML page will reference icons in the NetBeans repo. A static snapshot of the HTML page can be found here: https://people.csail.mit.edu/ebakke/misc/netbeans-icons-240612.html

Changes since the previous PR:

  • Add a command-line parameter to the script to point to the NetBeans source repository directory.
  • Update instructions in the README to reflect the new directory structure and command-line argument needed.
  • Add more print statements to explain what the script is doing and which files are being read and written.
  • Remove the PDF preview of the Illustrator file as suggested, instead mentioning in the README that users without Illustrator can use Inkscape to see the AI file contents.
  • Don't check in the icons.html file, since it must exist in the NetBeans repo (to reference images), and will change when regenerated in any case. There's a static snapshot of it available here for those who just want to take a look.

Details:
* Add a README file which documents the process for drawing and installing scalable SVG versions of the many old bitmap icons that are present in the NetBeans UI.
* Add the Adobe Illustrator file with the around 70 icons that have been drawn to date. This Illustrator file also contains template artboards for icons that should be prioritized in the future. (For people who don't have Illustrator, it's possible to view this file in Inkscape. Use Inkscape 1.2 or above, which has multi-page support.)
* Add the script, IconTasks that was used to find, organize, and install icons. A path to a checked-out NetBeans repo must be provided.
* The IconTasks scripts can generate a HTML page summary of the icon. This HTML page will reference icons in the NetBeans repo. A static snapshot of the HTML page can be found here:
  https://people.csail.mit.edu/ebakke/misc/netbeans-icons-240612.html
Copy link
Contributor

@matthiasblaesing matthiasblaesing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks sane to me.

Copy link
Member

@mbien mbien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great work!

@mbien
Copy link
Member

mbien commented Jul 26, 2024

this is quite some work to keep track of all the duplicates. I am wondering if it would make sense to work towards having one shared icon resource module or to stick to the current module-local resource configuration.

(edit: also if someone ever wanted to create alternative icon sets for NB, the single module solution would be probably easier to work with)

@eirikbakke
Copy link
Contributor Author

I am wondering if it would make sense to work towards having one shared icon resource module or to stick to the current module-local resource configuration.

I remember there was some discussion of this in the past; it could be relevant again now. The main objection was the modularity concern, where it's undesirable to have a single module that every other module has to depend on. An optional service provider module that provides alternative icons for icons loaded via ImageUtilities could be an idea. Though each module would then still need to carry one copy of each used icon as a default.

@eirikbakke
Copy link
Contributor Author

Thanks for reviewing! Merging this one...

@mbien
Copy link
Member

mbien commented Jul 26, 2024

The main objection was the modularity concern, where it's undesirable to have a single module that every other module has to depend on

don't nearly all modules which do UI also already depend on NB's window system API?

the question is what are the practical disadvantages since webstart days when every kb mattered are no more. But yes modules very often lead to duplicated efforts (copy and pasted code... icons).

This could still end up being modular if it turns out the image resource module is large enough so that splitting it to categories or something like that would make sense. But if it ends up being < 1mb I don't think any platform app would care.

I don't want to distract from the efforts here, its great to see that the icons-refresh project is still active!

@eirikbakke eirikbakke merged commit f1ef48e into apache:master Jul 26, 2024
@eirikbakke
Copy link
Contributor Author

Here was @jtulach's comment on the mailing list from 2017-03-06 (I can't find an online version of the thread to link to):

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.

(Myself, I don't have strong opinions one way or another on this topic.)

@neilcsmith-net
Copy link
Member

If only NetBeans had been built with a concept like layers or service providers to allow decoupling of these things! 😜

You need a central point for icon loading, which we already do in ImageUtilities. But that does not mean the central point has to provide the icons itself, just make use of registered icon services. You'd have modules requesting a logical icon (with some specificity hierarchy, similar to XDG icon naming) and have icon service providers return a suitable icon. The current module icons could even be registered as providers of last resort. I said exactly this in the thread quoted there in 2017, which is at https://lists.apache.org/thread/9qb0hl9lo17pk6s5tobpoq95mz8vc09b by the way. It's just a lot of work to implement when there is ahead of time resistance to the approach!

There is also the discussion in the (unmerged?) apache/netbeans#3414

@mbien
Copy link
Member

mbien commented Jul 26, 2024

Here was jtulach's comment on the mailing list from 2017-03-06 (I can't find an online version of the thread to link to):

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.

I don't think icons give the same promises as API/code does. An icon would have an UID (e.g a name) and promise that it visualizes something specific, like an open folder. The only promise there is that the shared module would not be able to remove icons and that the thing it visualizes does not change, thats it.

Even if we wanted to remove icons, we would change the namespace and continue with a new module. Basically all problems code would have, do not exist with simple resources like icons, since an app could even depend on both shared modules at once, the deprecated one and the new one until everything moved on. With API you can't do that in most cases since in it would break right away.

So the API contract doesn't really exist there in my opinion since icons are not code.

The actual implementation would also not require that everything would have to declare a direct dependency to the shared icon module - it would be a transitive dependency hidden behind a simple API (getIcon(UID)).

@neilcsmith-net
Copy link
Member

it would be a transitive dependency hidden behind a simple API (getIcon(UID)).

Yes, like https://bits.netbeans.org/22/javadoc/org-openide-util-ui/org/openide/util/ImageUtilities.html

We already have the API there. It's just expanding the notion of resource in a backwards compatible way? There is also a slight issue with that class and service loading IIRC - came up in the integration of SVG support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants