Community
Participate
Working Groups
A small/simple thing that would add polish to prov UI experience would be support for an icon property for IU's, so that when users browse the available software, they could see the branding icons. We could always default to the current icon if the IU didn't provide one.
*** This bug has been marked as a duplicate of bug 252014 ***
reopening this bug to track using the new icon metadata (in bug 299245) in the p2 UI. This is a pretty trivial change. The "duplicate" bug addresses using the icon from the feature.xml as the IU icon and that is really more of a tooling issue, so it should remain open in its own right.
I've just realized this bug is API affecting since we would need a new IInstallableUnit property constant. Should we add the property constant (and nothing else) for M6? In M6, it would always return null because it would never be found. We still have to work out what the format is and how the icon is stored (separate file vs. inline). However this could be considered "javadoc clarification" after API freeze. I will not have time to implement the storage of the property for M6 and I believe we wanted to discuss further. Thoughts?
(In reply to comment #3) > I've just realized this bug is API affecting since we would need a new > IInstallableUnit property constant. I think we can just go ahead and add the property constant now. Note we have a couple of other property constants that aren't in use today (like PROP_CONTACT) - having a property key defined is no guarantee that such a property will be present.
(In reply to comment #4) > (In reply to comment #3) > > I've just realized this bug is API affecting since we would need a new > > IInstallableUnit property constant. > > I think we can just go ahead and add the property constant now. Note we have a > couple of other property constants that aren't in use today (like PROP_CONTACT) > - having a property key defined is no guarantee that such a property will be > present. thanks, John. This one felt weirder to me because saying that the property is a string containing bytes is a bit vague. We will want to update the javadoc to describe the expected format of these bytes once we decide what they are. In the meantime, I have committed the property key definition and can now safely move this bug to M7...
We have several bugs on this topic. Let's say that: bug 301474 is determining the format/cleaning up the javadoc bug 301475 is tooling I'll consider this to be the bug representing: - utility method to get an Image (or ImageDescriptor) from the property - use of the icon in the label providers we may have to use a different "default" icon (bigger) for this to look right in the end (32 x 32 vs the 16x16 we use now).
Removing milestone. I was really hoping to make use of the icon in the "installed software list" so that branding observed during install could be maintained once it's in the system. However, there are just too many unsolved issues here: - Bug 301474 - how do we interpret the URI, how do we store the icon? - How do the label providers handle icon size? Do they allow mixed height items or assume a certain size, etc.? Discovery UI is much more specific about the sizes of icons. We could decide, for example, to put the 32x32 icon from the catalog in here, but we'd have to figure out what to do for the other cases
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This is relative to a component that is not widely used/adopted.
