On 08/05/2009 08:52 PM, Gustavo Sverzut Barbieri wrote:
> On Wed, Aug 5, 2009 at 3:07 PM, N-Billy<[email protected]> wrote:
>
>> On 08/05/2009 07:29 PM, Gustavo Sverzut Barbieri wrote:
>>
>> On Wed, Aug 5, 2009 at 1:48 PM, N-Billy<[email protected]> wrote:
>>
>>
>> now I finally found a way to fix this, though I'm sure it's rather a
>> workaround than a fix.
>>
>> the problem seems to be that evas has to render in order to correct the
>> coordinates of the buttons within the block. Thus, enforcing evas_render
>> and adjusting the scroller again works fine.
>> Could pls s.o. look into that issue? I assume this render operation
>> should be placed somewhere else, but I dunno where. Just calling it
>> before adjusting the scroller region doesn't work.
>>
>>
>> Index: src/lib/elm_genlist.c
>> ===================================================================
>> --- src/lib/elm_genlist.c (revision 41609)
>> +++ src/lib/elm_genlist.c (working copy)
>> @@ -1902,6 +1902,11 @@
>> it->x + it->block->x,
>> it->y + it->block->y,
>> it->block->w, it->h);
>> + evas_render(evas_object_evas_get(it->wd->obj));
>> + elm_smart_scroller_child_region_show(it->wd->scr,
>> + it->x + it->block->x,
>> + it->y + it->block->y,
>> + it->block->w, it->h);
>> }
>>
>>
>> I have not followed this thread in depth or investigated the problem,
>> but this is wrong. You should never force evas to render at any time,
>> this is bad.
>>
>>
>>
>> Hi Gustavo,
>>
>> just found out that even this helps only for the second block. Testing with
>> items>100 shows this doesn't help fully.
>> I just investigated when the coordinates it->y change from wrong to correct
>> and it was on idle/main loop. So I tried to force by rendering and it helped
>> at least a bit.
>>
>> Something's wrong with the recalculation and maybe the
>> elm_smart_scroller_child_region_show should then be added as a job or s.th.
>> to be done asynchronously as well?
>>
>> This bug is annoying but I still cannot find a proper solution :(
>>
>
> You'll need raster to look at it, he wrote it so he might know.
>
hm, hope he reads this in here :-)
> I'm still pending elementary refactor (aka merge with guarana) and
> then port my own list implementation. It's faster than genlist and
> orders of magnitude simpler than genlist, but comes with some
> limitations: you need the same row renderer for all rows, they should
> be of fixed size and now tree support. These limitations make it much
> simpler as we can keep a fixed pool of visible objects + 2 (spare) and
> recycle them, show a given region is basic math + move. I don't know
> your use case, but for things like music players and directory listing
> it should do.
>
>
sound like this would be sufficient, since the use case actually is only
a list of files, no tree.
should be worth a try :-)
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
