ubuntu-accomplishments-contributors team mailing list archive

[Rafał Cieślak <rafalcieslak256@xxxxxxxxxx>]

Hello everyone!

I need to consult you about a particular details daemon does. I would
like to get rid of a feature I consider completely pointless, and the
point of this e-mail is to ask whether everyone is okay with it.

The thing is about accomplishments icons. Let me explain how they work
currently.

The goal is to get the viewer to display appropriate accomplishment
icons. Some of them have a "lock" overlay on them, symbolizing that
they are locked, some of them don't. Whenever the daemon starts, it
loads all available .png icon files from all collections. Then it
stores them in .cache/accomplishments/trophyimages , it also paints
the lock symbol over each of them and saves the 'locked' icon copy as
*-locked.png. Finally, when the viewer asks the daemon where the icon
file for given accomID is, it points it to appropriate file in that
.cache directory, using locked or unlocked icon appropriately.

At first eye's sight this looks reasonable. The daemon is the one who
prepares all stuff for the viewer. But have a look at this alternative
solution:

Let's store both a.png and a-locked.png files within the
accomplishment collection. The daemon would not touch them at all, and
when requested to point to icon file location, it would point to the
appropriate file within the directory in which collections are
installed.

Let me list the advantages of that alternative solution, as well as
all it's cons I am aware of.
 + The daemon would not spend any additional on startup to do image
manipulation. It also avoids repearing same actions, as everytime it
starts it generates exacly the same set of icons (unless collections
are installed/removed, which is rare).
 + The daemon would not depend on or import any modules of some image
manipulation libraries.
 + We avoid a lot of possible problems with the cache not being yet
ready when viewer asks for icons. Moreover, it nullifies the
requirement to regenerate icon cache when it gets outdated.
 + It'll be easier for artists to work on icons. No need to restart
the daemon to force regenerating cache.
 + With this solution we would be able to work with .svg files primarily.
 - We would use twice as much disk space for icons within the
collection. (I think this can be ignored, the overall size will be
tiny anyway)
 - Creating a new icon would require to apply the 'lock' manually.
(This can be done with a small script that does exactly what the
daemon does now, it could be included among the icons).

Any thoughts on that? Did I miss any important point why the daemon
has to perform image manipulations? Are we fine with removing that
(old) functionality?

Rafał Cieślak