Opened 10 years ago

Closed 10 years ago

#5172 closed bug (fixed)

Right-click-drag broken

Reported by: humdinger Owned by: jackburton
Priority: normal Milestone: R1
Component: Applications/Terminal Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is hrev34761.

Dragging a file or folder into Terminal still shows the context menu to insert the path, change directory etc. but it can't be used anymore.

Change History (5)

comment:1 by jackburton, 10 years ago

Status: newassigned

I can take care of this. But what would be the correct behaviour ? Implement the missing functionality or remove the menus altogether ?

comment:2 by humdinger, 10 years ago

I thought it's already implemented (at least I remember it working...). So, it's more "fixing" than "implementing". I like those features, so I wouldn't like to see it go.

comment:3 by jackburton, 10 years ago

The bug is caused by hrev33746: the WasDropped property of a BMessage isn't cleared anymore when the message is copied. I'm not sure if this is the correct behaviour or not. From the commit message, it seems it is. If confirmed, the code in TermView would have to be changed to check for kSecondaryMouseDropAction before checking if the message was dropped, or (better) clear the wasdropped flag in _SecondaryMouseButtonDropped(), if possible.

Can anyone confirm that hrev33746 implements the correct behaviour?

comment:4 by mmlr, 10 years ago

I didn't actually test on R5 as I didn't (and don't) have it around anymore. But if you read about it in the BeBook it makes sense. It just signifies whether or not the DropPoint() is valid. At least I'd guess Tracker would be a good reference as it was around a long time. If someone could check on R5 that would be nice of course.

in reply to:  4 comment:5 by jackburton, 10 years ago

Resolution: fixed
Status: assignedclosed

Replying to mmlr:

I didn't actually test on R5 as I didn't (and don't) have it around anymore. But if you read about it in the BeBook it makes sense. It just signifies whether or not the DropPoint() is valid. At least I'd guess Tracker would be a good reference as it was around a long time. If someone could check on R5 that would be nice of course.

I decided to trust what Tracker does, and added a check in TermView::MessageReceived() for B_SIMPLE_DATA, in addition of checking for WasDropped. Fixed in hrev34828

Note: See TracTickets for help on using tickets.