Icon positioning/selection got screwed up.

[bga]

this is one of those bugs that are difficult to explain because I could not find a way for it to happen consistently but it always happens after a while playint with the icons in the Desktop.

usually when I set up a new installation I always change the icon size in the Desktop to 48x48 then move the icons around to the positions I want then (also adding some other links to the Desktop) and then use ALT+K to align the icons to the grid (Cleanup). After a while doing this, the following will start happening:

1 - Selecting a group of icons will not work. Only one icon in a group of three (for example) is selected. based on the other symptoms I think this happens because Tracker does not think the icon is there.

2 - Moving the icons around to a place that is not even near other icons or the screen border (just to be sure it was not Tracker trying to sort up overlaps) and pressing ALT+K will move the icon to its previous position (before I dragged it). No matter what I do or to where I move the icon, when it starts happening, it will always happen.

I think this is probably related to Tracker changes made sometime ago concerning icon size and positioning.

[bga]

Sekection Error

[bga]

Added a screenshot that shows the problem. I used the selection retangle to select 3 icons. Only 2 got selected.If I individually click the icon that was not selected, it is selected as expected. It just fails with the selection box.

[aldeck]

Didn't try to reproduce yet, but can you check an older revision (ex, before hrev29971) to be sure it's indeed a recent bug, thanks. I've got a patch pending for tracker's mouse tracking (including selection rect) so i'd rather have this one fixed before :)

[stippi]

It could well be that my changes to remembering icon positions and changing sizes and so on have caused this problem. For the next month, I will only be able to look into things on the weekends, though. So I'll be glad if someone else beats me to fixing this.

[bga]

Yes, hrev29970 does not have the described behavior. So it is something in stippi's changes. aldecjk, are you looking into it or should I?

[aldeck]

bga, go ahead if you're inspired :) i won't look into it today at least.

[stippi]

I would examine my changes in the direction that poses are not in some lists anymore where they should be in. Like there is a list sorted by Y offset. Also maybe poses have flags that indicate certain members are set, but they are not, or something to this effect. Maybe make a single diff for PoseView.cpp that covers a range of revisions and look closely at all the changes related to setting pose locations and inserting/removing poses from certain lists. Sorry for the trouble.

[bga]

aldeck: I can not look into it today either as I am working. I will try to look into it tonight, but no promises. If you start looking into this before I say anything, just mention it here. I will do the same.

stippi: No worries. We would not really progress much if people were not willing to make changes because they can potentially break things. :)

[bga]

Did anyone find the time to look into this (I didn't). It is still broken and is annoying as hell. :P

[aldeck]

I'm having a look, will assign to me if i get enough clues...

[aldeck]

I added a check to verify that poses in fVSPoseList are indeed always vertically sorted, and confirmed that it gets broken a some point. As it is used to speed up the intersection test, some poses are wrongly excluded from the test. Didn't find a problem in stippi's changes so he might still be innocent ;) Will find out soon hopefully.

[aldeck]

Note that this one doesn't exist (ie: fixed) in the tracker_refactor branch since hrev31433. Bear with me until i merge this back.

[bga]

Cool. Just out of curiosity, do you have an ETA?

[aldeck]

Well, it's hard to tell. There's still a lot of work planned. I'm currently modularizing the pose layouting. And the pose spatial cache needs an optimized implementation. I might merge back after that, although i'd like to do more (like making the list mode just a special case of icon mode). Note that in its current state it's totally usable (and as said earlier, even fixes bugs :)). The idea is to refactor/rewrite in place, and keep it in a usable/bug-free state at all times. I'm using it as i develop, since a few weeks.

[bga]

Considering you are fixing (annoying) bugs while you go, wouldn't it be a good idea if you merged back to trunk after completing one set of self-contained changes? This way there would be the benefit of the bug fixes and you would still be able to work on your branch.

In any case, thanks for doing this!

[jackburton]

Replying to bga:

Considering you are fixing (annoying) bugs while you go, wouldn't it be a good idea if you merged back to trunk after completing one set of self-contained changes? This way there would be the benefit of the bug fixes and you would still be able to work on your branch.

Yeah I'd like that too. If it doesn't introduce new bugs, and even fixes some, why not ?

[aldeck]

Will do when its ready :), well more seriously, the only issue is that while it is a lot more robust, PoseSpatialCache is currently slower than the code it replaced in trunk. So there might be some slowness in populated folders (affecting icon modes only). The problem is that i don't want to waste too much time in optimizations while i'm in a phase of generalizing, killing all the special cases code and thus "unoptimizing", and using OO design to prepare for specializations.

Optimizing after that is just a matter of a new implementation of the abstract class, everything is contained, and anyone wanting to try another implementation is free to do so :) I almost started a HashedSpatialCache (see "spatial hashing" on the web) which should be O(1) for all spatial queries, but i'd better keep the fun for later and spend my current time doing the hard work, ie: modularizing other parts.

In any case, a few testers of the branch wouldn't hurt :)

[aldeck]

(In #4876) Most probably a duplicate of #3828.

[aldeck]

Please test with hrev36592 or later.

[waddlesplash]

No reply in 10 years, assuming fixed.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone