[GitHub] [netbeans] timboudreau commented on issue #1278: [NETBEANS-2604] Support SVG icon loading from ImageUtilities

[GitBox <gi...@apache.org>]

timboudreau commented on issue #1278: [NETBEANS-2604] Support SVG icon loading from ImageUtilities
URL: https://github.com/apache/netbeans/pull/1278#issuecomment-539623163
 
 
   > I'm not very familiar with the clusters system--could you explain how to
   > do this? Is this different from what I started with in the first version of
   > this PR? For that version, @JaroslavTulach
   > <https://github.com/JaroslavTulach> objected that new libraries were
   > ending up in netbeans/platform/lib, which was undesirable. That included
   > libraries that were previously already in the ide cluster (
   > o.apache.commons.io and o.apache.commons.logging).
   >
   The cluster system actually dates back to Sun's architecture review
   requirements - but it is a generally good idea.  The idea - driven by
   requirements from Solaris - was that an application should only install ONE
   copy of any shared libraries on a system; and Sun was building multiple
   products on top of NetBeans.  So if there were two NetBeans-based
   applications on a system, there should only be one copy of, say, the
   platform modules or the editor modules, which both applications simply use
   as "clusters" of libraries.  So the cluster system was invented - carve the
   IDE and platform into chunks of relatied (and interdependent)
   functionality, such that inter-cluster dependencies are unidirectional and
   you - a directed graph.
   
   In practice, in terms of people installing multiple copies of software on
   systems, I don't think that is an enormous concern these days (this was
   back in the era of thin-clients, so a "system" was likely big iron and the
   "desktop" was a remote X connection).  But it forces us to think about both
   macro-level dependencies - what functionality is and isn't related, what is
   "essential" and what isn't, and what is "platform" vs. something else, and
   factor things accordingly.  That keeps a clean definition of what is
   "platform" and what isn't, and keeps the IDE and platform from merging into
   a monolithic hairball (which it once, circa 1999, was).  So it's a good
   thing to keep.
   
   Now, re SVG icons, that seems to me to be something which obviously belongs
   in the platform.  Display resolution is not going to go *down* and we are
   past the point where raster formats for this sort of thing are inadequate;
   mobile platforms typically have you create raster icons in multiple
   resolutions, which is annoying and goes out of date with the next model;
   and on the desktop, we're not dealing with standardized screen sizes and
   resolutions, so the only sane way to deal that is a resolution-independent
   graphics format.
   
   So, this belongs in the platform, period.
   
   If the objection is that the IDE itself is not yet using SVG icons, so it
   will result in library dependencies getting packaged which nothing
   uses, *that's
   a build-system problem, not an architecture problem.*  Fix the build system
   so the application-building phase detects that there are libraries which
   are not referenced in the manifest of any module or other library, and
   deletes those.  That's as simple as building a graph of inter-JAR
   dependencies and then seeing if what you actually get is *more than one
   distinct graph*, and deleting everything that is not in the largest graph
   which is the actual application.
   
   -Tim
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists