There are 2 processes. One is a GUI process that is located in MacOS folder under the Mac bundle, while the other one is a tray process that is located in Resources folder under the bundle. The tray process doesn't seem to be able to find the cocoa plugin/library. Because when I manually run it, there is an error as below
This application failed to start because it could not find or load the
Qt platform plugin "cocoa" in "".
The bundle structure looks like this
-Contents
|_MacOS
| |_gui
|
|_Resources
| |_tray
| |_qt.conf
|
|_Plugins
|_platforms
|_libqcocoa.dylib
qt.conf contains
[Paths]
Plugins = PlugIns
Imports = Resources/qml
Qml2Imports = Resources/qml
Is the right thing to do that putting tray process into resources folder within a Mac bundle?
According the Bundle Programming Guide the Resources folder is intended for resources like images, sounds, etc (see Table 2-5):
Contains all of the application’s resource files. This contents of this directory are further organized to distinguish between localized and nonlocalized resources. For more information about the structure of this directory, see The Resources Directory.
and:
The Resources directory is where you put all of your images, sounds, nib files, string resources, icon files, data files, and configuration files among others
The MacOS folder however may also contain helper executables:
Contains the application’s standalone executable code. Typically, this directory contains only one binary file with your application’s main entry point and statically linked code. However, you may put other standalone executables (such as command-line tools) in this directory as well.
Therefore, I think the MacOS folder is the best location for your tray binary. I don't know whether that solves the problem of the missing platform plugin.
Related
I'm running into an issue where after building an application with Powerbuilder, some users have no issue with viewing icons within the application while others can't see the icons. Also, the main icon for the application doesn't display on the Windows Task bar. I'm going to play with the icon size but if anyone else has any recommendations, that would be great!
I don't like to re-compile the executable every time there's a small graphic change or a customization that applies to only one library, and I don't like to compile graphics into the executable... it makes the exe file very large. No reason to rebuild the exe unless the library list changes. So I use .pbr files, and just rebuild the pbl with a pbr file.
My graphics.pbr file resides in the same directory as my graphics so I don't have to mess with environment variables or worry about file paths. I created an empty graphics.pbl in the AppCore directory, and a graphics.pbr in the graphics directory. The graphics.pbl is in the application's library list. When I have to add or edit graphics, I simply rebuild the graphics.pbl with the graphics.pbr.
I have multiple customers using the same application, with their own graphics (logos) so I do the same thing there. Here's what my directory structure looks like:
MyApp
MyApp.pbw
AppCore
graphics.pbl
bunch more libraries
AppGraphics
single resource file, graphics.pbr
bunch of icons and graphics
Customer1
Customer1.pbl
Customer1.pbr
a few libraries for customization and container for application object
a few custom graphics
Customer2
etc.
The key is to make sure when you add graphics or images to your application from the AppGraphics directory (or the customer directory), make sure there is no directory path.
This solution has made it easier for me to continue developing the next upgrades and versions by moving the code and renaming some directories without having to edit my code because my directory path has changed.
This is lengthy, but I hope it helps!
~~~Tracy
Within the IDE where you insert the icon file name, make sure you don't have a path (like "C:\graphics\myicon.ico") - only the name of the icon file. Then make sure the icon files are somewhere in a folder within the PATH variable on your system. When you build your application you can use a PBR file (a resource file) in the project for the application. If you list all the graphic files used in the application in this resource file they will be included in the exe (and you won't have to distribute them separately).
Matt is right on point with not using path names in your image references in the app. Also correct that it is best to compile them into the app.
However, during development I like to separate my resources and DLLs into separate directories. To do this without changing global env variables, you can include your directories in the PB "App Paths" registry section.
Depending on your PB Version...
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pb125.exe"
There you will find a "PATH" value. Just append your dev, resource, dll, directories to that path separated by ";" and PB will find them (requires restart).
I actually create reg files in the root of each app I'm working on to quickly register my paths.
NOTE: The same thing works with your final compiled application; but instead of using the PB section, there will be section created with the name of your executable. Just do the same thing there - add paths where resources are separated from the EXE directory.
This may sound like I'm just looking for a .exe file, but I'm not all that familiar with windows. I have been using pyinstaller to turn my apps into binaries. My app relies on a lot data directories and third party binaries that I package within the same directory as the executable binary. For Mac, this makes things easy because the user only has to click on MyApp.app inside the applications directory which is like a link to MyApp.app/Contents/MacOs/MyApp. This way MyApp never has to be touched and is all bundled together with the data directories (also loaded inside of MyApp.app/Contents/MacOs/).
However, I can't really find a windows equivalent. While Pyinstaller can create a directory with my data directories and executable inside of it, if the user ever moves the .exe file inside the directory, the app will never work (because it loses its relative location to the data directories). Is there such a thing that can package this directory like on MacOS so the user just has to click on a single .exe file that links to the .exe inside the directory packaged within it? That way we can just pass around one directory. Like a Mac.app?
Win32 apps store data within the executable file as resources, which allows the single file solution, but they can't be accessed using normal file APIs, there are a separate set of functions for resource handling. (This implies that resources aren't so useful for things that absolutely have to be files, like images of helper executables.)
Win32 also has alternate data streams, which are more similar to what you're used to with .app packages, separating a local identifier from the actual filename by $DATA:. But those only work on NTFS, get lost by many file management applications, never have been very popular, and are now effectively deprecated by Microsoft (by preventing access from Windows Store apps).
I have a set of applications that work together. It should be possible to start each of these applications individually by the user (i.e. one application provides a monitoring feature, another a configuration feature etc), therefore I would like them to show up in the Applications folder as different applications (possibly within a directory).
The applications are based on Qt5, so I would like to package Qt along with the applications privately to ensure that Qt is present and available. On the other hand I would like to make sure that I only include a single copy of Qt to avoid bloating the system.
I am using a package installer, due to the inclusion of a LaunchDaemon as well.
How do I place the Qt frameworks needed in order to avoid having multiple copies?
Here's the naive way:
/Applications/
MyCompany/
Foo.app/
Contents/
Info.plist (must use its own plist to specify some properties)
MacOS/
foo
Frameworks/
Qt-Goes-Here??
Bar.app/
Contents/
Info.plist
MacOS/
bar
Frameworks/
Qt-Goes-Here?? - Or can this be a link to the other location?
Since I am not a Mac-guru, any input (including informing me that I am trying something stupid) is very welcome!
There are two possibilities here, the first is
/Library
and the second
/Library/Application Support
If you look there, you'll find folders with contents for various applications. You should be able to create a folder there and add the Qt Framework, then update your applications to point to that using install_name_tool
The docs state the following for /Library: -
The Library directory is the top-level directory for storing private
app-related data and preferences. There are several Library
directories scattered throughout the system but you should always use
the one located inside the current home directory. Do not store files
directly at the top-level of the Library directory. Instead, store
them in one of the specific subdirectories described in this table. In
OS X v10.7 and later, the Finder hides the Library directory in the
user’s home folder by default. Therefore, you should never store files
in this directory that you want the user to access. To get the path to
this directory use the NSLibraryDirectory search path key with the
NSUserDomainMask domain.
For /Library/Application Support: -
The Application Support directory is where your app stores any type of
file that supports the app but is not required for the app to run,
such as document templates or configuration files. The files should be
app-specific but should never store user data. This directory is
located inside the Library directory. Never store files at the top
level of this directory: Always put them in a subdirectory named for
your app or company. If the resources apply to all users on the
system, such as document templates, place them in /Library/Application
Support. To get the path to this directory use the
NSApplicationSupportDirectory search path key with the
NSLocalDomainMask domain. If the resources are user-specific, such as
workspace configuration files, place them in the current user’s
~/Library/Application Support directory. To get the path to this
directory use the NSApplicationSupportDirectory search path key with
the NSUserDomainMask domain.
The full documentation can be found here.
I involved with the development of an application that is intended to deploy on multiple desktop system including the Macintosh.
Our team decided we would like to a drag and drop installation for the Macintosh. However, the application is intended to ship with other content besides the application itself such as example files.
Originally these files were placed in the application bundle, however this was discovered to be problematic as the cross platform libraries used for the user interface will not allow someone to access the contents in the bundle. Also force users to have to dive into a bundle to find content does not offer a great user experience.
To that end, we decided to pull these examples file and what not out of the bundle and place them in a separated folder that lived along side the application bundle. To make sure everything including the examples and the application were copied together during the drag and drop installation, a new top level folder was created that contained everything to be copied.
The problem that now exists is that whereby when originally just the application bundle was copied over to the system, the copying of this top level folder does not cause file associations for the application to occur automatically.
What can be done to associate an application with certain files when someone installs by dragging a folder contain the application bundle?
I suggest you to deliver it separately in one dmg. So your dmg structure will look like next:
MyApp -> Applications
MyApp Examples -> Application Support
Simple, user-friendly, no problems with association.
Actually it looks like the file association is working after all. Someone reported a defect against the installation not making the associations. However, I just tested the installation on a clean system and copying over the folder does seem to make the associations.
im a bit confused about the most proper way to manage resources (files and folders) needed by the application.
I make it clear:
I have an executable ( developing on mac osx with qt ), and a i have a fixed folder hierarchy, where a bunch of configuration files are kept. Those files might be manually edited, added or delete.
Now on windows or linux, i would just easily get those files by simply accessing parent folders, and those folders are freely accessible by any OS file manager.
But in OSX my executable is inside the .APP bundle.
Then i should be able to retrieve resources from within the bundle ( even if resources management in qt creator sucks ), but the user should also be able to open and edit the app bundle, which is not feasibl at all... and i neather want to deploy any resource manager nor put the configs in (eg.)home subfolder ( i want to keep everything together ).
Is there any solution?
Thanks!
In OS X terms your config files should really be in Application Support, the user can access them there. However they can also access them from the app bundle if you put them in there by right clicking and selecting View Package Contents, you can then change the files and save them.