Add ability to drag files to and from external applications by AW1534 · Pull Request #7849 · LMMS/lmms

AW1534 · 2025-04-16T01:09:15Z

Adds the ability to drag files in and out of LMMS. This required a bit more refactoring than I expected.

video2.mp4

I should note that this doesn't just work to and from the desktop, I've tested with firefox, CLion, dolphin and discord. It also works with more than just sample files (projects, presets, midis, vsts)

AW1534 · 2025-04-16T16:09:50Z

To hell with CodeFactor.

AW1534 · 2025-04-18T15:30:45Z

once #7627 is merged, I'd like to add the ability to drag sample clips out of LMMS too. That could be for a different PR though.

regulus79 · 2025-04-18T20:39:35Z

I tested this briefly, and it seems to work! I'm using nautilus on GNOME to drag files in.

Things I noticed (these aren't that important though):

Dragging in .xml files which are not presets causes a dummy instrument(?) to be added, and when you click on it, LMMS crashes. This is sort of also in master, but it gives you a warning first.
You can't drag in .sf2 files (I think this is in master too)
You can't drag in vst effects into an effect chain

AW1534 · 2025-04-18T20:47:11Z

Dragging in .xml files which are not presets causes a dummy instrument(?) to be added, and when you click on it, LMMS crashes. This is sort of also in master, but it gives you a warning first.

Okay, this should be a relatively simple fix.

You can't drag in .sf2 files (I think this is in master too)

Thats actually not in master, it's is a regression- Nice catch!

You can't drag in vst effects into an effect chain

This is out of scope as it isn't in master, but it's definitely a good idea for another PR.

regulus79 · 2025-04-18T21:44:57Z

I tested this again, and those two issues do appear to be fixed!

headquarter8302 · 2025-04-19T02:07:04Z

In Windows MSVC, dragging instruments to the Song-Editor doesn't work
Edit: I used the right-click menu to insert Mallets, OBS didn't capture the context menu

2025-04-18.23-03-41.mp4

szeli1

I would like a few things changed.
Also I'm testing this and When I drag a sample clip into AudioFileProcessor, it doesn't load the audio for me. Firstly create a sample clip and load audio, then create an empty AudioFileProcessor and try to drag the clip into the processor.
Dragging in files from outside works nicely.
What else to test?

include/Clipboard.h

plugins/AudioFileProcessor/AudioFileProcessorView.cpp

plugins/Patman/Patman.cpp

plugins/Lv2Instrument/Lv2Instrument.cpp

src/gui/editors/TrackContainerView.cpp

plugins/Vestige/Vestige.cpp

AW1534 · 2025-05-10T14:02:14Z

I would like a few things changed. Also I'm testing this and When I drag a sample clip into AudioFileProcessor, it doesn't load the audio for me. Firstly create a sample clip and load audio, then create an empty AudioFileProcessor and try to drag the clip into the processor. Dragging in files from outside works nicely. What else to test?

huh, I don't know why I'm just now seeing this comment, sorry.

Master doesn't let me drag sample clips into AFP either. In fact, I think master behaves worse, as it accepts the drop, but just has weird behaviour. So I think this is out of scope. However, I was planning to add that once your sample exporting PR is merged.

szeli1

I like the code changes and I believe the recent commits made the code easier to implement in the future which is nice. I didn't find any issues in the code.

I tested dragging samples from outside (ogg, flac, mp3) and it worked. However when I opened the file browser and dragged an instrument in, it didn't get added to the song editor. I couldn't test vestige because I could not load the instrument. I also tried to link a knob to an automation clip and it did not accept it.

include/Clipboard.h

src/core/Clipboard.cpp

src/gui/StringPairDrag.cpp

src/core/Clipboard.cpp

src/gui/editors/TrackContainerView.cpp

AW1534 · 2025-05-11T17:16:45Z

@szeli1 fixed. The issue was being caused by the hasFormat() check

AW1534 · 2025-05-11T23:09:26Z

@szeli1 any idea why the builds might be failing on windows?

szeli1 · 2025-05-14T06:56:16Z

@szeli1 any idea why the builds might be failing on windows?

Add LMMS_EXPORT to the problematic functions, the plugins can't access them without LMMS_EXPORT.

AW1534 · 2025-05-14T17:12:51Z

@szeli1 Thanks, that worked! This should be ready for merge now.

szeli1

I tested this again and everything worked as expected. I was able to drag in sound files from outside, vsts and project files worked as well.

The reason I'm not approving this is I found that snapping the lmms window to the screen's right side (for example) did not work after this change. This worked on master. I use Linux mint, I built.

Steps to reproduce:

launch lmms
grab the widow
drag it until the cursor reaches one side of the screen
normally, the window would resize to cover half of the screen
currently it does nothing

This PR is a big improvement, so I hope to get this merged.

AW1534 · 2025-05-18T17:33:12Z

this is a really weird issue, but I see no reason why my PR would cause this. Are you using a custom build to test master and AppImage to test my PR? if that's the case, you should test master with the AppImage to see if you get the same issue.

I am unable to reproduce this on the AppImage or custom build

AW1534 · 2025-05-20T20:17:36Z

@szeli1 do the keyboard shortcuts work? (super + right)

szeli1 · 2025-05-20T20:24:51Z

@szeli1 do the keyboard shortcuts work? (super + right)

I believe it didn't work for me when I tested it.

szeli1 · 2025-05-20T21:41:29Z

@szeli1 do the keyboard shortcuts work? (super + right)

Wait this happened to me in an independent branch, it seems like this is an unrelated bug

szeli1

I tested this PR and I approve it.

messmerd

Quick review

include/Clipboard.h

plugins/Lv2Instrument/Lv2Instrument.cpp

src/gui/StringPairDrag.cpp

src/gui/editors/TrackContainerView.cpp

include/Clipboard.h

plugins/AudioFileProcessor/AudioFileProcessorView.cpp

src/gui/StringPairDrag.cpp

include/StringPairDrag.h

plugins/AudioFileProcessor/AudioFileProcessorView.cpp

src/core/Clipboard.cpp

src/gui/clips/ClipView.cpp

src/gui/instrument/InstrumentTrackWindow.cpp

src/gui/tracks/AutomationTrackView.cpp

src/gui/tracks/SampleTrackView.cpp

src/gui/tracks/TrackContentWidget.cpp

src/gui/tracks/TrackView.cpp

…rsal-drag-drop2

plugins/ZynAddSubFx/ZynAddSubFx.cpp

src/core/Clipboard.cpp

Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>

src/core/Clipboard.cpp

- change `mimetypes` type to `std::map<std::string, std::set<std::string>> mimetypes` - remove lv2 and xiz from hardcoded mimetypes map

…rsal-drag-drop2

Co-authored-by: szeli1 <143485814+szeli1@users.noreply.github.com>

src/core/Clipboard.cpp

Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>

…rsal-drag-drop2

messmerd

Haven't tested it, but the code changes look fine to me.

src/core/Clipboard.cpp

Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>

szeli1

I like decodeMimeData and processDragEnterEvent, they are a huge improvement to the code.

szeli1 · 2025-08-26T11:29:43Z

include/Clipboard.h

+	 * The function also uses fallback decoding via StringPairDrag in case the type and value
+	 * were encoded in a non-file-based drag operation.
+	 *
+	 * @param _de Pointer to the QDropEvent containing drag-and-drop data.


I can't find "_de" as a param.

szeli1 · 2025-08-26T11:39:08Z

include/Plugin.h

-		const char * supportedFileTypes; //!< csv list of extensions
+		const PixmapLoader* logo;
+		const char* supportedFileTypes; //!< csv list of extensions
+		const char* supportedMimetype; //!< mimetype supported by the plugin. Should be null if no filetypes are supported


Should be csv maybe? But currently we don't need multiple new keys for one plugin.

szeli1 · 2025-08-26T11:47:03Z

plugins/AudioFileProcessor/AudioFileProcessor.cpp

 	",mp3"
 #endif
 	,
+	"samplefile",


Is "samplefile" only used by AudioFileProcessor? I believe other widgets send audio data with an other key already.
Removing the "samplefile" key may be outside of this PR's concerns.

Also patman uses "samplefile" even though it doesn't define it.

szeli1 · 2025-08-26T11:48:26Z

include/Clipboard.h

 	QString decodeKey( const QMimeData * mimeData );
 	QString decodeValue( const QMimeData * mimeData );


"// use decodeMimeData"

szeli1 · 2025-08-26T11:48:55Z

include/StringPairDrag.h

+	//! use QString Clipboard::decodeKey(QMimeData) instead
+	static QString decodeKey(QDropEvent* de);
+	//! use QString Clipboard::decodeValue(QMimeData) instead
+	static QString decodeValue(QDropEvent* de);


"// use decodeMimeData"

szeli1 · 2025-08-26T12:03:11Z

src/core/Clipboard.cpp

+	//! gets the extension of a file, or returns the string back if no extension is found
+	static QString getExtension(const QString& file)
+	{
+		QFileInfo fi(file);
+		const QString ext = fi.suffix().toLower();
+		return ext.isEmpty() ? file.toLower() : ext;
+	}


Please remove this. QT already has this functionality (QFileInfo) and lmms also implements this internally in some utility function.

szeli1 · 2025-08-26T12:06:30Z

src/core/Clipboard.cpp

+		if (it == mimetypes.end()) { return false; }
+
+		const auto& fileTypes = it->second;
+		const auto extStr = getExtension(ext).toStdString();


Suggested change

const auto extStr = getExtension(ext).toStdString();

const auto extensionStr = getExtension(extension).toStdString();

szeli1 · 2025-08-26T12:08:08Z

src/core/Clipboard.cpp

+	bool isMidiFile(const QString& ext)         { return isType(ext, "midifile"); }
+	bool isVstPluginFile(const QString& ext)    { return isType(ext, "vstpluginfile"); }
+
+	//! Gets the clipboard mimedata. NOT the drag mimedata


Move the comment into the header.

szeli1 · 2025-08-26T12:12:40Z

src/core/Clipboard.cpp

+		const QList<QUrl> urls = mimeData->urls();
+
+		QString type{"missing_type"};
+		QString value{};


Suggested change

QString value{};

QString value;

@messmerd suggested this change. It was incorrect to assume value isn't initialized when defined. This isn't the case with basic c++ types such as float and int.

src/gui/instrument/InstrumentTrackWindow.cpp

szeli1 · 2025-08-26T12:48:35Z

As I mentioned before, I'd like to see some of the mime type stuff refactored so that plugin-specific information is no longer present in the core LMMS application. Without that, our plugins are not truly plugins, are they?

You've approved this PR while plugin keys are still present in the code.

Maybe plugin descriptors should contain a mime type in addition to the file extensions. That could then be queried through PluginFactory like file extensions can.

This did happen. I think it is nice that plugins define the extensions, so this is a good change.

For example, Sf2Player would provide both "sf2,sf3" and "soundfontfile" in its descriptor. Or maybe use FileItem::FileType::SoundFont instead.

The existence of this code makes the changes not really "plugin-specific"

	bool isAudioFile(const QString& ext)        { return isType(ext, "samplefile"); }
	bool isProjectFile(const QString& ext)      { return isType(ext, "projectfile"); }
	bool isPluginPresetFile(const QString& ext) { return isType(ext, "pluginpresetfile"); }
	bool isTrackPresetFile(const QString& ext)  { return isType(ext, "trackpresetfile"); }
	bool isSoundFontFile(const QString& ext)    { return isType(ext, "soundfontfile"); }
	bool isPatchFile(const QString& ext)        { return isType(ext, "patchfile"); }
	bool isMidiFile(const QString& ext)         { return isType(ext, "midifile"); }
	bool isVstPluginFile(const QString& ext)    { return isType(ext, "vstpluginfile"); }

FileItem::FileType and the mime type seem to have an almost identical job, so there's probably also a simplification waiting to be made there - maybe a QString("filetype_%1").arg(static_cast(fileType)) mime type similar to what tracks use. Idk. Doing stuff like this is probably necessary to remove all the plugin-specific code from Clipboard, TrackContainerView::dragEnterEvent, TrackContainerView::dropEvent, and elsewhere.

Usually file types need human readable names, so I think marking them with a number complicates things.

I believe there is a much cleaner and more maintainable design waiting to be implemented, and rather than going along with the original poorly-made design by adding additional plugin-specific data hardcoded into the main application, I think this PR provides the perfect opportunity to truly fix the problem.

Keys are still hardcoded into the application, only extensions differ which is an improvement, but doesn't achieve the main goal, it doesn't truly fix the problem.

If it turns out to not be possible to move all the plugin-specific info into the plugins, then I think quarantining it to the FileItem::FileType enum within the main application would be an acceptable compromise.

This didn't happen.

My main issue is that I would like to replace string keys with enum keys. This means keys like "vstpluginfile" must be defined for example in clipboard, so the design mistakes are kept. You've approved this PR @messmerd while these design mistakes are still present.

Co-authored-by: szeli1 <143485814+szeli1@users.noreply.github.com>

allejok96

I didn't know LMMS' drag and drop system was such a horrifying mess. I like what you have done to clean up processDragEnterEvent. But there's more cleanup that needs to be done in the drag n drop code and now is the time to rethink that, before building more things on top of the old code.

allejok96 · 2025-08-31T19:38:54Z

src/core/Clipboard.cpp

+		return {type, value};
+	}
+
+	void startFileDrag(gui::FileItem* f, QObject* qo)


Why did you move this code here? It's only used by FileBrowser and requires the gui namespace.

that change was requested by @szeli1

I don't remember this, but I could be mistaken. I agree with @allejok96

Yes, this review comment. I'll revert that when I get the chance.

allejok96 · 2025-08-31T20:13:30Z

src/core/Clipboard.cpp


-	const QMimeData * getMimeData()
+	// there are other mimetypes, such as "samplefile", "patchfile" and "vstplugin" but they are generated dynamically.
+	static std::map<std::string, std::set<std::string>> mimetypes =


I strongly dislike the use of this mimetype map and I don't understand what benefit it brings.

First of all, these are not mimetypes, they are just arbitrary hard-coded and bug-prone strings.

Secondly, mimetypes are used to indicate the data format. But .xiz and .lv2 gets registered under the the same pseudo mimetype called "pluginpresetfile" which makes it possible to drag a .lv2 files into ZynaddsubFX. Mimetypes should be as specific as possible. This design removes useful information.

Thirdly, if a new plugin was created that could open .xyz files, it's not enough to simply define .xyz in the list of supported extensions, it now also has to have a pseudo mimetype. If we want to guarantee that the .xyz file cannot be opened with any other plugin we need to define yet another pseudo mimetype and corresponding isXyzFile() function to be able to call decodeMimeData(). But this is Clipboard and it should not even know about all these plugin specific formats. Like the comment says they should be generated dynamically.

Now to be fair @AW1534 you didn't create this pseudo mimetype system, it was already in place. But it feels like we should be moving to something more standardized instead of creating an every harder requirement of using this bad system.

Possible solution: instead of dealing with generalized file types, return the exact file type and let each caller check that against a list of file types that it supports. For common things like "samplefile" the list could be a constant in Sample.h etc.

I strongly dislike the use of this mimetype map and I don't understand what benefit it brings.

It was an attempt to move away from hard coded types. This attempt failed as things stand now although it partly improved the code because now plugins can define their supported file types (so the hard coded extensions are moved out of clipboard).

Secondly, mimetypes are used to indicate the data format. But .xiz and .lv2 gets registered under the the same pseudo mimetype called "pluginpresetfile" which makes it possible to drag a .lv2 files into ZynaddsubFX. Mimetypes should be as specific as possible.

I'm okay with grouping more extensions into 1 type, if they are converted to the same kind of data (for example .flac and .ogg are both audio data), this conversion should happen as soon as possible.

But this is Clipboard and it should not even know about all these plugin specific formats. Like the comment says they should be generated dynamically.

I don't know if it is possible to generate this dynamically, or if it is worth the cost of complexity. Currently gui assigns functionality to identifiers like samplefile. Therefor if we would dynamically define these identifiers, then we couldn't use them compile time. If we would declare something compile time that would replace them, then we end up in the same hard coded situation.

Possible solution: instead of dealing with generalized file types, return the exact file type and let each caller check that against a list of file types that it supports. For common things like "samplefile" the list could be a constant in Sample.h etc.

StringPairDrag::processDragEnterEvent(_dee, {"trackpresetfile", "pluginpresetfile", "samplefile", "instrument", "midifile", "soundfontfile","patchfile","vstpluginfile","projectfile", QString("track_%1").arg(static_cast<int>(Track::Type::Instrument)), QString("track_%1").arg(static_cast<int>(Track::Type::Sample))});

Here we would need to know about vstpluginfile, we could ask vst plugin for it's extensions, but then we would need to know that we are asking specifically vst plugin and not lv2 plugin for example. Therefor vst plugin is ought to be known compile time in some way.

I would suggest a simple hard coded approach where we define an enum containing all types. We would use this enum in gui, to replace strings (benefit: somebody can't misspell a type accidentally like in vst plugin's case). This solution isn't clean, but it is simple. We could still define extensions in plugins, then loop trough them to convert extensions to keys.

@AW1534 having taken a second look at the code, I realize that the only distinction between pluginpresetfile, vstpluginfile, soundfontfile and patchfile is which type of cursor icon they get. Otherwise they are all treated the same - the correct plugin is loaded and Plugin::loadFile() is called. Is it worth having different names and functions and types for the sake of a cursor icon? If all of these were loaded as pluginpresetfile, then by the grace of InstrumentTrackWindow SF2 player and Patman would gain drag and drop support and you could remove VestigeInstrumentView::dropEvent.

allejok96 · 2025-08-31T20:22:54Z

src/gui/clips/SampleClipView.cpp

 		_de->accept();
 	}
-	else if( StringPairDrag::decodeKey( _de ) == "sampledata" )
+	else if (type == "sampledata")


I can't find anything that creates a "sampledata" string pair btw

This is why I do not support using strings as keys / types. Fixing this is outside of the scope of this PR.

allejok96 · 2025-08-31T20:49:28Z

src/core/Clipboard.cpp

+		QString filePath = QUrl::fromLocalFile(f->fullName()).toString();
+
+		// Internal LMMS type
+		mimeData->setData("application/x-lmms-type", internalType.toUtf8());


Is this internal data ever used? If it should be kept it should use mimeType(MimeType).

allejok96 · 2025-08-31T21:14:43Z

src/core/Clipboard.cpp

 		return( QString::fromUtf8( mimeData->data( mimeType( MimeType::StringPair ) ) ).section( ':', 1, -1 ) );
 	}

+	std::pair<QString, QString> decodeMimeData(const QMimeData* mimeData)


Looking at its usecases I think decodeMimeData should be split in two.

Clipboard::getFile({list of supported extensions}) -> ext, path
the opposite of startFileDrag

Clipboard::getStringPair() -> key, value
the opposite of copyStringPair

Even if the return types are the same, having separate functions with specific names for specific usages makes the code much more readable.

If this was done, the caller of getFile would need to know every single supported extension. then we run into the same issues of hardcoding that this PR solved.

Even if the return types are the same, having separate functions with specific names for specific usages makes the code much more readable.

I disagree with this suggestion.

the caller of getFile would need to know every single supported extension

@AW1534 currently the caller always knows what file extension it expects, except in these two cases:

"samplefile"

In this case the caller relies on SampleDecoder so it doesn't need to know about file types. To get the supported extensions, the code could call SampleDecoder::supportedAudioTypes()

Actually, in your implementation "samplefile" is a dynamic mime type loaded by AudioFileProcessor. This means the AFP definition would need to be manually updated each time a new file format is added to SampleDecoder. And also, if APF is excluded from the build, any code using "samplefile" drag and drop would break.

"pluginpresetfile"

In this case the caller just want to know if there exists any plugin that supports a given file extension. This is used by TrackContainerView and InstrumentTrackWindow. Since the plugin specific mime types are loaded by PluginFactory I suggest that PluginFactory should be responsible for providing a list of file extensions that there exists a plugin for, similar to how SampleDecoder should be responsible for knowing which file types that can be loaded as samples. Then TrackContainerView could query this list of plugin extensions before it tries to load a plugin.

allejok96 · 2025-08-31T21:25:06Z

plugins/SlicerT/SlicerTView.cpp

-		else { dee->ignore(); }
-	}
-	else { dee->ignore(); }
+	StringPairDrag::processDragEnterEvent(dee, {"samplefile", QString("clip_%1").arg(static_cast<int>(Track::Type::Sample))});


The clipboard can contain multiple types of data, right? If dragging a sample clip would create both a stringpair and a URL then Track could use the stringpair and everything else would just use the regular sample file.

allejok96 · 2025-10-05T13:08:30Z

If this was done, the caller of getFile would need to know every single supported extension. then we run into the same issues of hardcoding that this PR solved.

I've mocked up a system of completely dynamic file types.

There are no functions like isVST() and no string literals like "*.sf2".

allejok96 · 2025-10-05T13:12:58Z

What I've learned the past days is that the clipboard system builds on unspoken rules and is in need of refactoring. Maybe we could add drag and drop without having to refactor... Idk @AW1534 would know. But at the moment, adding a lot of isFiletype() functions feels like a refactor in the wrong way.

forked from AW1534's work on LMMS#7849

AW1534 changed the title ~~Add ability to drag files in and out of LMMS~~ Add ability to drag files to and from external applications Apr 16, 2025

AW1534 added enhancement gui needs testing This pull request needs more testing labels Apr 16, 2025

szeli1 self-requested a review April 16, 2025 20:59

AW1534 removed the needs testing This pull request needs more testing label Apr 19, 2025

szeli1 requested changes Apr 26, 2025

View reviewed changes

AW1534 requested a review from szeli1 May 10, 2025 14:08

szeli1 requested changes May 11, 2025

View reviewed changes

szeli1 self-requested a review May 18, 2025 07:33

szeli1 reviewed May 18, 2025

View reviewed changes

szeli1 approved these changes May 20, 2025

View reviewed changes

messmerd reviewed May 29, 2025

View reviewed changes

messmerd reviewed May 31, 2025

View reviewed changes

include/Clipboard.h Outdated Show resolved Hide resolved

plugins/AudioFileProcessor/AudioFileProcessorView.cpp Outdated Show resolved Hide resolved

src/gui/StringPairDrag.cpp Outdated Show resolved Hide resolved

messmerd reviewed Jun 2, 2025

View reviewed changes

AW1534 requested a review from messmerd August 21, 2025 16:51

AW1534 added 2 commits August 22, 2025 02:53

make getMimeData not static

c03e652

Merge remote-tracking branch 'origin/universal-drag-drop2' into unive…

d1a13e2

…rsal-drag-drop2

messmerd reviewed Aug 22, 2025

View reviewed changes

szeli1 reviewed Aug 22, 2025

View reviewed changes

src/core/Clipboard.cpp Outdated Show resolved Hide resolved

Update src/core/Clipboard.cpp

c921c87

Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>

szeli1 reviewed Aug 22, 2025

View reviewed changes

src/core/Clipboard.cpp Outdated Show resolved Hide resolved

AW1534 and others added 3 commits August 22, 2025 23:19

apply code suggestions by messmerd

afefee6

- change `mimetypes` type to `std::map<std::string, std::set<std::string>> mimetypes` - remove lv2 and xiz from hardcoded mimetypes map

Merge remote-tracking branch 'origin/universal-drag-drop2' into unive…

448bc8e

…rsal-drag-drop2

Update src/core/Clipboard.cpp

968c18d

Co-authored-by: szeli1 <143485814+szeli1@users.noreply.github.com>

messmerd reviewed Aug 23, 2025

View reviewed changes

src/core/Clipboard.cpp Outdated Show resolved Hide resolved

AW1534 and others added 5 commits August 23, 2025 14:03

Update src/core/Clipboard.cpp

96e0ac6

Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>

change mimetype of .lv2 and .xiz to presetpluginfile

27b8421

Merge remote-tracking branch 'origin/universal-drag-drop2' into unive…

791151f

…rsal-drag-drop2

use std::set::find instead of std::ranges::find

7e921d1

rename "presetfile" to "trackpresetfile"

7a6f0bc

AW1534 requested review from messmerd and szeli1 August 25, 2025 19:58

messmerd approved these changes Aug 25, 2025

View reviewed changes

src/core/Clipboard.cpp Outdated Show resolved Hide resolved

Update src/core/Clipboard.cpp

d5d2d4b

Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>

szeli1 requested changes Aug 26, 2025

View reviewed changes

Update src/gui/instrument/InstrumentTrackWindow.cpp

cf4756b

Co-authored-by: szeli1 <143485814+szeli1@users.noreply.github.com>

allejok96 reviewed Aug 31, 2025

View reviewed changes

anytizer mentioned this pull request Sep 17, 2025

Allow replace the patch in Patman with a drag/drop #8065

Open

allejok96 added a commit to allejok96/lmms that referenced this pull request Oct 5, 2025

Drag and drop from external applications

a13542d

forked from AW1534's work on LMMS#7849

allejok96 mentioned this pull request Oct 5, 2025

Drag and drop from external applications v3 #8075

Draft

AW1534 marked this pull request as draft October 5, 2025 19:21

		QString decodeKey( const QMimeData * mimeData );
		QString decodeValue( const QMimeData * mimeData );

	const auto extStr = getExtension(ext).toStdString();
	const auto extensionStr = getExtension(extension).toStdString();

Uh oh!

Conversation

AW1534 commented Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AW1534 commented Apr 16, 2025

Uh oh!

AW1534 commented Apr 18, 2025

Uh oh!

regulus79 commented Apr 18, 2025

Uh oh!

AW1534 commented Apr 18, 2025

Uh oh!

regulus79 commented Apr 18, 2025

Uh oh!

headquarter8302 commented Apr 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

szeli1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AW1534 commented May 10, 2025

Uh oh!

szeli1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AW1534 commented May 11, 2025

Uh oh!

AW1534 commented May 11, 2025

Uh oh!

szeli1 commented May 14, 2025

Uh oh!

AW1534 commented May 14, 2025

Uh oh!

szeli1 left a comment

Choose a reason for hiding this comment

Uh oh!

AW1534 commented May 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AW1534 commented May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

szeli1 commented May 20, 2025

Uh oh!

szeli1 commented May 20, 2025

Uh oh!

szeli1 left a comment

Choose a reason for hiding this comment

Uh oh!

messmerd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AW1534 commented Apr 16, 2025 •

edited

Loading

headquarter8302 commented Apr 19, 2025 •

edited

Loading

AW1534 commented May 18, 2025 •

edited

Loading

AW1534 commented May 20, 2025 •

edited

Loading

szeli1 commented Aug 26, 2025 •

edited

Loading