-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
39ad0c6
to
bf35c62
Compare
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
bf35c62
to
6e71149
Compare
There was a problem hiding this 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great work!
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) |
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. |
Thanks for reviewing! Merging this one... |
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! |
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):
(Myself, I don't have strong opinions one way or another on this topic.) |
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 There is also the discussion in the (unmerged?) apache/netbeans#3414 |
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 ( |
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 |
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:
Changes since the previous PR: