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

Use Qt's Resource System (2nd approach) #1891

Merged
merged 9 commits into from
Mar 26, 2017
Merged

Use Qt's Resource System (2nd approach) #1891

merged 9 commits into from
Mar 26, 2017

Conversation

lukas-w
Copy link
Member

@lukas-w lukas-w commented Mar 21, 2015

This PR does pretty much the same as #1742, but takes a less invasive approach, touching much less code. In contrast to my first approach, embed::getIconPixmap stays (I removed it and replaced all calls in #1742), but uses Qt's resource system and QDir's search paths internally.

Even though I didn't test it, it should now be It's now possible to drop in SVGs instead of PNGs in themes without changing any code.

It's already been possible to replace any plugin's artwork by adding a file called something like e.g. monstro_logo.png to the theme folder. LMMS will then use that one instead of the plugin's built-in file. This PR changes this to monstro/logo.png instead (subdirectory vs underscore), just for the sake of easy implementation. I could not find any theme that replaces a plugin's artwork, so I hope this will have no impact on existing themes. Please let me know if I'm wrong and if there are such themes out there (on the LSP).

Support for generated .rc files was added in CMake v2.8.9 to the
QT4_ADD_RESOURCES macro. In order to support older versions of CMake, this
commit includes the source of the new macro from v2.8.9 and uses it if
necessary.
@Umcaruje
Copy link
Member

It's already been possible to replace any plugin's artwork by adding a file called something like e.g. monstro_logo.png to the theme folder. LMMS will then use that one instead of the plugin's built-in file. This PR changes this to monstro/logo.png instead (subdirectory vs underscore), just for the sake of easy implementation. I could not find any theme that replaces a plugin's artwork, so I hope this will have no impact on existing themes. Please let me know if I'm wrong and if there are such themes out there (on the LSP).

I think this won't be a problem, since theme compatibility is broken anyways (you can't use 1.1 themes on 1.2). This is a very useful feature and should be documented though.

So if I want to change the logo and/or the artwork of a plugin, I just add an png of the thing I want replaced? e.g. lb302/artwork.png and tripleoscillator/logo.png ?

@softrabbit
Copy link
Member

Even though I didn't test it, it should still be possible to drop in SVGs instead of PNGs in themes without changing any code.

FTFY.

@lukas-w
Copy link
Member Author

lukas-w commented Mar 21, 2015

So if I want to change the logo and/or the artwork of a plugin, I just add an png of the thing I want replaced? e.g. lb302/artwork.png and tripleoscillator/logo.png ?

Exactly. Note that I didn't test that one either. Tested, works.

Even though I didn't test it, it should still be possible to drop in SVGs instead of PNGs in themes without changing any code.

FTFY.

Nope, that didn't work before. We didn't have any code capable of loading SVGs. It's now possible by using QImageReader which supports SVGs (see 9175928).

@lukas-w
Copy link
Member Author

lukas-w commented Mar 22, 2015

@softrabbit Nevertheless, I'd be interested to know what you're referring to. Maybe I'm just missing something. :)

@softrabbit
Copy link
Member

This: #887 (OK, the explicit looping through possible file names was horrible, but I've loaded SVGs in LMMS for ages with that code...)

I'm guessing new QPixmap(filename) actually uses QImageReader behind the scenes. The documentation for QPixmap does hint at that in saying:

The complete list of supported file formats are available through the QImageReader::supportedImageFormats() and QImageWriter::supportedImageFormats() functions.

@lukas-w
Copy link
Member Author

lukas-w commented Mar 22, 2015

Ah thanks for the clarification. :) I didn't know QPixmap can read SVGs (maybe only on some systems?), it didn't work for me and isn't listed in the docs.

@tresf
Copy link
Member

tresf commented Apr 17, 2015

@lukas-w shall we shelve this for after the 1.2 release, or work to integrate it prior?

@lukas-w
Copy link
Member Author

lukas-w commented Apr 29, 2015

Seeing that 1.2 already has a lot of changes, it'd probably be wiser to merge this PR after 1.2.

@lukas-w lukas-w mentioned this pull request Aug 6, 2015
@tresf tresf force-pushed the master branch 2 times, most recently from 8c45c1f to 4da73f3 Compare September 15, 2015 18:32
@Umcaruje Umcaruje mentioned this pull request May 18, 2016
7 tasks
@tresf tresf added this to the 1.3.0 milestone Jul 5, 2016
@jasp00
Copy link
Member

jasp00 commented Jan 4, 2017

Why not to remove the embedding altogether? Advantages:

  • Runtime will be simpler.
  • No recompilation because of artwork.
  • Architecture-dependent size will be smaller, which is good for distros.

@lukas-w
Copy link
Member Author

lukas-w commented Jan 6, 2017

Yeah, why not. When this PR is merged it's just a matter of removing the QRC logic and installing the resources via CMake instead. No need to touch any code IIRC.

@tresf
Copy link
Member

tresf commented Jan 6, 2017

Why not to remove the embedding altogether? Advantages:

For lmms.exe/lmms (binary)? Sure. For plugins? I'd argue this could break portability and strongly advocate against it.

@jasp00
Copy link
Member

jasp00 commented Jan 6, 2017

For plugins? I'd argue this could break portability

What do you mean? An external image can be loaded portably.

@tresf
Copy link
Member

tresf commented Jan 6, 2017

An external image can be loaded portably.

It can, but it shouldn't. If a developer were to make a new LMMS plugin and distribute the binary, he should not need to write special instructions for users to extract images e.g. theme/foo/bar.

@jasp00
Copy link
Member

jasp00 commented Jan 6, 2017

If a developer were to make a new LMMS plugin and distribute the binary, he should not need to write special instructions for users to extract images

Are users not used to run installers or install packages? Anyway, if both methods are kept, official plug-ins still benefit from:

  • No recompilation because of artwork.
  • Architecture-dependent size will be smaller, which is good for distros.

@tresf
Copy link
Member

tresf commented Jan 6, 2017

Are users not used to run installers or install packages?

Generally, no. Commercial plugins do this, but it is not common for community plugins and just adds unnecessary burden to the distributor. Good installers are a lot of work to get right cross-platform.

official plug-ins still benefit from: No recompilation because of artwork.

Sure, but if unofficial plugins eventually use our code for building, we should have embedding be the default behavior. #3204.

https://github.com/PaulBatchelor/lmms-reverbsc is a good use-case for our discussion.

Architecture-dependent size will be smaller, which is good for distros.

👍

@jasp00
Copy link
Member

jasp00 commented Jan 7, 2017

it is not common for community plugins and just adds unnecessary burden to the distributor. Good installers are a lot of work to get right cross-platform.

Then let us use ZIP files for distribution, like the JAR, XPI, and OpenDocument cases. We can package Perl and Python plug-ins for LMMS, even multiple plug-ins sharing the artwork; just do not make the artwork to be part of the compilation. LMMS would be able to handle these ZIP files. The plug-in developer would run make plugin-package.

if unofficial plugins eventually use our code for building, we should have embedding be the default behavior.

Why that default? Third-party developers would also benefit from avoiding recompilation and providing separated packages, acting as a minidistro. Of course, if we give both options, it does not matter what the default is.

@tresf
Copy link
Member

tresf commented Jan 7, 2017

We can package Perl and Python plug-ins for LMMS, even multiple plug-ins sharing the artwork; just do not make the artwork to be part of the compilation.

When LMMS starts supporting non-compiled, scripted plugins, we can revisit this topic (assuming then the scripted plugins will adopt some common GUI framework). A gigantic part of our user base (> 1M downloads / year) is Windows and Windows doesn't yet ship with Perl or Python (Windows 10 may eventually change this).

Then let us use ZIP files for distribution, like the JAR, XPI, and OpenDocument cases.

Sure, but how about we start with project files first. :)

@jasp00
Copy link
Member

jasp00 commented Jan 7, 2017

We would not remove the embedding method until a better alternative is developed.

Making a drastic change such as remove all embedded resources from all of our executables assumes there's no good in keeping it the way it is today.

What are the good points for embedding in official binaries? My suggestion is to keep both options, to embed or not to embed, which could be overridden per plug-in. If embedding is done, it should happen on install rather than on build.

@tresf
Copy link
Member

tresf commented Jan 7, 2017

What are the good points for embedding in official binaries?

None.

@Umcaruje
Copy link
Member

@lukas-w now that we have diverged stable-1.2 from master, do you want to resolve the merge conflicts so we test and merge this?

@lukas-w
Copy link
Member Author

lukas-w commented Mar 26, 2017

do you want to resolve the merge conflicts so we test and merge this?

Already at it right now 😉

# Conflicts:
#	cmake/modules/BuildPlugin.cmake
#	plugins/Amplifier/logo.png
#	plugins/BassBooster/logo.png
#	plugins/Delay/logo.png
#	plugins/Eq/CMakeLists.txt
#	plugins/Eq/EqEffect.cpp
#	plugins/Eq/logo.png
#	plugins/Flanger/CMakeLists.txt
#	plugins/Flanger/logo.png
#	plugins/LadspaEffect/CMakeLists.txt
#	plugins/LadspaEffect/logo.png
#	plugins/SpectrumAnalyzer/logo.png
#	plugins/VstEffect/CMakeLists.txt
#	plugins/VstEffect/logo.png
#	plugins/carlabase/CMakeLists.txt
#	plugins/dynamics_processor/logo.png
#	plugins/ladspa_browser/logo.png
#	plugins/lb303/CMakeLists.txt
#	plugins/lb303/lb303.cpp
#	plugins/opl2/CMakeLists.txt
#	plugins/papu/CMakeLists.txt
#	plugins/peak_controller_effect/logo.png
#	plugins/stereo_enhancer/logo.png
#	plugins/stereo_matrix/logo.png
#	plugins/vestige/CMakeLists.txt
#	plugins/waveshaper/logo.png
#	plugins/zynaddsubfx/CMakeLists.txt
#	src/CMakeLists.txt
#	src/gui/GuiApplication.cpp
#	src/gui/embed.cpp
@lukas-w
Copy link
Member Author

lukas-w commented Mar 26, 2017

Done.

@Umcaruje
Copy link
Member

So I tested this out, LMMS functions as expected, no visual artifacts of any sort.

I did find a bug with the plugin artwork replacement feature though. If the plugin has an underscore in its folder name, the artwork won't get replaced.
I had 4 folders for 4 plugins with a replacement artwork.png (or in monstro's case artwork_op.png and artwork_mat.png):
screenshot from 2017-03-26 19 24 31
Only plugins without an underscore get their artwork replaced:
screenshot from 2017-03-26 19 24 16

@lukas-w
Copy link
Member Author

lukas-w commented Mar 26, 2017

Thanks for testing.

If the plugin has an underscore in its folder name, the artwork won't get replaced.

That's just a mismatch between the directory names in plugins and the actual plugin name. You have to match the plugin name, so it's tripleoscillator instead of triple_oscillator.
You can find the correct name in lines similar to BUILD_PLUGIN(tripleoscillator …) in the respective CMakeLists.txt or in the resulting library file (libtripleoscillator.so or tripleoscillator.dll).

So I guess this is good to merge?

@Umcaruje
Copy link
Member

That's just a mismatch between the directory names in plugins and the actual plugin name. You have to match the plugin name, so it's tripleoscillator instead of triple_oscillator.

Thanks, that's good to know.

So I guess this is good to merge?

LGTM 👍 I can't comment on the code though, not quite versed in cmake.

@lukas-w
Copy link
Member Author

lukas-w commented Mar 26, 2017

I can't comment on the code though

It's been two years and no one's complained about the code :) Merging

@lukas-w lukas-w merged commit 9f905bc into master Mar 26, 2017
@lukas-w lukas-w deleted the qrc2 branch March 26, 2017 20:06
tresf pushed a commit to tresf/lmms that referenced this pull request Apr 22, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
tresf pushed a commit to tresf/lmms that referenced this pull request May 10, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
liushuyu pushed a commit to liushuyu/lmms that referenced this pull request Jun 3, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
liushuyu pushed a commit to liushuyu/lmms that referenced this pull request Jun 19, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
PhysSong pushed a commit to PhysSong/lmms that referenced this pull request Jul 7, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
PhysSong pushed a commit to PhysSong/lmms that referenced this pull request Jul 7, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
PhysSong pushed a commit to PhysSong/lmms that referenced this pull request Jul 7, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
PhysSong pushed a commit to PhysSong/lmms that referenced this pull request Jul 7, 2017
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
@lukas-w lukas-w mentioned this pull request Nov 22, 2017
@PhysSong PhysSong mentioned this pull request Nov 22, 2017
sdasda7777 pushed a commit to sdasda7777/lmms that referenced this pull request Jun 28, 2022
* Remove bin2res, use Qt's resource system
* Use QDir search paths and QImageReader in getIconPixmap
* Don't include "embed.cpp" in plugins
* getIconPixmap: Use QPixmapCache, use QPixmap::fromImageReader
* Require CMake 2.8.9

* Fix ReverbSC embed usage
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