discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Opening bundles


From: Ivan Vučica
Subject: Re: Opening bundles
Date: Sun, 14 Aug 2011 15:08:03 +0200

make_services was already discussed on this mailing list (in fact, I remember participating in the discussion). I still believe that NSApplication/NSWorkspace should not only read the Info.plist, but also update the service cache at launch time.

Counting on make_service being regularly launched is not realistic in today's free desktop setups (since most are not based around GNUstep but around other libraries).

On Fri, Aug 12, 2011 at 23:44, Eric Wasylishen <address@hidden> wrote:
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 <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

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:

Direct link to info.plist:

--
Ivan Vučica - address@hidden


_______________________________________________
Discuss-gnustep mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnustep





--
Ivan Vučica - address@hidden



reply via email to

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