When using a genlist tree and populating the expansion on the fly, genlist never gets it's odd/even theme correct and you end up with doubled up colors. As an example run elementary_test FileSelector, set it to expandable, and expand a directory that has subdirectories.
In genlist filtering, this is a known problem since the items are hidden but they still exist in the list. So, if an item on say, 4th position is hidden, items on 3rd and 5th position will show the same color. I am checking for a solution for that.
However, it seems that Genlist tree is a different issue altogether as the sequence looks to be getting messed up when the items are being added. (To add: Not able to reproduce it. :( )
Hi I merged in the genlist sorted insert ticket as it is caused by the same root problem. Genlist keeps it's index in the order items are created, not the order that they are in on screen. I.e... 1-10 is the first level, 11-20 is the second level... and they were created in that order so genlist's index list has them in that order... but the order on screen is like 1, 11, 12, 13, 14, 15, 2, 3, 4, 16, 17, 18, 19, 20, 5, 6, 7, 8, 9, 10 for instance. Fixing this index keeping would fix a lot of the bugs in genlist.
7affe8c2047a41a2945cf6c048d59f28c974aa7a now breaks visual compat by removing a feature, but even worse.. it doesn't close this bug. if this bug isn't closed AND it remains a showstopper then efl 1.18 doesn't go out. removing a feature that has been there for 5+ years to hide the real issue is just bad.
either just accept this and move on, or fix it properly, but stop trying to hide it.
You know perfectly well how tricky genlist code is and how risky it is to try to fix anything in it at the last minute. Their is a decision to be made, make fileselector and all genlist visually ok with default theme. I also have no clue what you could mean by visual compat as that would mean we should forever maintain odd/even broken if that was a thing. Same we shouldn't have ever any new theme as it would break visual compat. And yes, it doesn't close this bug, because it is not a fix. genlist should be fixed in next release and the priority of this bug raised again for 1.19 after I revert my temporary patch.
now genlist look wrong. look at it next to a regular list. list does odd-even and genlist does not. not only that but the look changed between 2 versions of efl AND the bug actually isn't fixed. just visuals FOR the cases where inserts happen out of order. this is not all genlist use cases. this is just wrong. you're covering it up, creating new visual bugs where list and genlist now don't match AND apps no longer get the kind f look they used to have. apps with custom odd/even themes will lose that ability... but worse this will change again in a future release when this is fixed. stop covering it up. leave it. fix the bug or leave it. but this is STILL a showstopper so you did nothing to make efl release closer to happening...
Indeed, I will turn also list and index style to not have odd/even for this release and revert all of that as soon as 1.18 is out.
We both know that touching genlist is a high risk for adding more bugs. The only way for application to use the default genlist and not look bad is to cover up by themself the odd/even theme. I think it is better to have no rendering bugs and disable this feature in our theme than make application look like crap. Of course this is not closing this bug as it still need fixing, it is a temporary mesure that give us an acceptable result with the ressource we have.
I would have kept the original genlist bug as is. It's only a looks issue, not a usability bug as far as I know. By removing the odd/even look in all lists, you've just broken all possible exactness comparison tests. On top of that, lists are harder to read, because of the lack of odd/even visual cue.
Looks are just as important as usability. When the aesthetics are wrong, the human eye focuses on it. And therefore using the interface becomes highly annoying, and more and more so depending on how ocd you are. Cedric is right.
@raster and @jpeg it has been decided a long time ago to keep using an old version of the theme for running exactness as basically any change, not just mine, but any change might broke them and it is unavoidable. Added benefit of that decision was that we get automatic testing of theme ABI break.
I don't know if we're running exactness tests and I don't know the current setup, but I know that the only way for exactness to do reliable test is to embedded the theme in the exactness test itself (this has been one of the many reason exactness should be using eet to store information).
I'm now trying to solve this issue by get index from the block like fast ways, so every realization, update odd and even by percised index value, and it solve many problem cases,
but still there are some problem remains rarely. I think index calculation is wrong or some items which was already realized are not called realize function well..
need to check more,
but to solve this, we should make the odd and even much simpler, just get their percise index in that time.
iterating blocks with counting each block items will reduce the iteration burden a lot.
Could the indexes issue be related to some weird thing that happens when you append an item after an expanded tree item, like in this screenshot http://www.enlightenment.org/ss/e-58b1eb2d2a1586.23768233.jpg (there, item 1101 is a son of 1001 and item 0 is appended after 1001)?