Skip to content
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

Merged
merged 10 commits into from
Jun 14, 2015
Merged

Plugin+Data search paths #1719

merged 10 commits into from
Jun 14, 2015

Conversation

lukas-w
Copy link
Member

@lukas-w lukas-w commented Jan 29, 2015

Some tweaks on how plugins and data files are discovered by the program.

Introduce PluginFactory class
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.

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

QFile f("data:defaultTheme/style.css");

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 installing),
LMMS_DATA_DIR can be passed to point lmms to the "data" directory in the
source 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 the build 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

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.
@lukas-w lukas-w force-pushed the cmake_dist branch 2 times, most recently from 9860c8b to 45fb6a3 Compare January 29, 2015 15:27
@tresf
Copy link
Member

tresf commented Jan 29, 2015

I can now just run LMMS_DATA_DIR=../data ./lmms

@lukas-w Does this address the the single ~/.lmmsrc.xml limitation we have today? I feel your pain on the make install part. Very cool.

@lukas-w
Copy link
Member Author

lukas-w commented Jan 30, 2015

Does this address the the single ~/.lmmsrc.xml limitation we have today?

Hm I guess it doesn't. What limitation exactly are you referring to?

@tresf
Copy link
Member

tresf commented Jan 30, 2015

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 ~.lmmsrc.xml.

@badosu
Copy link
Contributor

badosu commented Jan 30, 2015

@lukas-w If this fixes the make install issue to recognize plugins I am totally into it :-).

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?

@lukas-w
Copy link
Member Author

lukas-w commented Feb 5, 2015

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. :)

Minor and really unrelated, but we don't support multiple versions running simultaneously due to the the default and non-overridable location of ~.lmmsrc.xml.

Hm… Yes, we should probably do something about that. How about including the version number in the file name? -> ~/.lmmsrc.1.1.0.xml

@tresf
Copy link
Member

tresf commented Feb 6, 2015

Hm… Yes, we should probably do something about that. How about including the version number in the file name? -> ~/.lmmsrc.1.1.0.xml

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
@lukas-w lukas-w merged commit cc454b2 into master Jun 14, 2015
@lukas-w lukas-w deleted the cmake_dist branch June 14, 2015 19:38
lukas-w added a commit that referenced this pull request Jul 28, 2015
This allows to just run "./lmms" during development, without installing
or specifying a data path.

Related: #1719 #1958
@lukas-w
Copy link
Member Author

lukas-w commented Jul 28, 2015

I went another step ahead in 5592d07 by looking for a CMakeCache.txt on startup and reading the lmms source path out of it, then using the data dir in that source dir.
Launching LMMS correctly during development is now as simple as

[~/src/LMMS/lmms/build]$ ./lmms

No make install required.

@midi-pascal
Copy link
Contributor

👍 Awesome!

@zonkmachine
Copy link
Member

@lukas-w
Cool but...
For me this:
1 - Only works for .ogg files
2 - After install, breaks sound for all samples but .ogg files.

I'm on Ubuntu 14.04

@lukas-w
Copy link
Member Author

lukas-w commented Jul 28, 2015

@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.
Please make sure what you're experiencing is related to this PR, and - if needed - open a new issue describing your problem.

ThomasJClark pushed a commit to ThomasJClark/lmms that referenced this pull request Sep 12, 2015
This allows to just run "./lmms" during development, without installing
or specifying a data path.

Related: LMMS#1719 LMMS#1958
@tresf
Copy link
Member

tresf commented Oct 19, 2015

@lukas-w this doesn't seem to work with VSTs unless make install has been run. Any idea why? I was testing #2390 and realized after using stable-1.1 as a baseline that simply running ./lmms from the build directory doesn't seem to satisfy the VST portion. Edit: Created #2419 for tracking.

tresf added a commit to tresf/lmms that referenced this pull request Apr 22, 2017
lukas-w pushed a commit that referenced this pull request May 6, 2017
* Make factory samples relative
Fixes #3491
Related #1719
PhysSong pushed a commit to PhysSong/lmms that referenced this pull request Jul 8, 2017
* Make factory samples relative
Fixes LMMS#3491
Related LMMS#1719
@tresf tresf mentioned this pull request Oct 3, 2017
16 tasks
lukas-w added a commit that referenced this pull request Oct 17, 2017
Fix regression from #1719
Fixes #3886
tresf pushed a commit that referenced this pull request Oct 17, 2017
sdasda7777 pushed a commit to sdasda7777/lmms that referenced this pull request Jun 28, 2022
* Make factory samples relative
Fixes LMMS#3491
Related LMMS#1719
sdasda7777 pushed a commit to sdasda7777/lmms that referenced this pull request Jun 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants