[Sugar-devel] [sugar-toolkit-gtk3 PATCH] sl#4276: Writing the icon-files for ".xo" files on a permanent mount-point, and not /tmp. mount-point.

[Manuel Quiñones]

2012/12/10 Ajay Garg <ajay at activitycentral.com>:
>
>
> On Tue, Dec 11, 2012 at 2:07 AM, Manuel Quiñones <manuq at laptop.org> wrote:
>>
>> Hi Ajay,
>>
>> first, thanks for helping on this.
>
>
> My pleasure :)
>
>
>>
>>
>> 2012/12/10 Ajay Garg <ajay at activitycentral.com>:
>> > This issue happens, when ".xo" files need to be rendered in the listview
>> > in non-journal locations.
>> > In such cases, these files have no "activity" or "bundle_id" fields in
>> > their metadata.
>> >
>> > Thus, the current way to know the icon-file-name for such ".xo" files
>> > was to expand the zipped files, and write out the icon-files at
>> > pseudo-permanent storage,  at /tmp.
>> >
>> > However, before the icon-file could be used by the listview to "pick up"
>> > the icon bytes, it was  being  garbage-collected.
>>
>> Are you sure about this assumption?  How can you explain that the
>> icons are visible in the palette and in the details view?  I tested
>> with a stick which has a .xo file inside.
>>
>> 1. ls /tmp - no svg files
>>
>> 2. open Journal - I can see this:
>> http://bugs.sugarlabs.org/attachment/ticket/4276/test-wrong-icon.png
>>
>> 3. ls /tpm - now I can see two svg files
>>
>> So seems your assumption is wrong.
>
>
>
> I also noticed that some files are there in the "/tmp" directory; however
> when I tried finding the file by the name @<return value of function in def
> get_icon(self)>, I could not find a file with that  name in "/tmp".
>
> Regarding the appearance in the right-click palette, I presumed that since
> doing a right-click generates a NEW palette everytime, so it works.
> But for the listview, the activity-icons are displayed  via the "file-name"
> property in CellRendererActivityIcon (in src/jarabe/journal/listview.py).
> So, it could be that once that with scrolling in the list-view, re-rendering
> the icon using the non-refreshed "file-name" property, might be causing the
> bug.

So I conclude this needs further investigation.

> However, in  any case, the space- and time-optimizations make me lean
> towards this one-time-icon-file-per-activity-writing approach.

I think the bug should be solved first, later we can discuss
optimizations, and certeanly not at this time of the cycle.

--
.. manuq ..