Opened 15 years ago

Closed 5 years ago

Last modified 4 years ago

#3828 closed bug (fixed)

Icon positioning/selection got screwed up.

Reported by: bga Owned by: aldeck
Priority: normal Milestone: R1/beta2
Component: Applications/Tracker Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking: #4876
Platform: All

Description

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.

Attachments (1)

SelectionError.png (57.9 KB ) - added by bga 15 years ago.
Sekection Error

Download all attachments as: .zip

Change History (22)

by bga, 15 years ago

Attachment: SelectionError.png added

Sekection Error

comment:1 by bga, 15 years ago

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.

comment:2 by aldeck, 15 years ago

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 :)

comment:3 by stippi, 15 years ago

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.

comment:4 by bga, 15 years ago

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?

comment:5 by aldeck, 15 years ago

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

comment:6 by stippi, 15 years ago

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.

comment:7 by bga, 15 years ago

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. :)

comment:8 by axeld, 15 years ago

Owner: changed from axeld to stippi

comment:9 by bga, 15 years ago

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

comment:10 by aldeck, 15 years ago

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

comment:11 by aldeck, 15 years ago

Owner: changed from stippi to aldeck
Status: newassigned

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.

comment:12 by aldeck, 15 years ago

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

comment:13 by bga, 15 years ago

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

comment:14 by aldeck, 15 years ago

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.

comment:15 by bga, 15 years ago

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!

in reply to:  15 comment:16 by jackburton, 15 years ago

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 ?

comment:17 by aldeck, 15 years ago

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 :)

comment:18 by aldeck, 14 years ago

Blocking: 4876 added

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

comment:19 by aldeck, 14 years ago

Please test with hrev36592 or later.

comment:20 by waddlesplash, 5 years ago

Resolution: fixed
Status: in-progressclosed

No reply in 10 years, assuming fixed.

comment:21 by nielx, 4 years ago

Milestone: R1R1/beta2

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

Note: See TracTickets for help on using tickets.