[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opening bundles

From: Eric Wasylishen
Subject: Re: Opening bundles
Date: Fri, 12 Aug 2011 15:44:17 -0600

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.


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. 


Ivan Vučica
via phone

On 12. kol. 2011., at 22:06, Eric Wasylishen <address@hidden> 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


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:

Direct link to info.plist:

Ivan Vučica - address@hidden

Discuss-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]