I want to retrieve the system language of a Macintosh in ISO-639-2 format (that is, in three character format).
Currently, I'm trying to use [NSUserdefault objectforkey:#"Applelanguages"]. This returns the Language code in 2 character format.
Whatever API I end up using, it should support MacOS X versions from 10.3.9 forward.
The relevant sections of the document are Internationalization Guide, another section of the same guide, and CFLocale reference. Unfortunately I don't think there's a standard API provided which convert 639-1 to 639-2. As explained there, OS X uses a mixture of both, and the canonical form used by the OS can be obtained by CFLocaleCreateCanonicalLanguageIdentifierFromString. But this is not what you want, unfortunately.
I would suggest you to process the table given here into an NSDictionary yourself.
For people needing this and don't want to process the table themselves, I created a category on NSLocale which should probably work on OS X also.
Related
I want to know if the C libraries system/string/data structure/data base etc are platform dependent.?
what are the things of these libraries that are dependent on a specific platform.?
like how a regular expression/string manipulation/sql connectivity etc libraries are dependent on a platform.?
can I use them on any platform for File I/O/Paths etc
just like we do things in python using the sys/os etc modules.?
I want to build a program which deals with strings,database(sqlite3,mysql,Oracle),data structures,File I/O and System paths. and can run on Windows,Linux and Mac when re compiled on that platform.
and I want it to be console based.
Please don't recommend me to do it in other programming languages, I want the C folks to answer please.
Thanks
Well, as long as you use the standard C library, all is well. The GNU C Library (glibc) is one implementation of the C standard, and for example Microsoft has their own implementation of it.
From a user's (your) perspective, the impelementation doesn't matter. If you for example
#include <stdio.h>
then you can, on any standards-compliant platform, call the fopen() and then use fread() for file i/o. Or any other standard C function.
Linux, Mac and Windows are all standards compliant (i.e. have implemented the ISO C) and thus the standard functions do the same thing on all platforms. The filepaths that you pass to fopen() are the same, too. The fact that Windows uses backslash ( \ ) in the filepath instead of the Unix way (forward slash, / ) doesn't matter: on Windows, in your C program, you use the Unix-style notation.
For C library functions, I suggest you ensure that you use functions within the POSIX standard. This will (at least in theory) guarantee compatibility with other POSIX platforms.
If you are programming on linux using glibc (i.e. the normal C library), the documentation thereof is reasonably good at pointing out what are GNU extensions, but the POSIX standard (referenced above) is the gold standard.
For other libraries, you'll have to look to the library in question.
Remember that if there are specific areas of incompatibility, you can use #ifdef's etc around those bits, and keep the machine specific elements in specific files.
To the specific points you mentioned:
* The POSIX regexp functions (regcomp, regexec, regerror, regfree) are part of the POSIX standard.
* Most of the string manipulation functions (e.g. strstr) are part of the POSIX standard. Some (e.g. asprintf) are GNU extensions.
* SQL connectivity is not provided by the C library. You will need a specific C library to deal with your SQL connection, or to use something like libdbi. You'll need to look at the specific library to see what support there is on other platforms.
In particular, be careful with path manipulation on windows (think about slashes vs backslashes, and drive letters), specifically dealing with how they are input by the user and what is passed to the function.
I need to rewrite a QuickTime reference movie, making it point to another set of files.
I'm working in Windows environment, so I don't have acces to the QuickTime API, and being the referenced files unaccesible, I can't also use the COM interface to load the movie because it can't resolve the referenced paths.
The documentation in the "QuickTime File Format Specification" says that the 'dref' atom can have a list of 'alis', 'url ' and 'rsrc' data references. In this case I need to parse the 'alis' elements. According to the reference, "Data reference is a Macintosh alias".
So long, I have not been able to see a declaration of the structure or any related information. Do you know the structure of an alias record? Where can I find detailed information about it's structure?
Thank you a lot for your help!
The format is very similar to the sort of alias that you could generate in the Finder by right-clicking an item, and creating an alias to it.
Aside: When the QuickTime format was originally specified, Apple intelligently chose to incorporate a number of other standards and paradigms that were extensively already being used elsewhere in the OS. This is one of the reasons why QT is (or was) able to do really clever things like reference movies. Unfortunately, there's also now a lot of cruft leftover from OS features that are no longer relevant (ie. AppleShare). Back in its heyday, QuickTime was slick, especially compared to its competitors; today, it's vastly underappreciated due to the buggy Windows port, and the relatively low processing power of the desktop systems of its time.
Back ontopic, unfortunately, the format for alias files is not an open/published standard, and there is precious little documentation on the topic on the 'net. There's one really old doc that deconstructs the alias format used in Mac OS Classic. Although the structure used in OS X is very similar, the alias files themselves tend to be much larger, as they contain numerous extra data strings at the end of the file that are not documented in the above-linked documentation.
Also, aliases created in the finder do look a bit different from the ones contained within the dref atom, although I've never run through them bit-by-bit to deduce the actual differences. If you want to take a peek at what those files, and have the OS X Developer Tools installed, you can run
setfile -a a [filename]
on a Finder-generated alias to strip the file of its alias-ness so that you can look at its contents in a hex editor (otherwise, the OS will just redirect you to the linked file - doh!). You can re-set the file's alias attribute, or arbitrarily designate any file as an alias by running
setfile -a A [filename]
Unfortunately, during my experiments, dumping the alis portion of a QT movie's dref atom has never seemed to generate an alias that Mac OS was able to interpret.
Fortunately (or not, as it was in my case), the functions that Mac OS allegedly uses to create/handle aliases are part of a public API called the Alias Manager, which is part of the very-low-level CoreServices framework. If you've got time to delve into this further, you can write some code to experiment with Mac OS's built-in alias-generating and interpreting capabilities.
Unfortunately, if you're dealing with an old/buggy file, you have no way of knowing if the file was actually generated by CoreServices' Alias Manager, or if that framework has changed/evolved/regressed since then. Because it's a closed format, 3rd-party developers who opt to not use the Alias Manager can only take guesses as to the format's "legal" structure.
You can use this Java program to see what is in the header, and extract data (it's a bit old, but may still work). What is more useful, though, is the thorough discussion by the author about the Quicktime header.
But I think you may just be looking for the Apple documentation, currently found here.
I'd like to store some additional information along with a document, but I can't use bundles or packages, and I cannot store it inside the document itself.
The application is a text editor, and I'd like it to store code folding and bookmark locations with the document, but obviously this cannot be embedded into the code directly, and I don't want to alter the code with ugly comments.
Can I use NSDocument to store information in the resource fork of a document? If so, how can I do this? Should I directly write to <filename>/..namedfork/rsrc or is there an API available?
First, don't use the resource fork. It's virtually deprecated. Instead, use extended attributes. They can be set programmatically at the BSD level via setxattr and getxattr. Extended attributes are used in many places... for example, in the latest OS X, the resource fork itself is implemented as a special type of extended attributes.
For example, the Cocoa text system automatically adds an extended attribute to a file to specify the encoding.
I thought NSFileManager and NSFileWrapper supported extended attributes since Snow Leopard, but I can't find any documentation :p You can always use the BSD level functions, though.
Does the state need to move with the file if it's copied to another computer? If not, you could do a lot worse than emulating the way Bare Bones handles document state with BBEdit. They store state for all documents in ~/Library/Preferences/com.barebones.bbedit.PreferenceData/Document State.plist.
The resource fork documentation is here. But it contains plenty of suggestions to not use the resource fork.
I have a class on my web site for reading and writing resource forks, which I have never got around to moving to my GitHub repository because, as Yuji points out, they are not really used any more.
I was going to say alias files and web Internet location file are the only places they are used, but I used and tested it on Mac OS X v10.7 (Lion), and they are not even used there any more; they may still be used for custom icons. I didn't test for that exclusively. I will have to see how that affect my NDAlias class on 10.7.
ndresourcefork
I'm writing a quick front end to display guitar tablature. The front end is in Flash but I want to store the tab in some human-readable format. Anyone know of something that already exists? Any suggestions on how to go about it? One idea I got from reading some stackoverflow posts was to use a strict ASCII tab format like so:
e||-1------3--------------0--|----2-------0---
B||--1-----3------------1----|----3-------0---
G||---2----0----------0------|----2-------1---
D||----3---0--------2--------|----0-------2---
A||----3---2------3----------|------------2---
E||----1---3----3------------|------------0---
It has advantages. I can gain a lot of info from the structure (how many strings, their tunings, the relative placement of notes) but it is a bit verbose. I'm guessing the '-'s will compress away pretty well when sent over the wire.
If anyone knows of an existing data-format for describing guitar tab I'll take a look as well.
edit:
I should note that this format is 90% for me and may not ever been seen by anyone other than myself. I want an easy way to write tab files that will be displayed eventually as graphics in a Flash front-end and I don't want to have to write an editor front end.
Check out the ASCII tab format. Also great description of the format is here:
http://www.howtoreadguitartabs.net/
ASCII export would be a great feature, but using ASCII as internal data format is not a good idea. For example, note durations would be extremely hard to express (hou would you store 32nds or even 16ths?, not to mention triplets...), so parsing those files would be extremely difficult. Moreover, users would be tempted to load ASCII files created outside your app, which will be likely to fail.
To sum up, i'd recommend to either try to reuse existing format or invent your own if that's not feasible. You may try to use XML for that.
EDIT: Beside DGuitar, i know of TuxGuitar and KGuitar, which support Guitar Pro files. You can look into their sources or ask their authors about file formats. I think there is also open source PowerTab-to-ASCII converter.
See Supported file formats in TuxGuitar.
TuxGuitar is open-source multiplatform software for reading, writing and playing the guitar tabs.
It supports the mentioned Guitar Pro and PowerTab format, and it also has its own TuxGuitar (.tg) format.
If you need the backend data structure to remain in human readable form I would probably stick it in a CDATA inside of XML. That could be inserted into a relational database with song/artist/title information and become searchable. Another option is to save it as zipped text files and insert links to those files in a database with the main artist info still searchable by sql.
These are not human readable:
Most common formats are Guitar Pro (proprietary) and PowerTab (freeware). DGuitar and TuxGuitar are open source viewers for Guitar Pro format. I'm sure that they have documentation for the format somewhere (at least in the code).
Advantage for using a common format would be the easiness of making tabs with those programs.
The Guitar Pro 4 format is described here http://dguitar.sourceforge.net/GP4format.html
I wrote a quick utility for displaying tab. For personal use. You can happily take the internal format I used.
I use a very simple string based format. There are three important structures.
Column, a vertical column in the output tab - all notes played simultaneously.
Bar, a collection of Columns
Motif, a collection of Bars
A Column looks like ':#|:#|*:#' where each * is a string number and each # is a fret number. If you are playing a chord you separate each string:fret with a '|'
A Bar looks like '[,,-,*]' where each * is a Column. A - indicates an empty column where no notes are played.
A Motif looks is just many Bars running back to back. For instance
"[1:5,-,3:7,-,3:5,-,3:7,-,-,3:5,3:7,-,1:8,-,1:5]"
e||---------------|---------------||
B||---------------|---------------||
G||---------------|---------------||
D||--7-5-7--57----|--7-5-7--57----||
A||---------------|---------------||
E||5-----------8-5|5-----------8-5||
"[-,-,1:3|2:2|3:0|4:0|5:3|6:3,-,-][-,-,3:0|4:2|5:3|6:2,-,-]"
e||--3--|--2--||
B||--3--|--3--||
G||--0--|--2--||
D||--0--|--0--||
A||--2--|-----||
E||--3--|-----||
Any help? Now can get NSSize, duration and its all.
You can do this almost entirely using Spotlight's metadata.
For example, I do the following in one of my apps
MDItemRef fileMetadata=MDItemCreate(NULL,(CFStringRef)eachPath);
NSDictionary *metadataDictionary = (NSDictionary*)MDItemCopyAttributes (fileMetadata,
(CFArrayRef)[NSArray arrayWithObjects:(id)kMDItemPixelHeight,(id)kMDItemPixelWidth,nil]);
This code essentially asks for the pixel width and height for a movie file (to determine if it's the dimension of an HD movie or not is the reason).
The Spotlight Metadata Attributes Reference lists all the available keys for various file types by category. You can probably get the required data this way without doing anything significant, provided that the media type you're examining has a Spotlight plug-in.
This functionality may not be built in (I'm honestly not sure), but I do know of two third-party libraries which can tell you the information you need.
VLCKit, the framework being used by the newest beta versions of VLC for Mac.
libmediainfo, a multi-purpose library that can read practically any bit of information you need out of practically any media file.
I can go into more depth with how to use either of these, but I'd rather only do so if you end up needing me to. Let me know!