According to F J Franklin <[EMAIL PROTECTED]>: > But it ought to be easy to install plugins and dictionaries system-wide as > well, and having to install them inside bundles is awkward, especially > since (I'm guessing) to many Mac users an application is an application is > an application and what the hell is a bundle anyway? (Recently a friend > of mine, who has used Macs since I was in nappies, asked me WTF a bundle > bit was... like I would know.)
Sounds reasonnable. So AbiSuite should be i /Library BTW, a bundle bit is for MacOS < X where a bundle designate an association beetween an App (with its own creator code), document types and their icons. An application that has a the bundle bit set (this is a filesystem meta-data attribute) will make the Finder take care of checking its bundle upon copying it the disk. > Opera etc. are installed in /Applications as folders, so I don't think > it's anything too abnormal. It is abnormal. This is what raw carbon port (ie application built like a MacOS 9 Carbon app) does. These apps are usually dual forked executable (ie MacOS 9 style) rather that bundle executable (the NeXT style). AbiWord will be the later anyway. > Yes, bundle services is probably the way to go, though how the Finder > locale and AbiWord's locale methods can/will interact I have no idea. The problem is mapping UNIX locale name (ISO codes) with NeXT style locale names which are less versatile but more verbose.... > I'm a little stuck on NIB files. Are they static, or can they be altered > after loading - for example, could new entries be added to a list of > supported file types in the Open/Insert File/Image dialogues if plugins > are found? NIB file are just static interface description. You can modify the GUI at run time after having created it. For localization, 2 solution: 1/ runtime localization by modifying each control (what is done with the UNIX build for example) 2/ NIB localization which means duplication of NIB files. Here are my thought. But lets start on major issues first. Hub
