On Thu, 7 Oct 2010 12:34:28 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> On Thu, Oct 7, 2010 at 9:36 AM, Gustavo Sverzut Barbieri > <[email protected]> wrote: > > On Thu, Oct 7, 2010 at 8:52 AM, Rui Miguel Silva Seabra <[email protected]> > > wrote: > >> For the record, in case someone searchs for the same problem: > >> > >> <raster> [Rui]: textwrap doesnt work in genlist. its basically not > >> possible (without massive overhead). so dont do it. > >> <raster> [Rui]: dont put wrapped text there > >> <raster> dont use genlist > >> <raster> genlist places limits on layout because it makes assumptions > >> <raster> to speed things up > > > > yeah, that's something I never expected and find quite limiting... > > I'll try to see what is possible to do with compress mode, or > > introduce another mode that is similar to it. > > Okay, the attached patch makes it work, but it is slow* as Raster > warned us with his -- sometimes annoying -- wisdom. :) > The slowness is just when list width changes, as it is obvious that we > need to invalidate all item geometry and calculate them again. I > really don't see how to avoid this, it is theoretically impossible as > it is dependent on the variable :-) But the fact that calc_job() is > blocking does most of the harm... and it may happen in other cases as > well (for instance if one invalidates all items by calling > elm_genlist_item_update()). width changes are not just when the scroller changes - but any change of any item could change list width (min width - long label for example that doesnt compress). this would force a full recalc. and that reclalc may completely change the height of all items. with a lot of effort you can begin to make things "less bad" but that effort doesnt exist right now. the idler for handling adds/dels and updates could work here, but u'd have to set it up right. there needs to be work on also keeping scrolelr position correct during these recalcs as it shifts around (or more specifically scroller pos is fixed at N pixels from top left, but the items shift around as they expand/contract thus the scroller seems to shift around). > Thus I'd like Raster's opinion on this patch and whenever it is okay > to have calc_job() loop to be an idler that is started from the job. > This idler would be reset whenever calc_job is re-requested and an > existing was being executed. I'll try to do this patch and send it to > mail list, but if you think it is a "NO GO" then say now and save me > some work ;-) i need to look in more detail, but in principle, if you use an idler that calcs a few items each time just like the current queue idler does - it should work. the current idler should possibly be changed to ALSO handle "updates" as well as "queued items". so if a "recalc item N" (also re-shuffle items after N), "reclac block N", and so on - or well, whatever is needed. the same code that handles "only do N items and/or use up to N seconds of time to do the work" logic can be shared. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
