> I'm thinking about a SINGLE ImageRegistry / StringRegistry
> (could also be a database), from which plugins can acquire
> an image/String by means of a Key (that could be an int
> number, for instance). At the time a bundle is installed, all
> its images / Strings are placed into the common Database.
> Clients get a Key in return, which they can use at runtime
> to retrieve their data. Identical data is collapsed.
>
> Sounds interesting? Or am I missing something? Uninstalling
> a bundle would certainly not be easy, and I guess that the
> String and Image database would likely be an add-only thing
> to avoid lifecycle issues.
We have had great success in the past with JFace's LocalResourceManager. As
long as the keys are not taking up more space than what you save through
collapsing the real data, it sounds like a good idea.
LocalResourceManager is an object whose lifecycle is managed by its owner
(usually some plugin), so lifecycle issues are not that problematic. Each
resource manager has a parent resource manager, but all resources (in the
JFace case: Images, Colors, Fonts) are managed at the root resource
manager, and reference-counted there. By disposing your
LocalResourceManager, the reference counts for all resources you
contributed get decremented automatically. This also avoids the Singleton
pattern... your all-caps SINGLE made me extremely nervous. ;-)
Not sure how you would use something like this for strings though. Given a
list of potentially not unique string objects, you can use a hash to
uniquefy them, but it's computationally expensive if done synchronously and
eagerly. (The resources plugin will uniquefy all strings used for markers,
but it's done in a background job:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244631#c9)
Boris
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
