Command + Drag does not work (Apple) #2890
Comments
|
This also affects automation on OS X as it's not possible to drag a control knob etc onto the automation track. In both cases the drag "ghost" image of the block/control appears but it doesn't have the green "+" copy symbol. It works on RC1. Tested on Mac OS X 10.8.x with the 1.1.91 DMG file from OP. |
|
Marking for 1.2 milestone. This bug is really making usability of 1.2 difficult on Mac. This may be a Qt5 problem. This works perfectly fine in the 1.1.3 installer which was packaged with Qt4. |
|
When did the Qt5 change happen? FWIW it works fine with the 1.2.0-RC1 / lmms-1.1.90-mac10.7.dmg file. |
Between RC1 and the upcoming RC2 per #2611 |
|
Moving to #2611. This is a blocker for Qt5 release. Help appreciated. |
|
Some more details for those that may be able to help...
AFAIK, the check happens here: src/core/Track.cpp#L657 if( m_trackView->trackContainerView()->allowRubberband() == true &&
me->button() == Qt::LeftButton )
{
if( m_trackView->trackContainerView()->rubberBandActive() == true )
{
// Propagate to trackView for rubberbanding
selectableObject::mousePressEvent( me );
}
+ else if ( me->modifiers() & Qt::ControlModifier )
+ {
+ if( isSelected() == true )
+ {
+ m_action = CopySelection;
+ }
else
{
m_action = ToggleSelected;
}
}
else if( !me->modifiers() )
{
if( isSelected() == true )
{
m_action = MoveSelection;
}
}
}And according to the Qt 5.7 docs, this logic should still be valid...
But some people claim |
|
@tresf have you tried to code that hard? I've seen that somewhere in the code with that flower string. “⌘” |
Thanks for the hint however what you are referring to is most likely just a translated tool-tip. |
|
Edit: Turns out the "bug" is with Back to the drawing board...
"tco:0:<?xml version="1.0"?>
<!DOCTYPE>
..."
"tco:0:<?xml version=\"1.0\"?>\n<!DOCTYPE>
..."
|
|
To help you, someone should work on Linux, add traces ( |
|
The above video demonstrates what happens when replacing
Components that are broken with this behavior:
|
|
In Qt 5.6, at least that part seems to work for me. With qDebug() << "TCOV::mousePressEvent" << me->modifiers();as the first line in
as expected. The pattern still doesn't copy though. Where I see it break down is around I'm having trouble installing 5.5, so I'm afraid I can't reproduce what you're seeing. Do you have a 5.6 installation at hand to see whether that maybe fixes what you're seeing? |
Sorry, it was a mistake on my part... I've put debug statements all over Track.cpp and you're right, it IS firing on If you blindly replace all instances of Side note... DON'T use |
|
I just recompiled with Qt 5.6.2 (released yesterday) and it works 🚀
|
|
If See also #2862. Ugh... |
|
@teeberg I've patched the installation process to use the 5.5 version of the
Unfortunately Option + Drag is still broken. I'm starting to wonder if this issue is related to the build environment I'm using (10.9 for backwards compat reasons). I'd happily use a newer build environment if we can keep backwards compatibility for older MacOS versions. |
|
To put the "Why do we build on 10.8 anyway?" conversation into some context, I tried running a 10.11 build on 10.8 and this is what I get:
https://gist.github.com/tresf/b52f70300970b6f733e9c173bf43fc84 Option+Drag is a crucial feature for LMMS. How crucial is having backward compatibility? BTW, Removing SDL gets us a bit further but still crashes... https://gist.github.com/tresf/b55e2d7510921f42c30bfaff8a65aa4c The Command + Drag bug may be caused by this: |
|
For the record, I'd be disappointed but understanding if LMMS chose not to support OS X 10.8 as that's what I'm currently on. (I suspect older hardware running older OS versions might be more common due to less compelling Mac hardware releases of late but could be wrong.) By way of comparison, for similar FLOSS creative apps (but with presumably larger dev teams):
If the decision is made not to support older versions the release notes need to be updated to indicate this--currently they still say OS X 10.7 is the minimum supported. |
|
@tresf, attached you can find a small test program that I have just put together. It builds a Qt6 application which shows a window that dumps many of its pointer interactions to the output. You can extend the method What's interesting is that under Linux/Wayland my mouse is reported as a touchpad: |
|
Whoa, thanks! And it's a macOS bundle, far out!
Hilariously, my trackpad is reported as a mouse (as is my 2-button mouse): Sadly, nothing stands out as being different. My theory is because the problem is not actually with Command key nor with the drag start, but rather with the Command button inadvertently cancelling the drop/release action on the target. Of course, I haven't actually tested this recently with LMMS+Qt6 so the behavior may vary. I'll test a quick build with Qt6 so as not to spin our wheels to much. |
|
Ok, Qt6 is interesting! The bug is now reprocible with a two-button mouse, so this problem will get worse with the update to Qt6. The symptoms are identical, unless Command is release, the drop will not work. |
|
This is just a shot in the dark, but I wonder if the problem is perhaps related to the resetting of modifiers in the destructor of the lmms/src/gui/StringPairDrag.cpp Line 76 in 68ea3f5 If the modifiers somehow get reset while the item is still being dragged then this might lead to a change of mode. Can you try how it behaves if you comment out the code, @tresf? |
|
Another idea would be to change the last line with the In the successful case this should output the following: If the drag is cancelled, e.g. via the escape key, then the output is the following: I guess in the buggy case you will get the latter output. Having the lmms/src/gui/clips/ClipView.cpp Line 820 in 68ea3f5 IMO it would be cleaner to have something like a static method |
|
@tresf, I saw your comment from October 11th, 2016. I guess if you set a break point in If that's the case then I suspect that it really is a problem with Qt and MacOS. Once the code enters the The documentation states that the Last but not least, can you please set a break point in |
qDebug() << "Executing drag";
Qt::DropAction dropAction = exec( Qt::LinkAction, Qt::LinkAction );
qDebug() << dropAction;@michaelgregorius yes! It fires |
|
Then it would be interesting to find out what's happening during the
|
|
The MacOS implementation for Qt 5.15 can be found here. I did not see any key handling though. Would be interesting to know how applications that are not written in Qt behave with regards to drag & drop and the command key. |
|
I'm unaware of a program that uses Command + Drag to copy. Garage Band uses Option + Drag. |
Key handling is here. It confirms that copy should be using Alt|Option instead of ⌘ Command, although we use the LinkAction, would expect this to work. |
|
Why is |
My assumption is that it uses Link historically because the behavior was originally copied from the Automation drag/drop. Unfortunately this issue also occurs when trying to link knobs to automation segments -- where we'd probably want |
|
A stop-gap may be to fix this on Mac to match other applications -- e.g. switch to |
Copy: Link: |
|
@Veratil, right, but in Automation editor and BBEditor, it's effectively a link, so the UI is using the the right indicator there. With Piano Roll segments, the indicator should be copy, not link. |
Furthemore, this makes a lot of |
|
@michaelgregorius would you be willing to enhance the demo you created to allow us to test this out without the LMMS cruft? For example, if we can prove that drag-and-drop works normally with Command we might be able to narrow down why it won't work in LMMS. |
|
@tresf, here's a new version of the event tester. EventTester.zip Ironically my file browser froze the first time I dragged and dropped the zip file onto the text area of the browser. 😅 Here's a quick video that demonstrates how to use it: Bildschirmaufnahme_20240616_185901.webmThe "features" are:
That way you should be able to test most of the relevant scenarios. Interestingly, I cannot add additional keys once the drag is started. So if I press the "Alt" key exclusively when starting the drag and then later add the "Control" key as well when dropping on the target widget the event still only contains the "Alt" key. Please note that this is still for Qt 6. |
|
@michaelgregorius thank you! First, I have to say that the behavior with Some oddities though:
This seems to suggest that Command is causing the issue and that the behavior appears to be a bug with the What wasn't obvious to me in the LMMS source code is that Ideally, we would be able to override this behavior, as it prevents us from ever using the Command key for a drag-and-drop event. The workaround would be to rearrange these shortcuts to play nicer with the default Qt behavior. |
|
Ok, another oddity...
Of course, any Control presses are problematic on Mac if there's a context menu, because, reasons.
|
Yes, that confuses me as well. The API seems to indicate that the developers have to find out which default action to use, e.g. by using key modifiers. And then the implementation performs some checks if the developers did right. 😅 I'm starting to wonder if the intention of the API is to simply let users start dragging without evaluating the modifiers and the system then determines during the drag what's the current action to be taken. This would likely be done to ensure system consistency.
I think for that the main implementations (Windows, Linux, MacOS) would have to be compared so that we do not run into similar problems on other platforms. |
|
@tresf, here you can find an extended version of the event tester: EventTester.zip It has the following new functionality:
The default action indeed seems to describe what action is to be executed if no modifier key is pressed. If the default action is not given then the system will determine the action to be taken by evaluating the set of allowed actions and the keys that are pressed before the drag was started. In my case the mapping is as follows if all three allowed actions are checked and "Evaluate default action" is unchecked:
If the default is not given then a drag without a key modifier results in a "Move" action. Also if the set of allowed actions is not the full set then the keys map by some other rules. It is really a very complex set of rules, e.g. try experimenting with disallowing all actions and evaluating the default action. Then do just a drag with no modifier keys. In my case it is always a "Copy" action regardless of the default action. Allow just one action and it will always be the action regardless of the selected default action. |
My exact thoughts.
This is what puzzles me the most. It's as if we've been barely dodging this issue elsewhere, or Qt hilariously cares less about consistency on non-Apple OSs. The later would make sense given Apple's track record, as they do curate applications for their platform and human interface guidelines are a major part of this, but it's still bewildering that they're no one else complaining about this. I assume other applications choose to implement their own I've opened up #7325 for discussion on this matter. Initial testing is pretty positive. As it turns out, most code that allows fine-tuned dragging (e.g. via What's perhaps more concerning is the long-term effects of placing |
I noticed this nonsense too. IMO this is broken behavior. |
|
I think it would also be beneficial to get a better understanding of Qt's concepts with regards to the source and the target of a drag and their responsibilities. The source of the drag determines the (mime) type of the data that is transported via the drag and drop. What I find interesting is that it also has a say with regards to the actions that are allowed for the target, i.e. how the data is interpreted by the target. The target of a drag on the other hand can evaluate the data that's transported by the drag and can then also inspect the drop action which is partly determined by Qt's code. This can be done in IMO the solution could be to not add more I am not really sure if the It would also be interesting to know the concepts behind "Copy", "Move" and "Link" in Qt because they are not really explained, at least in the documentation of the corresponding action enums. Does "Move" for example imply that the data is moved from the source to the target in that is destroyed or not available anymore in the source after a successful action? |
I like this proposal, however this doesn't solve the originating problem, and that's the we have other mouse listeners on these same widgets. For example, knobs can be dragged to adjust values WITHOUT It could be argued that move should use QDrag, but I'm not sure it's going to behave as intended. This means that we don't have much choice but to listen for keypress to filter out non- |
We can and do inspect the data. My understanding of the problem is that the default |
I've thought about this as well. From my understanding it expects the implementation to be done by the application, not the framework (which is why this From my understanding, the various actions are for filtering intent as well as providing a UI indicator of intent only and that all other implementation details are to be handled by the application, quoting:
I do like the idea of using it for all drag actions, if it's possible. 🤞 |
Edit: Thanks to @follower for the hint.... Here's the workaround:
On Mac, the Ctrl shortcuts generally map to the Command button.
On current master branch, the Command + Drag should clone a Piano roll or BB Editor segment but does not.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: