LMMS
Command + Drag does not work (Apple)
Edit: Thanks to @follower for the hint.... Here's the workaround:
[...] through random key mashing happened to make drag copy appear to work by pressing command (butterfly) and option (alt) simultaneously!
Edit: 2024 @tresf: It appears Ctrl can fix this on nightly versions, but it's very hard to time properly.
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:
- Using OSX 10.7 or higher, install latest master branch (mirror available here: @tresf/lmms-1.1.91-mac10.8.dmg)
- Create a piano roll segment
- Try to clone it using a modifier key
- No modifier keys work for cloning, instead a Right Click, Copy and Right Click, Paste is needed.
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.
When did the Qt5 change happen
Between RC1 and the upcoming RC2 per https://github.com/LMMS/lmms/issues/2611
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...
"Note: On OS X, the ControlModifier value corresponds to the Command keys on the Macintosh keyboard, and the MetaModifier value corresponds to the Control keys. The KeypadModifier value will also be set when an arrow key is pressed as the arrow keys are considered part of the keypad."
But some people claim modifiers() can't be trusted. Is this an underlying Qt5 bug? Note, we use Qt 5.5 due to a bug with macdeployqt on 5.6 so if this is a bug with 5.5, we may between a rock and a hardplace in regards to moving from Qt4.
@tresf have you tried to code that hard? I've seen that somewhere in the code with that flower string. “⌘”
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 qDebug per https://bugreports.qt.io/browse/QTBUG-47316. The underlying data is fine. This can be observed by changing qDebug() << txt.toUtf8() to qDebug() << txt.toUtf8().data().
Back to the drawing board...
~~Ok... I'm fairly certain the bug stems from the StringPairDrag object constructor. For some reason with Qt5 it's escaping the newlines and double quotes.~~
~~According to qDebug()~~
~~Qt4:~~
"tco:0:<?xml version="1.0"?>
<!DOCTYPE>
..."
~~Qt5:~~
"tco:0:<?xml version=\"1.0\"?>\n<!DOCTYPE>
..."
~~As far as I understand, this will break the construction of a new TCO because it's contents will be unparsable, but if that's the case, why only on Mac?~~
~~Thoughts? Is there a flag or a QDomDocument QString or toUTF8() change I'm missing here?~~
To help you, someone should work on Linux, add traces (fprintf(stderr,) to the drag and drop process, and make a new branch so that you can test and provide feedback.
The above video demonstrates what happens when replacing Qt::ControlModifier with Qt::ShiftModifier (and subsequently actually using the Shift key while dragging).
~~After a few hours of testing, I'm fairly certain Qt 5.5 is ignoring any mousePressEvent when ⌘ Command key is being pressed. All other shortcuts seem to be OK.~~
~~I tested this by placing a qDebug statement at the top of TrackContentObjectView::mousePressEvent(...).~~
~~This debug line shows with all modifiers except ⌘ Command. I think this is a bug with Qt5.5 and possibly others...~~
Components that are broken with this behavior:
- Clone track using
⌘ Command+ Drag handle - Linking Automation Editor using
⌘ Command+ (any control within LMMS) -
⌘ Command+ Drag-cloning patterns inside Song Editor, Beat/Bassline Editor
In Qt 5.6, at least that part seems to work for me. With
qDebug() << "TCOV::mousePressEvent" << me->modifiers();
as the first line in TrackContentObjectView::mousePressEvent and dragging while holding ⌘, I get
TCOV::mousePressEvent QFlagsQt::KeyboardModifiers(ControlModifier)
as expected. The pattern still doesn't copy though. Where I see it break down is around TrackContentWidget::dropEvent, which gets triggered in Qt 4.8.7, but not in 5.6.1.
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?
In Qt 5.6, at least that part seems to work for me. With
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 mousePressEvent. It's not firing on TrackContentWidget::dropEvent. That seems to be the place where the actual pasteSelection code gets fired.
If you blindly replace all instances of Qt::ControlModifier with Qt::ShiftModifier it all works with the shift key.
Side note... DON'T use Qt::MetaModifier because Mac translates Ctrl to toggle the Qt::RightButton and then all of the Qt::LeftButton logic fails. ⚱
If macdeployqt is still broken then we can't package with 5.6 due to QTBUG-53533 although I do consider this stellar news.
See also https://github.com/LMMS/lmms/issues/2862.
Ugh... https://bugreports.qt.io/browse/QTBUG-53533 https://bugreports.qt.io/browse/QTBUG-56814 https://bugreports.qt.io/browse/QTBUG-54086
@teeberg I've patched the installation process to use the 5.5 version of the macdeployqt for bundling, while still using the latest version for compiling here https://github.com/tresf/lmms/commit/fc899978f8cf3a5724863778f0c7e78969b1ec34. This allows us to use Qt 5.6 or higher without suffering from #2862.
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:
- Splash screen
- Crash while attempting to initialize the audio devices
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:
https://bugreports.qt.io/browse/QTBUG-48795
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):
- Blender supports Mac OS X 10.6+ (Snow Leopard onward)
- Gimp supports Mac OS X 10.6+ (Snow Leopard onward)
- Inkscape supported Mac OS X 10.7+ (and somewhat 10.5-10.6) for the immediate previous release but currently has no OS X binaries of the latest release.
- Ardour supports Mac OS X x 10.5+ (Leopard onward)
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.
In terms of the error message from running the 10.11 build--did you have the correct minimum system version set for compilation?
There seems to be two primary causes of backward compatibility issues with OS X apps:
- Incorrect minimum OS version settings causing use of new optimisations/features rather than backward compatible shims (fixable).
- Newer features not supported by older releases.
Also, the later "Symbol not found: ___exp10f" error messages seems to potentially fit into the first category:
10.8 was the planned dev environment for the 1.2 release. Many patches for 1.2 were due to Apple being mid-stdc++ during this SDK.
Tha said, the Command + Drag bug is the only outstanding, but one of which has dire consequences.
If you have time to address this, we'd be happy to release a 10.8 DMG.
Furthermore, we'd be happy to release one anyway if it's worth living without automation.
Perhaps a 3rd option is a 10.8 Qt4 release. The new theme has many bugs with Qt4 on Mac (some of which make it impossible to read file names) but it does fix the Command Drag bug. Thoughts welcome.
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.
@follower, we've added 10.8 build to our downloads page. Can you please test this on 10.7 so we know how best to document in the release notes? (Warning, it still suffers the Command + Drag bug)
https://lmms.io/download/#mac
Ummm, so, this is just a quick comment (I've got some other thoughts but they'll have to wait :) )...
I just tested the 10.8 build (1.2.0-rc2.6) (thanks for going to the effort of building that, btw :) ) and through random key mashing happened to make drag copy appear to work by pressing command (butterfly) and option (alt) simultaneously! It seems to work with at least beat blocks and automation knob drag copies...
Should this be working? :D
While I'm at it... my "other thoughts" mentioned above was that when I was researching OS X version support for my earlier post I totally forgot about Mixxx which is particularly relevant both because it's another audio application and it uses QT:
- "Mixxx 2.0.0 supports Mac OS X 10.5+ (Intel)"
My initial investigations suggest they're now using QT5 (?) I could be wrong on that.
These files might be of interest in relation to the linking issues [edit: #2862] I seem to recall:
- https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/qt5.py
- https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/qt4.py
- https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/osx/OSConsX.py
- https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/osx/otool.py
I'm not sure if they use command drag anywhere--I initially thought they did for copying tracks into crates but it seems like the "+"/drag copy happens without key modifiers.
Thanks again for pursuing this issue. :)
It appears to be affected by #2892 also (can't remember if I've mentioned that previously) except more severely as the menu backgrounds are white, not grey.
Was able to play around with making some "music" with the kick and triple osc keyboard, so it seems like a promising start. :)
Since it seems to be working okay I'll switch to using that version until I encounter something problematic.
Should this be working? :D
No it shouldn't, but it makes more sense why it's being ignored if it thinks an additional modifier key need to be held. How well does it work? Is it intermittent or does it work 100% of the time when ALT is held? If that is the case, we may be able to workaround it. I'm intrigued now.
These files might be of interest in relation to the linking issues [edit: #2862] I seem to recall:
Thanks. Take a look at this unused script.
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/unused/create_mixxx_dmg.sh#L39-L149
This has been superseded by the otool.py script they've authored themselves, used by scons here:
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/build/osx/OSConsX.py#L275-L282
Long story short... It's a lot of work due to a botched upstream tool. :/
It appears to be affected by #2892 also (can't remember if I've mentioned that previously) except more severely as the menu backgrounds are white, not grey.
~~Right, the new theme has a bunch of issues with Qt4 on Mac. We can likely fix 99% of these in style.css if someone wants to take the time to hack at it.~~ Wait are you saying you suffer these bugs on Qt5?
How well does it work? Is it intermittent or does it work 100% of the time when ALT is held?
AFAICT (from the admittedly limited testing with BB & knob drag/copy I've done so far) it works 100% of the time.
I'm intrigued now.
You and me both. :)
Long story short... It's a lot of work due to a botched upstream tool. :/
Yeah, I suspected that was the case.
Incidentally, I'm a little confused about how all the different aspects (e.g. {build OS version; QT version; run OS version} vs. {app runs; drag+copy works} ) interact, so wanted to clarify the current situation. Primarily because I wasn't sure if OS X 10.11 release (which uses QT 5.6?) has a correctly working drag+copy? Does it?
Also, wanted to know if you tried setting 10.8 as the min OS version when building on 10.11?
Wait are you saying you suffer these bugs on Qt5?
Yes (the mouse pointer is not visible in the screenshot but was on the "Empty" template entry):
As far as I recall, I deleted the .lmmsrc.xml file before testing...
The menu icons in the classic theme display correctly.
(Also, I get crashes on exit most of the time that seem related to QT clean-up operations but that's been pretty constant with all the versions I've used and doesn't seem to prevent correct function.)
Primarily because I wasn't sure if OS X 10.11 release (which uses QT 5.6?) has a correctly working drag+copy? Does it?
Yes, it does both Qt5.5 and Qt5.6 have working option-drag (Qt5.6 is useless due to the macdeployqt bug, but I have a workaround to get us on Qt5.6 if needed. The option-drag bug seems to be a combination of Qt5 + Xcode version which causes it. Builds created on 10.11 + Xcode 8 don't seem to suffer the option-drag bug. I believe it to be the newer version of Xcode which makes the difference.
also, wanted to know if you tried setting 10.8 as the min OS version when building on 10.11?
Yes, about a month ago but not for this latest build. AFAIK, that just sets the SDK to an older version, which needs to be explicitly installed anyway (no backward compat magic going on). I had a 10.11 build environment running Xcode 5.5.1 successfully (and then this setting would toggle between Xcode 7/8 and Xcode 5) but other than helping dodge the legacy build environment bugs and legacy brew dependencies the outputted app wasn't any better (same drag bug occurred). This 10.8 build was done directly on 10.8.
AFAIK, that just sets the SDK to an older version, which needs to be explicitly installed anyway (no backward compat magic going on).
My understanding is that there is actually some backward compatibility magic going on, with the correct configuration. :)
Specifically, CMAKE_OSX_DEPLOYMENT_TARGET is used to set -mmacosx-version-min but if it is used to set the minimum version, then CMAKE_OSX_SYSROOT needs to be set to use the newer SDK version that is installed on the build host.
CMakeCache.txt includes the following comments (re: weak-linking):
//Minimum OS X version to target for deployment (at runtime); newer
// APIs weak linked. Set to empty string for default value.
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=
//The product will be built against the headers and libraries located
// inside the indicated SDK.
CMAKE_OSX_SYSROOT:STRING=
In addition to weak-linking (which presumably can have its own issues) it also disables certain optimisations for backward compatibility (via):
"The compiler and linker are capable of using features and performing optimizations that do not work on older OS versions.
-mmacosx-version-mintells the tools what OS versions you need to work with, so the tools can disable optimizations that won't run on those OS versions. If you need to run on older OS versions then you must use this flag."The downside to
-mmacosx-version-minis that the app's performance may be worse on newer OS versions then it could have been if it did not need to be backwards-compatible. In most cases the differences are small."
For additional details: see & see
Also, I'm uncertain how far back this works.
But, I assume we'd want:
CMAKE_OSX_DEPLOYMENT_TARGET=10.8 # Maybe even 10.7?
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk # Or wherever it is.
So, it might be worth trying, in order to hopefully enable a return to a single download and deal with some of the version-related issues...