ubuntu-accomplishments-contributors team mailing list archive

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

Thanks for the feedback guys. I'll work on moving the -locked
generation from daemon to a separate script within collection.

2012/11/28 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
>>>
>>>
>>
>>
>
> --
> 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