On 09/12/2025 13:20, Patrick Cardona wrote:
Hello Richard,
On 2025-12-08 21:12:56 +0100 R Frith-Macdonald <[email protected]>
wrote:
So I looked for it:
for FOLDER in /System/Library /Local/Library/; do find $FOLDER -name
"Services.GNUstepExtPrefs"; done
Not found.
Is my GNUstep system badly set?
Sorry, I made a typo in the name, it's Services/.GNUstepExtPref
This is your personal preference setting, so it's in *your* Library
folder (not System or Local), which is usually inside ther GNUstep
folder in your home directory. The file format is binary property list,
so if you really want to look at it you should use something like the
pldes tool.
If the fact this is not provided even in GNUMail is confirmed, I think we
should implement it in a more general way.
I think the current framework is about as general and flexible as is
possible ... services are available in all apps with no coding required,
and the full mechanism can be used from code extremely easily (one line
of code).
However ... when I investigated GNUmail I found that the code in the
gui library was partially broken (it worked years ago when first
written, but had bit-rotted since then). I have made changes to address
that in the 'service-fixes' branch of the gui librrary, so you could try
those.
The fixes involve:
Allowing 'Open URL' services to work with either string pastebooard data
(how it used to work) or url pastebaord data (the preferred format
nowadays), and fixing a naming issue so that opening a URL via services
should work reliably again.
The attempts the framework makes automatically should now be in four
stages before failure:
1. try asking a GNUstep app to open the URL (using the preferred app) if
any app is available
2. try asking an 'Open URL' service to open the URL
3. try running the non-gnustep program specified by the NSWebBrowser
user default
4. try the fallback mechanism for opening a file of unknown type
