Changes between Initial Version and Version 1 of Ticket #7061, comment 5


Ignore:
Timestamp:
Nov 18, 2013, 10:59:32 AM (11 years ago)
Author:
stippi

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #7061, comment 5

    initial v1  
    11It is only slightly more tricky using HVIF. The classes necessary for this are contained in libicon.a, and end up in libbe. The header files and the code strips functionality which is only needed by Icon-O-Matic, but there should be enough left, or it should be easily enabled, so that one can add any shape one desires to an Icon object.
    22
    3 The most "complicated" step may turn out to be getting to the actual resource which contains the icon that ends up being used. For example, when you download a .ZIP, its no use to get the ZIP icon bitmap, you need to figure out where this actually comes from (the ZIP MIME-type file) and load it from there manually as an libicon.a "Icon" instance. But maybe IconUtils can be extended for that. From there, it's easy to add shapes to that icon and export it as file attribute, again using functionality from libicon.a (FlatIconExporter, if memory serves).
     3The most "complicated" step may turn out to be getting to the actual resource which contains the icon that ends up being used. For example, when you download a .ZIP, its no use to get the ZIP icon bitmap, you need to figure out where this actually comes from (the ZIP MIME-type file) and load it from there manually as a libicon.a "Icon" instance. But maybe IconUtils can be extended for that. From there, it's easy to add shapes to that icon and export it as file attribute, again using functionality from libicon.a (FlatIconExporter, if memory serves).
    44
    55As far as what the best way to do it would be... I don't know. Apps other than Tracker only actually benefit if they contain a mechanism to live-update the icons of files they show based on node monitoring. But it would certainly be useful as a first implementation.