I have a helper tool in my bundle that resides in Contents/Library/PriviledgedHelperTools inside my .app. Can I somehow read the version of the info.plist of this program?
The Helper Tool itself is NOT a .app bundle, it is a binary that is embedded in my .app bundle residing in Contents/Library/PriviledgedHelperTools which has its Info.plist embedded inside of the __TEXT section of the binary using the linker flags
-sectcreate __TEXT __info_plist path/to/info.plist
Please note: I am currently not running this program, I just want to check if the currently installed helper tool is older than the one in my bundle and need to check if I have to update the helper tool (e.g. if its comming from a previous version of my program).
Just list all files inside the app dir. There are "version.plist" and "Info.plist" files that you can parse with simple script. If the app has another app inside then its structure is similar to parent.
Related
I am new to WebRTC stuff. I cloned the webrtc_ios main branch, and I built the framework as instructed here with the python script for arm64. When I add this to my Xcode project as a framework, everything is fine. Project builds, I can import files using <WebRTC/...> syntax.
However, I need to use RTCMTLRendeder.h file. Building a framework with python script leaves some of the header files out. (When I take a look at WebRTC.h inside the built framework, I can see that this file is missing) How can I include all header files that actually exist inside /webrtc_ios/src/sdk/objc/components folder while building the framework? I can see RTCMTLRenderer.h and .mm files are in that folder before using the build script. When turned into a framework those files don't exist inside the framework anymore. Why? And is there any other way to actually copy those files into the project as well?
Turns out you need to create your own, long renderer class which does not inherit from RTCMTLRenderer at all if you want to render on Metal view manually in a Swift/ObjC hybrid project (at least this is how I solved it). That class does whatever RTCMTLRenderer does, and grabs pixel buffers from RTCVideoTrack through an RTCVideoView.
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
In ruby on rails project.
I am using PDFKit gem for generating pdf reports
PDFKit uses wkhtmltopdf executable which is to be installed on the machine .
And next step to give the path of the executable .
I dont want to use the executable file .because if i use it how to deploy it on server .
the server will need to install it on its local and give the path.
Is it possible to use only library????
The executable is used to wrap the underlying Qt app, so it's technically possible to wrap the library in a gem (using ffi or some other similar lib) but I never heard anybody doing it.
I'm myself bundling the executable with my Rails app, to ship both at once when I deploy (even on Heroku).
To do the same, you can put the binary file in directory (you can call it bin), and configure PDFKit to get the executable where it's at using PDFKit.configure in an initializer for instance (you might wanna check the README).
I want to add a C++ Executable file to my App's MacOS Folder. The Executable file needs no plist or anything to run. It runs without any other files support. So i tried adding this file to my Xcode project , when i build my app, the binary resulted in Resources Folder.
The App is running fine, but i want the executable to be in Contents/MacOS folder. How to achieve this ..?
Create 'copy file' phase in your app's target.
I'm new with Cocoa / Objective-C development and I have a question.
Last week I had to create a SWF based Screensaver for Mac, and as I didn't find a free-compatible solution for Mac OS X Snow Leopard / Lion, I created a .saver bundle with Xcode 4. It creates inside a webview and loads inside the SWF file.
You must place the SWF file inside the Resources folder inside the bundle to make it work with different SWFs.
And now, I'm trying to code a Cocoa Application to do it automatically.
It has a simple user interface so as the user can select a SWF file. Then the code makes a copy of my previously build .saver file (I have the path hardcoded), places inside it a copy of the SWF file, and saves it where the user indicates in a save panel.
And here comes my question. Now I have the path of the .saver file hardcoded, but I need to have it as a Resource inside my app. Would it be possible? How could I use/access it?
Thanks for your help and time!
Your application already has at least one resource, assuming you didn't delete the MainMenu nib. Add your .saver bundle to that build phase. In the app's code, get the URL to the screen-saver bundle the usual way.