Opened 13 years ago

Closed 8 years ago

Last modified 8 years ago

#880 closed bug (fixed)

[Tracker] icon disappers if right click selected and then desktop is left clicked

Reported by: diver Owned by: aldeck
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #1805
Has a Patch: no Platform: All

Description

Select any icon on the desktop, then right click and hold mouse button in empty area of desktop, selected icon will disappear,

Change History (27)

comment:1 by stippi, 12 years ago

Sounds like a problem with accepting or not accepting first click? Maybe R5 makes sure clicks which result in closing menus never go though to the window which is clicked on?

comment:2 by axeld, 12 years ago

Milestone: R1R1/alpha

Bug #1000 was a duplicate of this one.

comment:3 by stippi, 12 years ago

Resolution: invalid
Status: newclosed

R5 behaves exactly the same for both left and right click into empty desktop region when icons are selected (the icons are deselected and the context menu appears). So I am closing this bug as invalid (should not hold up R1/alpha at least :-)). That being said, I don't know what the expected behaviour is. Personally, I find it "expected" that clicking outside the selected icons deselects them even if the context menu opens.

comment:4 by diver, 12 years ago

Resolution: invalid
Status: closedreopened

Yes i know that R5 behaves exactly the same, but imho it's a bug and user don't have to see such visual glitches as it looks not professional and shouldn't be there in the first place ;-) I would like to reopen this bug, feel free to close it again if you feel so as you know it better. And you are right, it should not hold up R1/alpha.

comment:5 by jackburton, 12 years ago

Milestone: R1/alphaUnscheduled

Windows does it like this, Gnome does it like this, I think we should just stick with this behavior since it makes sense. If you want to do something with the selected files, you should right click on the selection. I'm changing milestone, anyway.

in reply to:  5 ; comment:6 by diver, 12 years ago

Replying to jackburton:

I think you misunderstood me here. If you select desktop files and hold it for several seconds icons will _disappear_ and this is not the same as with Gnome, KDE or Explorer, this is just with Tracker.

in reply to:  6 comment:7 by jackburton, 12 years ago

Replying to diver:

Replying to jackburton:

I think you misunderstood me here. If you select desktop files and hold it for several seconds icons will _disappear_ and this is not the same as with Gnome, KDE or Explorer, this is just with Tracker.

This really looks like a bug, sorry for misunderstanding :)

comment:8 by jackburton, 12 years ago

Although I can't reproduce it.

comment:9 by diver, 11 years ago

To reproduce:
Boot Haiku
Close Terminal
Select Haiku volume icon
Click Leaf menu
Click and hold mouse in empty area of desktop

comment:10 by diver, 11 years ago

Or just right click any icon on desktop (to show icon context menu) and then left click and hold in empty area of desktop.

comment:11 by stippi, 11 years ago

Ok, with the second method, I can reproduce it. The icon disappears for a short moment until the context menu appears. Since Tracker "busy loops" to figure out whether to show the context menu when clicking with the left mouse button, I suppose, a simple Window()->UpdateIfNeeded() before waiting for the timeout should do it. Until that big Tracker refactoring cleanup, that is... :-)

comment:12 by diver, 11 years ago

Maybe we should change milestone then :P

comment:13 by diver, 11 years ago

Summary: [app_server] icon disappers if selected and then desktop right clicked[app_server] icon disappers if right click selected and then desktop is left clicked

comment:14 by diver, 11 years ago

Component: Servers/app_serverApplications/Tracker
Summary: [app_server] icon disappers if right click selected and then desktop is left clicked[Tracker] icon disappers if right click selected and then desktop is left clicked

comment:15 by axeld, 11 years ago

Milestone: UnscheduledR1

I can't reproduce this in VMware.

comment:16 by diver, 11 years ago

I can reproduce it in vmware. Maybe my description is not that clear? Stippi, could you describe how have you managed to reproduce it? Or better yet, just fix it ;-)

comment:17 by aldeck, 11 years ago

This is definitely due to busy looping for long click/drag detection. I'll have a look soon!

comment:18 by diver, 11 years ago

Any news on this one aldeck? ;-)

comment:19 by aldeck, 11 years ago

Well sorry for the apparent promise, i didn't assign it to me at least :) Anyway, i didn't forget it but this one is just low priority on my list, it causes no real harm. And it's also not necessarily an easy fix, as Tracker's mouse tracking code is a bit messy and would need some rewriting.

comment:20 by aldeck, 10 years ago

Blocking: 1805 added

(In #1805) Yes you're right, thanks for testing. This will be fixed with the mouse tracking rewrite. Marking as duplicate.

comment:21 by diver, 10 years ago

Still here in hrev35569.

comment:22 by diver, 10 years ago

Version: R1/pre-alpha1R1/Development

comment:23 by diver, 9 years ago

Still reproducible in hrev38300.

comment:24 by aldeck, 8 years ago

Owner: changed from axeld to aldeck
Status: reopenedin-progress

comment:25 by aldeck, 8 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev41892

comment:26 by diver, 8 years ago

Finally, thanks a lot!

comment:27 by aldeck, 8 years ago

My pleasure, thanks for your dedication!

Note: See TracTickets for help on using tickets.