Just sharing my progress.
Qtractor.cpp line 159:
sLocPath = (QDir(QCoreApplication::applicationDirPath()).filePath("../share/qtractor/translations"));
This allows Qtractor to always find the translations, even if the local installation directory changes.
You just need to respect the structure: bin | lib | share.
---
QtractorOptions.cpp line 72:
qtractorOptions::qtractorOptions(void)
: m_settings([&]() -> QSettings {
QString appDirPath = QCoreApplication::applicationDirPath();
QString homePath = QDir::homePath();
QString app = QDir::cleanPath(appDirPath);
QString home = QDir::cleanPath(homePath);
// Comprueba si se esta ejecutando en local
bool inHome = (app == home) || app.startsWith(home + QDir::separator());
if (inHome) {
QString confPath = QDir(appDirPath).filePath(QLatin1String("../Qtractor.conf"));
return QSettings(confPath, QSettings::IniFormat);
} else {
return QSettings(QTRACTOR_DOMAIN, QTRACTOR_TITLE);
}
}())
{
g_pOptions = this;
loadOptions();
}
This ensures that if it's installed locally, the configuration won't conflict with other existing Qtractor installations.
Very useful for testing.
___
Conclusions:
Furthermore, these two requirements make it easier to create a portable Qtractor with your own plugins and samples.
You only need to:
1- Compile on Ubuntu 20 LT and add library dependencies to the lib directory.
2. Create an application run that saves the application's root path state and updates this path in the internal configuration files if it changes, and manages the lib environment variable.
The result is much cleaner than the current AppImage, more understandable, and with fewer files. It's a portable application in traditional style.
P.S.:
I used deploy to gather the libraries.
https://github.com/linuxdeploy/linuxdeploy/
Calf Suite works correctly (I still don't understand why it doesn't work in the official AppImage).
Samplv1 also works, as it uses the RubberBand library from the portable version.
re. Facilitate Portability...
please don't bother much with this, on a couple of accounts...
general support for calf/gtk2 is ever vanishing from near sight and I'd be surprised if it's not going into a silent death in just a few years at most; so, and I'm sure said this more than once before, you'll better off with the LSP than betting on a dead-horse for life :S
the good news are the aforementioned calf/gtk2 issue on the AppImage's have been already addressed and hopefully mitigated (qtractor >= v1.5.12.20+); you may assess this claim from the latest builds.
hth.
thanks
It works
Many will appreciate it :). Calf still has no replacement.
Most users value high usability, provided the result is satisfactory.
I understand all the warnings from various developers. GTK2 is reaching its end; there's no solution.
Regarding the Qtractor distribution project, I think I should put it on hold for now. It have too much technical knowledge; it's beyond me. Besides, it's a project that could unintentionally violate licenses.
Thank you for everything, especially for your patience :)
---
P.S.
I assume you're aware of this, and it's to be expected.
Qtractor is reporting an error in the messages:
qt.qpa.theme.gnome: dbus reply error: [ "org.freedesktop.DBus.Error.UnknownMethod" ] "There is no interface 'org.freedesktop.portal.Settings' in the object at /org/freedesktop/portal/desktop"
But it seems to be working correctly.
It's also reporting two other things (the old appImage version did the same):
Case insensitive sorting unsupported in the POSIX collation implementation
Numeric mode unsupported in the POSIX collation implementation
re. dbus reply error...
this happens mostly on wayland sessions and maybe due to missing the org.rncbc.qtractor.desktop file on the system directories (eg. /usr/share/applications/).
hth.
The portability approach was incorrect
The approach I started this post with isn't the right one. I'm mainly posting this in case another user else wants to try something similar.
Summary: It's not necessary to modify Qtractor or the plugins; it's feasible with the appImage.
It's better to use the appImage, which creates an isolated environment and manages libraries and things like iBus without you having to worry about them.
The best approach is a hybrid one. Project dependencies (plugins, libraries, etc.) are in user-accessible folders inside the portable distribution folder.
But the executable will be the appImage.
Managing XDG_CONFIG_HOME from the launcher (a pre-launcher for managing the distribution, not the internal AppRun of the AppImage) ensures that all configurations (qtractor and plugins) are in the distribution folder. Therefore, the plugins can also be official builds without needing modification. This avoids conflicts with other possible installations of Qtractor or the plugins.
This launcher also updates the paths in plugin and other configuration settings when the distribution folder is moved.
It's technically feasible; my tests confirm this.
Greetings :)
Add new comment