Re: OpenURL issue not fixed with an OpenURLService

Hello All,

A noted also a regression: the badge on the miniwindow of GNUMail is 
showing a '1' counter value on a red background while I have no more 
unread mail.
My previous build of GNUMail was from the tarball, not from svn: with 
this, the badge was with a yellow background and an accurate counter.

On 2025-12-15 13:56:25 +0100 Patrick Cardona <[email protected]> 
wrote:

> Hello Richard,
> 
> On 2025-12-14 23:32:44 +0100 R Frith-Macdonald 
> <[email protected]> 
> wrote:
> 
> 
>> (...)
> 
>> 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
> 
> 
> So I built from svn revision 942:
> - Pantomime framework,
> - GNUMail.
> Did make_services.
> 
> Unfortunately, I had still this unexpected behaviour:
> 
> Clicking on a link from a message read in GNUMail:
> 1) Firefox.app is called and launched: but it opens a new default 
> tab, not 
> the expected URL;
> 2) After several seconds, an NSAlert Panel said: "No service matching 
> 'OpenURL'";
> 3) After I closed this panel, the expected URL was finally opened in 
> a new 
> tab.
> 

Cheers,
Patrick

-- 
Patrick Cardona - Pi400 - GNU/Linux aarch64 (Debian 13.2)
Xorg (1:7.7+24) - libcairo2 (1.18.4-1+rpt1 arm64)
Window Maker (0.96.0-4) - GWorkspace (1.1.0 - 02 2025) - Theme: 
AGNOSTEP - MUA: GNUMail (1.4.0)