Since I found mp3 files can't be retrieved by QMediaPlayer from resource, I figure it out to use them as local file. I use this cmd with a little modification to copy files into installation directory:
copydata.commands = $(COPY_DIR) $$PWD/resources/sound $$OUT_PWD/HomeControl.app/Contents/MacOS
first.depends = $(first) copydata
export(first.depends)
export(copydata.commands)
QMAKE_EXTRA_TARGETS += first copydata
So those files existed in the /HomeControl.app/Contents/MacOS/sound. From Qt Creator the app plays the mp3 perfectly, but if executed from the build directory it doesn't play the mp3 at all! Really don't know why.
arm away btn clicked
current media: "file:///Dev/Qt_Sample/build-test_widgets-Desktop_Qt_5_3_0_clang_64bit-Debug/HomeControl.app/Contents/MacOS/sound/System_Arm_Away.mp3"
disarm stay btn clicked
current media: "file:///Dev/Qt_Sample/build-test_widgets-Desktop_Qt_5_3_0_clang_64bit-Debug/HomeControl.app/Contents/MacOS/sound/System_Disarmed.mp3"
Is there any difference from executing in the Qt creator & directly from the App? Like debug mode or what?
Or is there other ways to correctly deploy mp3 files into the bundle?
This is how I build in resources for OS X bundles:
mac {
Resources.files = dirInTheProjectDirectory
Resources.path = Contents/MacOS
QMAKE_BUNDLE_DATA += Resources
}
You can call Resources whatever you fancy.
That copies them to Contents/MacOS/dirInTheProjectDirectory. You can then access them with QDir(QCoreApplication::applicationDirPath()+"/dirInTheProjectDirectory/");
The likely problem is when you're accessing them in your code you're pointing to the path in the build directory, and not the path that's within your bundle.
Here's my final solution. Thank you #nicholas-smith.
In the .pro file:
# deploy with mp3 folder
mac {
Resources.files = ./resources/sound
Resources.path = Contents/MacOS
QMAKE_BUNDLE_DATA += Resources
}
Then accessing those file with:
// pass the path of mp3 to the QMediaPlayer
playAudio(QCoreApplication::applicationDirPath()
+ "/sound/System_Disarmed.mp3");
From log it shows:
arm away btn clicked
current media: "file:///Dev/Qt_Sample/build-test_widgets-Desktop_Qt_5_3_0_clang_64bit-Debug/HomeControl.app/Contents/MacOS/sound/System_Arm_Away.mp3"
Related
I completed the CurrencyConverter example using Xcode 2.5 on Mac OS X Tiger 10.4.11, which I called CurrencyConverter2 since it was my second attempt. Since I've read that GNUstep is compatible with the Mac OS X Tiger version of Cocoa, I wanted to try building this Xcode project in GNUstep, which I am interested in learning.
I was able to install GNUstep on a VM running FreeBSD 12.0. I created a Makefile called GNUmakefile. Here are the contents of GNUmakefile:
include $(GNUSTEP_MAKEFILES)/common.make
APP_NAME = CurrencyConverter2
CurrencyConverter2_OBJC_FILES = main.m ConverterController.m Converter.m
CurrencyConverter2_RESOURCE_FILES = Info.plist English.lproj/MainMenu.nib
include $(GNUSTEP_MAKEFILES)/application.make
When building the program using gmake, it appears that everything was built correctly:
This is gnustep-make 2.7.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for app CurrencyConverter2...
Creating CurrencyConverter2.app/....
gmake[3]: Warning: File 'main.m' has modification time 21869 s in the future
Compiling file main.m ...
Compiling file ConverterController.m ...
Compiling file Converter.m ...
Linking app CurrencyConverter2 ...
gmake[3]: warning: Clock skew detected. Your build may be incomplete.
Creating CurrencyConverter2.app/Resources...
Creating stamp file...
Creating CurrencyConverter2.app/Resources/Info-gnustep.plist...
Creating CurrencyConverter2.app/Resources/CurrencyConverter2.desktop...
Copying resources into the app wrapper...
However, when I try to open CurrencyConverter2.app, the main window does not show up at all.
My hunch is that for some reason my Makefile is not recognizing English.lproj/MainMenu.nib.
I also tried using a tool called buildtool that is able to build Xcode projects using GNUstep, but it complained that it couldn't find English.lproj even though it is in the directory that I ran buildtool.
When converting a Mac app to GNUstep, you need to make a GNUstep-specific Info-plist template that roughly mirrors Info.plist (which is Mac-only).
At build time, the Info-plist template is used to generate two files: Info-gnustep.plist, and the app's .desktop (freedesktop.org desktop entry) file.
Info-gnustep.plist contains Info entries used at loadtime/runtime, such as the name of the principal class, the main-menu nibfile to load, etc.
The app's .desktop file contains Info entries used for registering the app with the desktop-environment/file-browser, such as the app's desktop-menu category, the executable path, supported MIME types, etc. (Note: 'make install' currently doesn't register a GNUstep app with the desktop environment; In order for an installed GNUStep app to appear in the desktop menus, its .desktop file - found in its Resources folder - must be manually registered using the 'desktop-file-install' command-line tool.)
The Info-plist template should be named, "{APP_NAME}Info.plist", and can contain a standard XML-format plist, or a simple text-list format:
{
{KEY1} = {VALUE1};
{KEY2} = {VALUE2};
...
}
For CurrencyConverter2, create a textfile named "CurrencyConverter2Info.plist" in the same directory as the Makefile, with the contents:
{
ApplicationName = CurrencyConverter2;
FreeDesktopCategories = ("Utility", "X-GNUstep");
NSExecutable = "CurrencyConverter2";
NSMainNibFile = "MainMenu.nib";
NSPrincipalClass = NSApplication;
NSRole = Application;
}
GNUstep-make will automatically find CurrencyConverter2Info.plist, so it doesn't need an entry in the Makefile.
Unrelated to the Info-plist template issue, you can also make these changes to your Makefile:
Info.plist is Mac-only, so it can be removed from
CurrencyConverter2_RESOURCE_FILES
MainMenu.nib can be specified as a localized resource (so it no longer needs English.lproj in its pathname) by removing it from CurrencyConverter2_RESOURCE_FILES and adding these two lines to your Makefile:
CurrencyConverter2_LOCALIZED_RESOURCE_FILES = MainMenu.nib
CurrencyConverter2_LANGUAGES = English
I am using Nreco Video Converter for take video thumbnail on my MVC project. App is working correctly on local but it shows error on live host
Error is
Access to the path 'C:\Inetpub\vhosts********\httpdocs\bin\ffmpeg.exe' is denied.
I did search this file in my code and host bin folder but I can't found. NReco's site says
Simple and easy to use video conversion .NET library: all you need is one assembly (FFMpeg is embedded)
There is no ffmpeg.exe file in local and host bin folder or anywhere.
How can i fix this?
Thanks.
VideoConverter is a .net wrapper for ffmpeg tool (I'm an author of this library) and ffmpeg.exe is extracted into app bin folder (default location) on first use. On your live host asp.net process cannot write to app bin folder; this may be fixed by specifying another location, for example:
var ffmpeg = new FFMpegConverter();
ffmpeg.FFMpegToolPath = System.Web.HttpContext.Current.Server.MapPath("~/App_Data");
I am creating a sand-boxed application on MAC(10.9).When App Sand-boxed is off then i am able to get files and folders from any path. But when I does App Sand-boxed enabled it's not accessing any files and folders from any path.
Getting file and folder from path ("/Volumes/DriveName" or "/" etc.) when App Sand-boxed is off using Qt 5.0
// for folders
QStringList folderlist;
QDir curDir = QDir(path);
curDir.setFilter(QDir::Dirs);
QFileInfoList list = curDir.entryInfoList();
for(;<list.size;)
{
QfileInfo fileInfo = list.at(i);
folderList << fileInfo.filePath();
}
// for files
QStringList filelist;
QDirIterator dirIn(path,filterfiles,QDir::AllEnteries);
while(dirIn.hasnext())
{
dirIn.next();
QfileInfo fileInfo = dirIn.fileInfo();
filelist<< fileInfo.filePath();
}
What i do same when App sand-boxed is enabled?
That's the point of a sandbox, you can only access resources within the sandbox. A user may add files to the sandbox, but that requires your application to launch a file open dialog box, so they can choose the file they want to work with.
I suggest you start by reading the Apple documentation here.
I develop Firefox extension with bundled executable file which should be run on browser startup.
To run process I need get nsIFile or nsILocalFile instance which points to executable file.
I know one solution how to get it using directory service:
var file = Components.classes["#mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("ProfD", Components.interfaces.nsIFile);
file.append("extensions");
file.append("<extension id>");
file.append("<relative path>");
But this solution has two disadvantages:
It doesn't work in development mode, when instead of installed extension I have only text file with real extension path
I'm not sure that it will work on all Firefox configurations because of hardcoded "extensions" part of the path
So is there any nicer way to run executable file which comes with Firefox extension?
Thanks.
You are making way too many assumptions about the directory structure of the Firefox profile - don't. The Add-on Manager API lets you get the path of a file inside the extension, you should use it:
Components.utils.import("resource://gre/modules/AddonManager.jsm");
AddonManager.getAddonByID("<extension id>", function(addon)
{
var uri = addon.getResourceURI("<relative path>");
var file = uri.QueryInterface(Components.interfaces.nsIFileURL).file;
...
});
A restartless addon's startup function (in the bootstrap.js file) will receive, as its first parameter, the path where the addon is installed. You can then play various tricks to read files inside the .jar file, if any: see https://github.com/protz/GMail-Conversation-View/blob/master/bootstrap.js#L55 as an example.
In a non-restartless case, I must confess I don't have much of an idea :).
I found this thread looking for a way to reference a path to an image hosted in extension's directory from a content script. Here's a solution:
Include your files in web_accessible_resources in the extension's manifest.
"web_accessible_resources": [
"images/*"
]
Absolute paths to these resources contain randomly generated UUID, therefore we're using runtime.getUrl() giving it the path relative to manifest.json. Example:
let myImg = document.createElement('img');
myImg.src = browser.runtime.getURL("images/my-img.png")
I'm having a little trouble making my app bundle work from the terminal or just double clicking it.
This App actually compiles, links and runs perfectly within the Qt Creator IDE. But, if I try to open it from the terminal I get a "media/file.x file not found" error. The App bundle nor the /Contents/MacOS/executable is finding the "media" folder that is supposed to be beside the executable.
In my app I do something like:
openFile("media/file.x");
In Windows and Linux, this file WILL be found if the "media" folder is exactly in the same hierarchical position of the executable (beside it). On the Mac I have discovered it works differently cause Qt Creator builds an "App Bundle" and the actual executable is inside the /Contents/MacOS folder, so I copied the "media" manually there. This worked without any hassle when "playing" my app from the Qt Creator but as mentioned before it doesn't work when running the bundle itself.
So does anyone know where or how can I homogenize the look for this "media" folder so it works on both: Qt Creator and the App bundle?
Lately, I have been using the following command to "install" the folder on the bundle.
mac {
MediaFiles.files = media
MediaFiles.path = Contents/MacOS
QMAKE_BUNDLE_DATA += MediaFiles
}
Thanks for your help.
After looking for a few days I found a couple of posts discussing the relative path problem. I was just not searching with the right words... The answer is displayed in:
Relative Paths Not Working in Xcode C++
http://www.experimentgarden.com/2009/06/how-to-load-resource-from-your.html
Basically it is necessary to add this:
//On the include part
#ifdef __APPLE__
#include "CoreFoundation/CoreFoundation.h"
#endif
// On the main of your app
// This makes relative paths work in C++ in Xcode by changing directory to the Resources folder inside the .app bundle
#ifdef __APPLE__
CFBundleRef mainBundle = CFBundleGetMainBundle();
CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
char path[PATH_MAX];
if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
{
// error!
}
CFRelease(resourcesURL);
chdir(path);
std::cout << "Current Path: " << path << std::endl;
#endif
// ----------------------------------------------------------------------------
IMPORTANT:
The chdir, changes the working path of the app, so it is not necessary to change you relative code after that...