Associating bundle directories with app
Ivan Vučica
Riccardo Mottola
your friend is make_services. Once your application is installed, run
it. (OS-X just runs make-services periodically).
You can also check with GWorkspace that the inspector "Tools" shows with
what to open. Several applications can be listed with one default.
Furthermore I may add that ProjectCenter's 0.6.0 file format is a
Bundle, organized similarly to Xcode: a project specific file inside and
a user-specific plist.
Riccardo
Ivan Vučica
Hi,
your friend is make_services. Once your application is installed, run it. (OS-X just runs make-services periodically).
You can also check with GWorkspace that the inspector "Tools" shows with what to open. Several applications can be listed with one default.
Furthermore I may add that ProjectCenter's 0.6.0 file format is a Bundle, organized similarly to Xcode: a project specific file inside and a user-specific plist.
Riccardo
Ivan Vučica wrote:
Hi,
Since Zcode is trying to be compatible with Xcode, I'd like to make it the associated app for opening .xcodeproj bundles. Project Center does not seem to support specifying that a document type is a bundle, and by reading PC's Info-gnustep.plist, it doesn't seem to require it either.
I've specified the document type in .plist, and I've launched the .app at least once. On OS X, that would be sufficient to associate the filetype with the app. However, GWorkspace does not seem to open the .xcodeproj files with Zcode, nor does the file open dialog represent the .xcodeproj bundles as "files" instead of directories.
What did I do wrong with the plist? What else do I have to do to make the GNUstep workspace associate .xcodeproj with Zcode?
See the plist here:
https://bitbucket.org/ivucica/zcode/src/9d1d0e6cebe1/ZcodeInfo.plist
--
Regards,
Ivan Vučica
Gregory Casamento
Sent from my iPhone
_______________________________________________
Discuss-gnustep mailing list
Discuss...@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Richard Frith-Macdonald
On 20 Jan 2011, at 00:45, Gregory Casamento wrote:
> You're correct, it's not done like that today.
>
> On NEXTSTEP and OPENSTEP systems there was a process called make_services... This is why GNUstep has this executable.
Yes ... run when you log in, so any updates are done automatically when you log in.
The NSWorkspace class also runs make_services the first time it is used ... but an app which doesn't use it won't automatically update things.
> Your suggestion, though, make sense. The make_services program should be run periodically so that registration of application associations is automatic.
I would think it's highly likely that Apple, when they added support for monitoring the filesystem on their OS (ie for the OS to notify applications which have registered an interest in filesystem updates), modified the workspace application to update associations at the point when an application is added to, or modified in, any of the standard directories.
This would be the ideal way to do things (much, much more efficient than scanning all the directories periodically), but we don't have any way to do that yet as we don't have a cross-platform api for gettting filesystem update notifications :-(
Perhaps someone could write something to use inotify (linux), kqueue (bsd), change notifications (windows NTFS) to perform real-time updates, and run make_services occasionally to catch cases that the filesystem notifications miss?
Sebastian Reitenbach
since the cache used is stored in the users GNUstep directory in the
.GNUstepServices file.
Maybe it would make sense to have a global services cache, in some shared
accessible directory. So for me as a packager, I could run make_services as a
post (un)install script, when installing a package. So it would update the
services database everytime a gnustep application is (un)installed.
Since make_services always accounts all available applications, for me it
would make sense to remove the burden to remember to run make_services, from
each user of the system, but move it to the admin/packager...
But maybe I miss sth. here...?
Well, people installing from source, would then still need to run
make_services, but since they are able to install from source, I don't think
that this would be a great hurdle.
cheers,
Sebastian
Ivan Vučica
file when the app is opened (or its plist read by openapp/workspace).
No need to update every app's registered types every time. Also, when
an app is deleted, just remove it from cache.
If I remember correctly, OSX doesn't detect association:
A) until app is opened from finder (maybe copied!)
B) unless app is removed from finder
I would have to play when I get back to OS X, but either way, I don't
see a reason why it couldn't work that way.
Regards,
Ivan Vučica
via phone
On 20. sij. 2011., at 10:10, Sebastian Reitenbach
<seba...@l00-bugdead-prods.de
Richard Frith-Macdonald
Yes. It has to be done on a per-user basis, since the locations that applications/services live in vary from user to user.
> Maybe it would make sense to have a global services cache, in some shared
> accessible directory. So for me as a packager, I could run make_services as a
> post (un)install script, when installing a package. So it would update the
> services database everytime a gnustep application is (un)installed.
If (and only if) you control the system and no users are going to have private installations of GNUstep, it would make sense to have a common shared database.
> Since make_services always accounts all available applications, for me it
> would make sense to remove the burden to remember to run make_services, from
> each user of the system, but move it to the admin/packager...
Well, make_services is supposed to be run by the user's login script (ie the installation HOWTO documentation, last time I looked, said that you should do that) ... but if you are making a system-wide package you could run it in /etc/profile or equivalent. However, it's really not the case that the user has any 'burden' to do it ... applications run it automatically (as soon as the NSWorkspace class is instantiated in the app).
However, I think it would be good if gnustep-make also ran it automatically when doing a make-install (perhaps it already does ... I haven't checked).
> But maybe I miss sth. here...?
I think the issue is that, if you copy an app into your Apps folder, the information about that app doesn't become available immediately ... it has to wait for some app to start up and (automatically) run make_services.
Ivan Vučica
However, I think it would be good if gnustep-make also ran it automatically when doing a make-install (perhaps it already does ... I haven't checked).However, it's really not the case that the user has any 'burden' to do it ... applications run it automatically (as soon as the NSWorkspace class is instantiated in the app).
Regards,
Ivan Vučica
Sebastian Reitenbach
place, and actually don't want your users to install software on their
own, however you try to prevent this. Therefore kind of central location
for the cache would not be too bad. Other packages on OpenBSD do the
same, i.e. updating the mime database, or run gtk-update-icon-cache, or
run update-desktop-database.
>
>
>> Since make_services always accounts all available applications, for me it
>> would make sense to remove the burden to remember to run make_services, from
>> each user of the system, but move it to the admin/packager...
>>
>
> Well, make_services is supposed to be run by the user's login script (ie the installation HOWTO documentation, last time I looked, said that you should do that) ... but if you are making a system-wide package you could run it in /etc/profile or equivalent. However, it's really not the case that the user has any 'burden' to do it ... applications run it automatically (as soon as the NSWorkspace class is instantiated in the app).
>
Yes, for now, its recommended in the README that gets installed with
GNUstep on OpenBSD that make_services should be added to a kind of login
script. And its not really a "burden", but users tend to not read
documentation, and start complaining ;)
I wasn't aware that the NSWorkspace class instantiation does this
automatically at some point in time for me.
> However, I think it would be good if gnustep-make also ran it automatically when doing a make-install (perhaps it already does ... I haven't checked).
>
>> But maybe I miss sth. here...?
>>
>
> I think the issue is that, if you copy an app into your Apps folder, the information about that app doesn't become available immediately ... it has to wait for some app to start up and (automatically) run make_services.
>
>
Don't know whether it would make sense to add a parameter to
make_services, to run in a given domain, i.e. USER, LOCAL, SYSTEM, and
then having for each domain a cache. When NSWorkspace initializes
itself, it looks up the information in each domain, and merges them
together. But maybe its too much hassle for this little problem.
cheers,
Sebastian
David Chisnall
On 20 Jan 2011, at 15:02, Richard Frith-Macdonald wrote:
> Yes. It has to be done on a per-user basis, since the locations that applications/services live in vary from user to user.
I'm not sure I understand this argument. Isn't this the same as allowing defaults to be set in GNUstep.conf (e.g. so the administrator can set the default theme for all users)? Per-user defaults override systemwide defaults in both cases. If an application is installed by the system administrator, then I would expect it to be the default application for all users, unless they have explicitly provided an alternative setting.
The reason for not automatically generating these settings on OS X[1] is security - you don't want a user clicking on some link, getting a .app bundle, and finding that it's a trojan that installs itself as a the default file handler for all of your file types. If the system administrator is performing the installation, then this does not apply; if root is installing trojans then you have bigger problems than GNUstep's file associations.
One of the issues that is always raised with regard to GNUstep adoption is the quality of GNUstep packagers, and if we can make life easier for packagers then this seems like a good thing to do...
David
[1] OS X does generate them automatically now, but it prompts you the first time the app is run.
-- Sent from my PDP-11
Richard Frith-Macdonald
On 20 Jan 2011, at 18:15, Sebastian Reitenbach wrote:
>> Well, make_services is supposed to be run by the user's login script (ie the installation HOWTO documentation, last time I looked, said that you should do that) ... but if you are making a system-wide package you could run it in /etc/profile or equivalent. However, it's really not the case that the user has any 'burden' to do it ... applications run it automatically (as soon as the NSWorkspace class is instantiated in the app).
>>
> Yes, for now, its recommended in the README that gets installed with
> GNUstep on OpenBSD that make_services should be added to a kind of login
> script. And its not really a "burden", but users tend to not read
> documentation, and start complaining ;)
>
> I wasn't aware that the NSWorkspace class instantiation does this
> automatically at some point in time for me.
Yes ... in practice that's basically whenever a gui app starts up ... and since these associations are practically only ever used by gui apps (and in particular extension:app associations are usually only by the workspace app), that means that make_services is run automatically before any app needs the info.
>> However, I think it would be good if gnustep-make also ran it automatically when doing a make-install (perhaps it already does ... I haven't checked).
>>
>>> But maybe I miss sth. here...?
>>>
>>
>> I think the issue is that, if you copy an app into your Apps folder, the information about that app doesn't become available immediately ... it has to wait for some app to start up and (automatically) run make_services.
>>
>>
> Don't know whether it would make sense to add a parameter to
> make_services, to run in a given domain, i.e. USER, LOCAL, SYSTEM, and
> then having for each domain a cache. When NSWorkspace initializes
> itself, it looks up the information in each domain, and merges them
> together. But maybe its too much hassle for this little problem.
Sure, that could be good in principle, but I can't see much benefit in practice for now since we have to generate the user domain info and merge in the local/system domain info anyway.
If we had a *lot* of apps in the local/system domains then caching information about them separately and merging it with the user domain stuff would improve performance, but for now I can't see the additional coding being worth the effort.
Richard Frith-Macdonald
On 20 Jan 2011, at 18:25, David Chisnall wrote:
> Hi Richard,
>
> On 20 Jan 2011, at 15:02, Richard Frith-Macdonald wrote:
>
>> Yes. It has to be done on a per-user basis, since the locations that applications/services live in vary from user to user.
>
>
> I'm not sure I understand this argument. Isn't this the same as allowing defaults to be set in GNUstep.conf (e.g. so the administrator can set the default theme for all users)? Per-user defaults override systemwide defaults in both cases. If an application is installed by the system administrator, then I would expect it to be the default application for all users, unless they have explicitly provided an alternative setting.
Yes, if you like, placing an app in the system domain is equivalent to setting a default in GNUstep.conf
And yes, the user domain apps override/replace the system domain ones ...
so to find the app a user should use, we *must* look in the user domain (because anything found there will override the system domain apps) and cached information has to be stored on a per-user basis (because the cached information may contain information about apps in the user domain).
> The reason for not automatically generating these settings on OS X[1] is security - you don't want a user clicking on some link, getting a .app bundle, and finding that it's a trojan that installs itself as a the default file handler for all of your file types. If the system administrator is performing the installation, then this does not apply; if root is installing trojans then you have bigger problems than GNUstep's file associations.
>
> One of the issues that is always raised with regard to GNUstep adoption is the quality of GNUstep packagers, and if we can make life easier for packagers then this seems like a good thing to do...
I'd say the current situation is easy for packagers ... in order for the filetype associations to work the packager has to do ... nothing whatsoever (apart from putting the apps in the normal locations of course).
SPUeNTRUP - Kai Henningsen
Am Thu, 20 Jan 2011 08:27:34 +0000
schrieb Richard Frith-Macdonald <ric...@tiptree.demon.co.uk>:
> Perhaps someone could write something to use inotify (linux), kqueue (bsd), change notifications (windows NTFS) to perform real-time updates, and run make_services occasionally to catch cases that the filesystem notifications miss?
You might want to look at this partial solution:
http://mark.heily.com/pnotify/
Mit freundlichen Grüßen aus Münster /
with kind regards - Kai Henningsen
--
SPUeNTRUP Software
An der Kleimannbrücke 52
D-48157 Münster, Germany
Reg: Münster Nr.29047
Fon: +49 700 CALL CATS (=22552287)
Fon: +49 251 322 311 0
Fax: +49 251 322 311 99
Web: http://www.cats.ms
Mail: suppor...@cats.ms
Niels Grewe
On Thu, Jan 20, 2011 at 10:08:55AM +0100, Sebastian Reitenbach wrote:
> With the make_services available right_now, it has to be run as the user,
> since the cache used is stored in the users GNUstep directory in the
> .GNUstepServices file.
>
> Maybe it would make sense to have a global services cache, in some shared
> accessible directory. So for me as a packager, I could run make_services as a
> post (un)install script, when installing a package. So it would update the
> services database everytime a gnustep application is (un)installed.
I think it would be a good idea to have a kind of system wide (or per
installation domain?) mechanism for storing settings. This probably
should not only include the .GNUstepServices and .GNUStepAppList files
but also the user-defaults database. If I'm not mistaken, people are
routinely having trouble to set the right NSFont for their backend
because the packager cannot do it for them.
Also, it is worth noting that there is a freedesktop.org spec
[0] for associating mime-types with applications. Maybe we should
consider supporting that as well [1] for people who occasionally use GNUstep
applications on their whatever-is-considered-fancy-this-week desktop.
> Since make_services always accounts all available applications, for me it
> would make sense to remove the burden to remember to run make_services, from
> each user of the system, but move it to the admin/packager...
>
> But maybe I miss sth. here...?
Well, people might want to install applications and services in their
user domain so it kinda makes sense to run it automagically for the
user.
Cheers,
Niels
[0] http://standards.freedesktop.org/shared-mime-info-spec/latest/
[1] I'd be willing to look into that if there is sufficient interest.
David Chisnall
> Also, it is worth noting that there is a freedesktop.org spec
> [0] for associating mime-types with applications. Maybe we should
> consider supporting that as well [1] for people who occasionally use GNUstep
> applications on their whatever-is-considered-fancy-this-week desktop.
I think this would be a nice thing to support, but it's not clear to me from scanning the spec that it's possible to correctly handle bundles. It looks like you can define things for directories, or you can define things for files with a specific extension, but not for directories with a specific extension (although, like most fd.o 'standards' it's missing most of the explanation of how it works.
I'm also not really sure how it will interoperate with UTIs. Maybe someone should poke fd.o to adopt UTIs, rather than MIME types, as the core representation, since they're more expressive...
David
-- Sent from my IBM 1620
Richard Frith-Macdonald
On 20 Jan 2011, at 13:42, Niels Grewe wrote:
> Hi,
>
> On Thu, Jan 20, 2011 at 10:08:55AM +0100, Sebastian Reitenbach wrote:
>> With the make_services available right_now, it has to be run as the user,
>> since the cache used is stored in the users GNUstep directory in the
>> .GNUstepServices file.
>>
>> Maybe it would make sense to have a global services cache, in some shared
>> accessible directory. So for me as a packager, I could run make_services as a
>> post (un)install script, when installing a package. So it would update the
>> services database everytime a gnustep application is (un)installed.
>
> I think it would be a good idea to have a kind of system wide (or per
> installation domain?) mechanism for storing settings.
We already do (for user defaults).
> This probably
> should not only include the .GNUstepServices and .GNUStepAppList files
> but also the user-defaults database.
We have system-wide user defaults settings.
We don't have system-wide app/service caches because (as mentioned earlier in this thread), there's no point, apart from some potential performance gain.
> If I'm not mistaken, people are
> routinely having trouble to set the right NSFont for their backend
> because the packager cannot do it for them.
This is a user default setting ... so the packager can set that for them.
> Also, it is worth noting that there is a freedesktop.org spec
> [0] for associating mime-types with applications. Maybe we should
> consider supporting that as well [1] for people who occasionally use GNUstep
> applications on their whatever-is-considered-fancy-this-week desktop.
That sound like a reasonable addition.
Niels Grewe
>
> On 20 Jan 2011, at 13:42, Niels Grewe wrote:
>
> > I think it would be a good idea to have a kind of system wide (or per
> > installation domain?) mechanism for storing settings.
>
> We already do (for user defaults).
>
> > This probably
> > should not only include the .GNUstepServices and .GNUStepAppList files
> > but also the user-defaults database.
>
> We have system-wide user defaults settings.
> We don't have system-wide app/service caches because (as mentioned earlier in this thread), there's no point, apart from some potential performance gain.
Yes. I got that now (my mail somehow was delayed for about a day). I
will start telling people about the GlobalDefaults.plist when somebody
asks me awkward questions again…
Cheers,
Niels
David Chisnall
>> We have system-wide user defaults settings.
>> We don't have system-wide app/service caches because (as mentioned earlier in this thread), there's no point, apart from some potential performance gain.
>
> Yes. I got that now (my mail somehow was delayed for about a day). I
> will start telling people about the GlobalDefaults.plist when somebody
> asks me awkward questions again…
I can't remember if this has been asked before, but is this a single file, or can we scan a directory for plists providing global defaults? For packagers, the latter is a lot more useful - they can then add and remove defaults trivially. For example, when you install a theme bundle, you can set it as the global theme, when you uninstall the theme, you unset this default.
This is nontrivial to implement though. A typical use-case would be installing a user appkit bundle - you'd want to add this to an array in defaults on install or remove it from that array on uninstall. Can plmerge or similar do this, and is this documented somewhere that's easy for packagers to find?
David
-- Sent from my brain
Niels Grewe
> On 20 Jan 2011, at 13:42, Niels Grewe wrote:
>
> > [0] for associating mime-types with applications. Maybe we should
> > consider supporting that as well [1] for people who occasionally use GNUstep
> > applications on their whatever-is-considered-fancy-this-week desktop.
>
I thought one could do this by adding a glob-pattern to a subclass of
the built-in pseudo-type inode/directory but that does not seem to work.
Apparently nobody thought about the bundle approach to things when
designing that.
> I'm also not really sure how it will interoperate with UTIs. Maybe someone should poke fd.o to adopt UTIs, rather than MIME types, as the core representation, since they're more expressive...
UTIs are pretty smart. I'll check whether there are smart people
available at fd.o.
Cheers,
Niels
Richard Frith-Macdonald
On 21 Jan 2011, at 12:51, David Chisnall wrote:
> On 21 Jan 2011, at 12:41, Niels Grewe wrote:
>
>>> We have system-wide user defaults settings.
>>> We don't have system-wide app/service caches because (as mentioned earlier in this thread), there's no point, apart from some potential performance gain.
>>
>> Yes. I got that now (my mail somehow was delayed for about a day). I
>> will start telling people about the GlobalDefaults.plist when somebody
>> asks me awkward questions again…
>
>
> I can't remember if this has been asked before, but is this a single file, or can we scan a directory for plists providing global defaults? For packagers, the latter is a lot more useful - they can then add and remove defaults trivially. For example, when you install a theme bundle, you can set it as the global theme, when you uninstall the theme, you unset this default.
Nice suggestion ... I added it.
So now we have a GlobalDefaults subdirectory into which packagers can place .plist files ... and have have all those files merged into the GSConfigDomain of the defaults system.
But we still keep GlobalDefaults.plist and merge that into the defaults system after the files in the subdirectory, so this can continue to be used for general system settings while the subdirectory can be used for package specific settings.
> This is nontrivial to implement though. A typical use-case would be installing a user appkit bundle - you'd want to add this to an array in defaults on install or remove it from that array on uninstall. Can plmerge or similar do this, and is this documented somewhere that's easy for packagers to find?
No, plmerge doesn't do anything like that ... I guess we'd need another tool (or perhaps better, to extend plmerge to allow control over how/where things are merged).
Stefan Bidi
On 21 Jan 2011, at 12:51, David Chisnall wrote:
> I can't remember if this has been asked before, but is this a single file, or can we scan a directory for plists providing global defaults? For packagers, the latter is a lot more useful - they can then add and remove defaults trivially. For example, when you install a theme bundle, you can set it as the global theme, when you uninstall the theme, you unset this default.
Nice suggestion ... I added it.
So now we have a GlobalDefaults subdirectory into which packagers can place .plist files ... and have have all those files merged into the GSConfigDomain of the defaults system.
But we still keep GlobalDefaults.plist and merge that into the defaults system after the files in the subdirectory, so this can continue to be used for general system settings while the subdirectory can be used for package specific settings.
I have a question on this, just out of curiosity... What happens if two different plist files in the GlobalDefault subdir assign a value to the same default? Which one is going to be taken?
The example David gave is nice in theory, but what happens if two or more different theme bundles want to be the default?
Stef
David Chisnall
> I have a question on this, just out of curiosity... What happens if two different plist files in the GlobalDefault subdir assign a value to the same default? Which one is going to be taken?
>
> The example David gave is nice in theory, but what happens if two or more different theme bundles want to be the default?
I wondered this too - presumably the last one to be read is taken. It doesn't matter in the case of themes - the first time you install a theme, one is set, later on it may change the default, or it may not, but if you have multiple themes installed then it's probably because you want users to be able to switch between them.
It's more of a problem, as I said, with user appkit bundles. For example, there's no mechanism for automatically installing the EtoileMenus and EtoileBehaviour appkit bundles and having them both added to defaults, although a metapackage could depend on both and provide a default that activated both.
I'm not sure what other defaults things might want to set. It's not a problem for apps - they can include their own default settings in the bundle. It's only really relevant for bundles. The various -back bundles would probably want to set themselves as the default back end on installation but, again, it doesn't really matter much if you need to explicitly configure which one to use with multiple back ends installed - each can install a .plist for itself, and if the administrator installs two then he can add a line to GlobalDefaults.plist to specify the default one to use.
David
-- Sent from my Cray X1
Richard Frith-Macdonald
On 21 Jan 2011, at 16:05, Stefan Bidi wrote:
> I have a question on this, just out of curiosity... What happens if two different plist files in the GlobalDefault subdir assign a value to the same default? Which one is going to be taken?
It's undefined ... whichever happens to be the last one read (I already wrote that in the documentation) ... thats why GlobalDefaults.plist is merged in *after* the files in the subdirectory ... so you know the values specified there will take precedence.
> The example David gave is nice in theory, but what happens if two or more different theme bundles want to be the default?
Really I think it's not a great example because individual packages *shouldn't* be setting defaults which control other code. I would see individual package preferences as a way to set the defaults for that particular package (as opposed to hard-coding them in the package binaries). Decisions about *which* package (eg which theme) to use should be made by the person in charge of the distribution as a whole. eg. in the case of themes, the distributor would be responsible for ensuring that only one theme is made default within their distribution. So GlobalDefaults.plist might set values for the entire distribution while GlobalDefaults/packagename.plist might set the defaults for a particular package.
Riccardo Mottola
> You're correct, it's not done like that today.
>
> On NEXTSTEP and OPENSTEP systems there was a process called
> make_services... This is why GNUstep has this executable.
>
> be run periodically so that registration of application associations
> is automatic.
>
script of the host package script and/or by make install.
Running it periodically is a bit a waste. We don't really have yet a
standard environbment where we just install apps by drag-and-drop.
Riccardo
Riccardo Mottola
> This would be the ideal way to do things (much, much more efficient than scanning all the directories periodically), but we don't have any way to do that yet as we don't have a cross-platform api for gettting filesystem update notifications :-(
>
>
Riccardo
Ivan Vučica
On Thu, Jan 20, 2011 at 16:02, Richard Frith-Macdonald <ric...@tiptree.demon.co.uk> wrote:
However, it's really not the case that the user has any 'burden' to do it ... applications run it automatically (as soon as the NSWorkspace class is instantiated in the app).
However, I think it would be good if gnustep-make also ran it automatically when doing a make-install (perhaps it already does ... I haven't checked).
So, upon instantiation of NSWorkspace, the registration is automatically done, already?
--
Regards,
Ivan Vučica
The thread is moving in various directions so I'll simply go back to the original purpose of my posting :-)
Regards,
Ivan Vučica
Richard Frith-Macdonald
On 22 Jan 2011, at 16:04, Ivan Vučica wrote:
>
> Still, I really don't think there is much need to actively monitor the filesystem. Simply registering in NSWorkspace's +initialize or -init, or in NSApplication's +initialize or -init (which does not seem to happen at the moment, at my first glance in in the source code last updated a few days ago) would greatly improve the user experience when apps are distributed as bundles.
The -findApplications method is already called from the -init method of NSWorkspace.
If this is not working then ...
perhaps Zcode has not been installed in one of the directories searched or
perhaps the filesystem associations in the Info plist are wrong or
perhaps there's a bug in either generating or using the cached information.
You could try running make_services under gdb and checking what it does to see which of those is the case.
Ivan Vučica
The -findApplications method is already called from the -init method of NSWorkspace.
If this is not working then ...
perhaps Zcode has not been installed in one of the directories searched or
--
Regards,
Ivan Vučica
Fred Kiefer
A simple solution here could be to add some special handling for the
current application into NSWorkspace. Adding its plist contents even
when it isn't installed in a normal directory. But this may lead to
inconsistent behaviour later one, when make_services gets executed by a
different application and wont find the original application any more.
David Chisnall
> A simple solution here could be to add some special handling for the
> current application into NSWorkspace. Adding its plist contents even
> when it isn't installed in a normal directory. But this may lead to
> inconsistent behaviour later one, when make_services gets executed by a
> different application and wont find the original application any more.
Perhaps NSApplication would be a better place for this? A lot of applications won't touch NSWorkspace in normal operation, but they will all use NSApplication (or UIApplication, in the future...). The NSWorkspace code, called by make_services, would then:
1) Look in the cache and check that all apps in the cache still exist.
2) Scan Applications directories for new apps and add them to the cache.
This would mean that anything using NSWorkspace would see all apps that were either installed in their normal locations, or had been explicitly launched at least once by the user from another location.
David
-- Sent from my brain
Ivan Vučica
Perhaps NSApplication would be a better place for this? A lot of applications won't touch NSWorkspace in normal operation, but they will all use NSApplication (or UIApplication, in the future...). The NSWorkspace code, called by make_services, would then:
1) Look in the cache and check that all apps in the cache still exist.
2) Scan Applications directories for new apps and add them to the cache.
This would mean that anything using NSWorkspace would see all apps that were either installed in their normal locations, or had been explicitly launched at least once by the user from another location.
Ivan Vučica
David Chisnall
> This sounds great! However, perhaps checking standard directories for applications and reading all Info.plists is not wise for performance reasons; perhaps leaving that task to make_services would be a good idea, while just making sure that cached apps exist, and that currently running app is registered?
If it's just updating a cache, then it shouldn't be too bad in terms of performance. It wouldn't need to read Info.plists from any .app that was already in the cache (maybe it could store the modification date in the cache and just stat the file to find out if it had been modified more recently, but you could probably just assume it hasn't, and do a proper update the next time the .app is launched, when the .plist is read anyway).
Since you typically only have 3 Applications directories, this would just involve the equivalent of three ls *.app commands in the common case, and a tiny bit more in cases where you've added one or two new apps recently.
David
-- Sent from my STANTEC-ZEBRA
Ivan Vučica
If it's just updating a cache, then it shouldn't be too bad in terms of performance. It wouldn't need to read Info.plists from any .app that was already in the cache (maybe it could store the modification date in the cache and just stat the file to find out if it had been modified more recently, but you could probably just assume it hasn't, and do a proper update the next time the .app is launched, when the .plist is read anyway).
Since you typically only have 3 Applications directories, this would just involve the equivalent of three ls *.app commands in the common case, and a tiny bit more in cases where you've added one or two new apps recently.
--
Regards,
Ivan Vučica