Re: Looking for advice on multiple language spell service installation

[Wolfgang Lux]

Richard Frith-Macdonald wrote:

> On 22 Feb 2010, at 22:32, Wolfgang Lux wrote:
>
> > After committing a set of changes that extend GNUstep's spell  
> > server to support multiple languages, I'm looking for advice on  
> > how GSspell should properly announce its service.
> >
> > By default, users will see only the dictionary for AmericanEnglish  
> > in the Spelling panel. To make dictionaries available for other  
> > languages supported by aspell, users (or rather an administrator)  
> > must change the NSLanguages key in GSspell.service's Info- 
> > gnustep.plist. Apparently, this is not really a workable solution,  
> > in particular since the change would have to be repeated whenever - 
> > gui is reinstalled.
> >
> > The current state could be improved in two ways:
> > 1) Have GSspell.service update its own Info-gnustep.plist to match  
> > the list of aspell's available dictionaries if it is run with a  
> > special command line flag.
> > 2) Create a GSspellService.plist file in the user's Services  
> > directory and have it announce the additional languages besides  
> > AmericanEnglish.
> >
> > Of course the first solution still requires administrator  
> > privileges, but I think this could be acceptable if  
> > GSspell.service is automatically run with the appropriate flag in  
> > a post installation phase. However, I'm not sure whether this  
> > works well for package installation, so I'd appreciate if any  
> > package maintainer who is on this list could comment on this.
> >
> > Unfortunately, neither of the two approaches works at present in  
> > GNUstep. The first approach fails because GSspell.service is  
> > unable to locate its own info dictionary [1]. The second fails  
> > because the spell checker would attempt to start an executable in  
> > the user's Services directory for the additional languages, even  
> > when I explicitly set the executable path in GSspellService.plist.
> >
> > Before starting to work on either implementation, I'd appreciate  
> > to receive comments on which solution you consider better. Or  
> > maybe I have been overlooking something completely obvious.

Thank you for your reposnse, Richard.

> I think the second option is cleaner  as I really don't approve of  
> self modifying application bundles, and think that the user's  
> Services directory is precisely for this kind of thing.

I understand (and share) your dislike of self modifying bundles.  
However, this kind of modification looks to me rather like a post  
installation configuration step, which would just adjust the GNUstep  
installation to the existing system environment after installation.  
This configuration step would need to be repeated only if a system  
administrator has installed additional dictionaries (AFAIK, aspell  
supports only system wide installation of dictionaries).

I could provide a separate tool (or maybe even just a shell script)  
to update the service's Info.plist file. Indeed, my original plan was  
to have GSspell.service just read the NSLanguages key from its own  
info dictionary, but unfortunately this does not work (cf. bug  
#29012). Furthermore, it turned out that I need the ability to  
determine aspell's dictionaries in GSspell anyway, so the executable  
could serve both purposes, implementing the service and updating the  
Info.plist file.

> Now, I don't know why you have a problem with the second course of  
> action.  presumably you have created
>
> ~/GNUstep/Library/Services/GSspell.service/Info.plist
>
> and then run make_services ([NSWorkspace-findApplications] will do  
> that)
>
> So the system will then know that the service exists, and when  
> attempting to access it will try to open ~/GNUstep/Library/Services/ 
> GSspell.service
> At that point, it should look in the Info.plist, find the  
> NSExecutable entry, and launch a task to run the process specified  
> by NSExecutable
>
> As it's not working, I'd have thought the first place to look would  
> be setting a breakpoint in [NSWorkspace-locateApplicationBinary]  
> which should be looking in Info.plist for the NSExecutable entry.

I was a bit more lazy and did just create a file ~/GNUstep/Library/ 
Services/GSspellService.plist, but the effect is the same as when I  
create a full bundle. NSSpellChecker attempts to start the service with
  GSContactApplication(spellServicePath, port, finishBy);
where spellServicePath is the path of the service bundle, not that of  
the executable. Apparently neither GSContactApplication nor the  
methods it uses to start the service look into the bundle's  
Info.plist. I'm not sure if this is the intended behavior of  
GSContactApplication. If so, I could fix NSSpellChecker to look for  
the NSExecutable key itself.

Wolfgang