-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin+Data search paths #1719
Plugin+Data search paths #1719
Conversation
This singleton class handles management of plugin search paths and plugin discovery. Search paths are (if they exist): * <lmms-exe-dir>/../lib/lmms: This is the common location on Unixoids (Not included in Windows builds) * <lmms-exe-dir>/plugins: For portable and Windows installations * The path given by the compile define LMMS_PLUGIN_DIR * Environment variable LMMS_PLUGIN_DIR if given This commit also tweaks the build script to output built plugins to "${CMAKE_BINARY_DIR}/plugins". This way lmms can find plugins during development without the need to use `make install`. Plugin::getDescriptorsOfAvailPlugins and ConfigManager::pluginDir were removed.
Also add LMMS_DATA_DIR env var to "data:" search paths. When lmms is launched from its build directory (without `make install`ing), LMMS_DATA_DIR can be passed to point lmms to the "data" directory in the source tree.
9860c8b
to
45fb6a3
Compare
@lukas-w Does this address the the single |
Hm I guess it doesn't. What limitation exactly are you referring to? |
Minor and really unrelated, but we don't support multiple versions running simultaneously due to the the default and non-overridable location of |
@lukas-w If this fixes the Having a dedicated class for this and removing complexity and responsability from the other classes is a great improvement as well! We just need to be sure that this really does not breaks and remove any discoverability from before. Also, just so that I understand the scope of this PR, it is just about the discoverability of already built-in or external LMMS plugins right? Does it affects LADSPA? |
While this PR touches some LADSPA code due to the refactorings that were made, it should only add discoverability. Some testing wouldn't hurt of course. :)
Hm… Yes, we should probably do something about that. How about including the version number in the file name? -> |
That was suggested previously as well. This is a pretty good idea I feel. There's a chance that it will still cause issues with master vs. stable testing though since we don't bump our CMakeLists.txt for the master branch. |
# Conflicts: # include/Plugin.h # src/core/Plugin.cpp
# Conflicts: # include/ConfigManager.h # include/Engine.h # plugins/CMakeLists.txt # plugins/vst_base/CMakeLists.txt # plugins/vst_base/Win64/CMakeLists.txt # src/core/Engine.cpp
I went another step ahead in 5592d07 by looking for a [~/src/LMMS/lmms/build]$ ./lmms No |
👍 Awesome! |
@lukas-w I'm on Ubuntu 14.04 |
@zonkmachine I don't get what you're trying to say. LMMS only ships with .ogg samples. This commit/PR does not touch any sound/sample loading code. |
Some tweaks on how plugins and data files are discovered by the program.
Introduce
PluginFactory
classThis singleton class handles management of plugin search paths and plugin
discovery. Search paths are (if they exist):
<lmms-exe-dir>/../lib/lmms
: This is the common location on Unixoids(Not included in Windows builds)
<lmms-exe-dir>/plugins
: For portable and Windows installationsLMMS_PLUGIN_DIR
LMMS_PLUGIN_DIR
if givenThis commit also tweaks the build script to output built plugins to
"${CMAKE_BINARY_DIR}/plugins". This way lmms can find plugins during
development without the need to use
make install
.Plugin::getDescriptorsOfAvailPlugins
andConfigManager::pluginDir
wereremoved.
Add some search path support
Plugins and data can now be discovered/opened via QDir's search path feature.
Instead of writing (for example)
QFile f = ConfigManager::inst()->dataDir() + "defaultTheme/style.css";
One can now use
This will search in all directories added via
QDir::addSearchPath("data", …);
.Commit dc1f8dc also adds
LMMS_DATA_DIR
env var to "data:" search paths if given.When lmms is launched from its build directory (without
make install
ing),LMMS_DATA_DIR
can be passed to point lmms to the "data" directory in thesource tree.
Why
The main issue that reduced my productivity during development was the constant need to run
make install
with every build to test changes and then run the installed binary. It greatly increased compilation time for me. When running the not-installed lmms binary (in thebuild
directory), lmms could not find any plugins or data such as styles/icons.This pull request fixes that issue. In the build directory, I can now just run
[ ~/src/LMMS/lmms/build ]$ LMMS_DATA_DIR=../data ./lmms
Closes #1958