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.
Related
We market an application that runs on multiple platforms, including Macintosh. On the Macintosh the software gets packaged into a .dmg file, and when installed everything goes into the /Applications hierarchy.
Some of the files in our application's hierarchy are samples that users are supposed to be able to modify in place or copy to different files in the same directory. The problem is the permissions that seem to get applied within the /Applications hierarchy prevent our application from doing such operations.
So I either need to change the install so the directories and files in question within /Applications allow modification, or I need to segregate the sample files to a different location on the disk where they can be modified.
I've tried making sure the permissions on the files allow writing at the time the .dmg file is pulled together, but then when the product is installed the permissions get changed to more restrictive ones that don't allow file modification or copying.
I've been able to modify the packaging so the sample files get installed to a different location, but so far I haven't been able to find a suitable area on the Macintosh disk to put them so modification is allowed. I haven't been able to figure out how to tell the packaging that these sample files should be installed into the installer's home directory.
Anyone have any suggestions? I'm afraid I'm a bit of an Apple novice. The procedure to build the .dmg file employs a Makefile that invokes commands like pkgbuild and productbuild. The productbuild command uses a --distribution qualifier that references a .xml file. There don't seem to be any scripts invoked.
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.
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.
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.
I'm building an application where I want to provide the user with a few dozen templates that will internally take the form of property lists. I would also want to group them in categories, which would conveniently be achieved using folders.
While I have contemplated shipping these files as simple resources in my application, I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
I can see that many applications have installed such resources in their application support directory (~/Library/Application Support//...), but I can't seem to find any documentation resource on how to achieve this.
I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
It is. Put them in folders in your project directory, then add the top-level folder(s) to your project. Make sure you add it/them as folder reference(s) and not group(s) (see? that sheet does have a purpose!).
Then, add the folder reference(s) to your Copy Bundle Resources or Copy Files phase.
One word of warning: When you change one of the files in the folder, you may need to “touch” the folder to get Xcode to re-copy it. You can do this in Xcode or from the terminal.
You can group items in sub-folders of your app bundle's Resources directory. Unless you want users to edit these plists, keeping them in your app bundle allows users to drag-n-drop install your app, rather than having to use an installer package (a big win).
You can group them into folders in your application bundle by adding a "New Copy Files Build Phase" to your project as described in this forum post:
http://forums.macrumors.com/showthread.php?t=458594