ubuntu-accomplishments-contributors team mailing list archive

[Michael Hall <mhall119@xxxxxxxxxx>]

The only real downside I can think of from this proposal is that you may
lose consistency if people use different lock iconography, so the user
wouldn't necessarily be able to tell, at a glance, if the accomplishment
is locked or not.

An alternative that satisfies both is to run the lock image generating
script as part of the package build, translations build, or some other
process that happens before the package is uploaded.

Michael Hall
mhall119@xxxxxxxxxx

On 11/28/2012 12:48 PM, Matt Fischer wrote:
> I'm okay with this as well, just be sure to include the locked icon
> generator script and update the directions.  We could also add a check
> to the package build and have it fail if a locked icon is missing (or
> just generate it).
> 
> On 11/27/2012 11:23 PM, Janos Gyerik wrote:
>> I'm not working on the viewer, but your proposal makes perfect sense.
>> This is "static data", and as such it should not be generated but
>> given and ready to use. Space saving is a non-issue, considering the
>> small size of these image files.
>>
>> Janos
>>
>> On Tue, Nov 27, 2012 at 7:45 PM, Rafał Cieślak
>> <rafalcieslak256@xxxxxxxxxx> wrote:
>>> 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
>>>
>>> -- 
>>> Mailing list: https://launchpad.net/~ubuntu-accomplishments-contributors
>>> Post to     : ubuntu-accomplishments-contributors@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ubuntu-accomplishments-contributors
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
> 
>