I have a QT application and right know I need to change the app name to something like "A&B".
I have tried to change the TARGET in my .pro file, but I am having problems with the "&" character in macOS.
I have also tried to use qmake functions like val_escape, system_quote, shell_quote but nothing worked for me.
As a last resource, I have tried to change the CFBundleName in my .plist file, which worked for app menus and etc, but not for the app name (still having problems with &, as make is considering the app to be called B.app instead of A&B.app
Do you know any other way to get this problem fixed? Is there even a way to have a macOS application with a name like A&B.app?
Thanks in advance
I dont think you are following the right approach. What the client want is perhaps change the "user visible" strings for the application name to "A&B" - for that you need to check out the following functions in QCoreApplication:
applicationName : QString
applicationVersion : QString
organizationDomain : QString
I fixed this by adding a DisplayName to my configuration and changing the applicationDisplayName in the Info.plist.
Thanks anyway.
Related
I need fileDialog to work properly with tags. On OSX, when I try to click on tag - this code removes all files from file dialog, so I can't pick them.
Looks like I found solution Option::DontResolveSymlinks but it doesn't work either.
Update: if filter is "Any (\*.\*)" it shows folders, in other cases it doesn't. Like it disables files to be chosen - I already came up with workaround, but hope there is a solution.
QStringList filenames = QFileDialog::getOpenFileNames(nullptr,
caption,
lastDirPath,
filter,
nullptr,
QFileDialog::Option::DontResolveSymlinks);
Update: added screen to describe what "tag" is
I have found a resolve for the mac file open hang, based on the previous answer.
QStringList filenames = QFileDialog::getOpenFileNames(nullptr,
caption,
lastDirPath,
filter,
nullptr,
QFileDialog::Option::DontUseNativeDialog)
The mac file dialog is not used, it looks more UNIX like, but it now works.
Users of my application keep running into issues related to other applications declaring a different UTI for the same file extension as my application. I think I can best describe this with an example:
My application supports importing and exporting OPML files. For this to work I import the org.opm.opml UTI in my info.plist. This mostly works fine, but fails if an other application declares a different UTI for the opml file extension. For example com.redlex.opml or com.xwavesoft.cloudoutliner.opml.
Is there something I can do to work around this problem? Can I somehow tell launch services that my application accepts all files with an .opml extension?
I solved this issue with the following work around:
I removed the entire LSItemContentTypes entry from the list of CFBundleDocumentTypes
In my NSDocument subclass I use NSString's rangeOfString:: method to look for the #"opml" keyword in the typeName parameter.
This work around was confirmed by a user.
Cloud Outliner updated on the MAS today, and looking at the UTI for .opml files now, the com.xwavesoft.cloudoutliner.opml is now gone and com.redlex.opml is now in its place. Which would be uninteresting, except for the fact that OPML files now open in MindNode without a problem.
I can't find any release notes for Cloud Outliner other than "various fixes and improvements." but it would seem that something changed for the better. So: in my case - the simple answer was "update Cloud Outliner" but I'm not sure this solves the larger problem. I also have Mellel on my system (obviously, right?!) but this doesn't seem to be causing the same issue.
For those watching this thread - the issue presented as MindNode showing greyed-out icons for OPML files in its open dialog. Dragging OPML to the MindNode icon in the dock also produced no results.
Rob
I've read all the tickets about this issue, but I still don't get it right. I have a non-document OSX app (for OSX Lion and MountainLion). I want this app to export and import custom data, associated with a custom file extension ".iobs". Internally, these files are just data archived with [NSKeyedArchiver archivedDataWithRootObject:], and saved onto the disk with the "iobs" extension.
So, my check list is this:
1) Export mechanism: checked. My app create correctly .iobs files. If I run "file <filename.iobs>" in the Terminal, I get "iObserve_exportedItems.iobs: Apple binary property list"
2) Declaration of an exported UTI, checked. As shown in the image below. I did NOT declared a custom Document type, since it I never use NSDocument inside my app, and there is no point. Anyway, I already tried and failed. I've tried also different combinations of "Conforms To" entries, but with no success.
3) Is there any 3rd point??? Do I need to start my app once to let the system know? I just ran it in Debug from Xcode so far, and this has no effect. So I guess my Info.plist is wrong, but I filled it from within Xcode4 interface, so???
Thanks for any help, hint, question, suggestion.
Ok, so apparently, I do have to declare a document type even if I don't specify a document class. See the attached screenshot. Note that leaving only the Document UTI doesn't work. I do need the two (exported UTI and document type). Note also that if I say it conforms to com.apple.binary-property-list, I don't have the right icon.
And for those who wonder, there is nothing to do to "register" a type (and its subsequent changes) apart from launching the app once.
I am new to Mac development and are trying to understand the location that XE2 firemonkey apps are deployed. I understand that the application is deployed into a "package" however I am not sure how this work when getting path information from within my app.
My application loads a dylib that I moved over from Visual Studio to XCode and initializes it by passing in a driver path (intended to be off the application path). i.e.
UDMXLibInit(PAnsiChar(AnsiString(driver_path))
If I put a breakpoint on this line in Delphi I find that driver_path is:
.../PAServer/scratch-dir/MacMini/LightFactory3.app/Content/MacOS/drivers
In my dylib I put a breakpoint in XCode on the "Init" function I find that the path is now:
.../PAServer/scratch-dir/MacMini/LightFactory3.app/Content
There appears to be some vodo that is truncating the path. Is this because "LightFactory3.app" is a package and there is something I dont understand or is there something else I am missing about passing this string between app and library under OSX?
Thanks in advance.
This appears to be a bug in the Expressions view for XCode 3.2. For some reason it truncates strings.
The actual string was correct - figure this out by passing it back to to my app.
I have met a strange problem with the localized strings. I have only a 'Localizable.strings' in my 'en.lproj' folder and it works fine. all the strings are shown on device. but the next time i compile it and run, it shows only the ID of the strings. even if i change nothing and only click on build&debug. and the next time it works fine again and next time again shown with IDs.
so does anyone knows why this is happening? it's kind of annoying that i always need to build twice.
My SOLUTION is at bottom:
I've been running into the same problem: Alternating runs yield correct, then incorrect translations (only for English though).
Adding "-NSShowNonLocalizedStrings YES" as an argument to the app yielded:
Localizable string "MyKey" not found in strings table "Localizable" of bundle CFBundle
So, I tried loading the key file directly from the bundle as a string and dumping it. Well, the times it did NOT work correctly, it was displaying a bunch of built-in iOS messages. So, I went to the APP file that was built, opened the package contents, and viewed the en.lproj/Localizable.strings file...and voila!!! The file had been filled with Apple iOS key/value pairs. On the next build, it was filled as expected.
Of course, this has nothing to do with the encoding of the files (which should be UTF-16). I have not been able to locate anything with mention of this specific problem.
MY SOLUTION:
I copied the contents of the legitimate english Localizable.strings file FROM THE APP PACKAGE (not from my source) into an XML file (when compiled, the .strings file are converted into XML) and added to my project. I then loaded this file into a dictionary at startup, and if the call to NSLocalizedString returned the key instead of the value, I did a lookup on the dictionary I loaded. In theory, you could do this for all languages, but I was only having the problem with english.
Yes, it's not the answer to the problem, but it's a workaround.
Check if you have more than one Localizable.strings in your project. Merging them into one solved it for me. (Check any external code you use e.g. ShareKit)