Sorry, it was my mistake, I forgot to run ./configure. I built it successfully and can reproduce the problem. It seems that NSWorkspace never actually reads the info.plist of the running application; only the cache generated by make_services (unless I'm missing something). This is also a problem because it means information on file types supported by the application won't be available if the application isn't installed.
--Eric On 2011-08-12, at 3:22 PM, Ivan Vučica wrote: > That is the same problem Gregory ran into yesterday, but the file was there, > and I have since applied a few fixes which made the program compile on my > machine. > > Are you absolutely sure you have today's latest commits? Did you ./configure > and make clean? If so, I am not sure what might be going wrong. > > XCPluginManager.h should be located in Plugins/ and should be referred to in > the GNUmakefile. > > Regards, > > Ivan Vučica > via phone > > On 12. kol. 2011., at 22:06, Eric Wasylishen <[email protected]> wrote: > >> Hey Ivan, >> >> I ran in to a similar problem once where Ink wouldn't open rtfd bundles; >> running the make_services tool fixed it. >> >> The open/save panel code calls -[NSWorkspace isFilePackageAtPath:] to decide >> whether a path is a bundle. From what I can see, the implementation of >> isFilePackageAtPath doesn't consult the application's info.plist but only >> looks at the cache generated by the make_services tool. This isn't very >> nice, since it seems we both ran in to problems because of it, so >> NSWorkspace should probably be modified to check the app's info.plist file >> in case the make_services cache is out of date. >> >> btw, I tried updating and building zcode but it looks like a file is missing: >> IDE/AppController.m:24:28: fatal error: XCPluginManager.h: No such file or >> directory >> >> Cheers, >> Eric >> >> On 2011-08-12, at 12:06 PM, Ivan Vučica wrote: >> >>> Hi there, >>> >>> a few months ago, I've updated GNUstep and compiled Zcode to discover I can >>> no longer open .xcodeproj bundles directly, despite associating Zcode with >>> them in the .plist. I've resolved this today by allowing users to open >>> .pbxproj files that are de-facto the only important pieces of .xcodeproj >>> bundles. >>> >>> However, this is suboptimal. >>> >>> Can someone verify that I'm not doing anything incorrect? >>> >>> Zcode available via Mercurial: >>> https://bitbucket.org/ivucica/zcode >>> >>> Direct link to info.plist: >>> https://bitbucket.org/ivucica/zcode/src/6948ef540274/Zcode-Info-gnustep.plist >>> >>> -- >>> Ivan Vučica - [email protected] >>> >>> >>> _______________________________________________ >>> Discuss-gnustep mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
