[Debian GNUstep maintainers] Nearly all GNUstep apps are missing from the GNOME Software catalog

[Josh Freeman]

On Mar 20, 2018, at 4:29 PM, Yavor Doganov wrote:

> Josh Freeman wrote:
>> On Mar 18, 2018, at 9:16 AM, Yavor Doganov wrote:
>>
>>> I wonder how TextEdit is available when its icon is in
>>> /usr/share/GNUstep which is not part of the icon search path.
>>
>>   Here's my guess:
>> [...]
>>   Any software that supports symbolic links can still access the icon
>> at the /usr/lib/... path, however, according to the AppStream's
>> 'icon-not-found' error message for Paje.app, it doesn't support
>> symbolic links:
>
> Right, although Paje's error is not due to the symlink.

    Yup - the original error message had additional possible reasons  
for the failure, I just replaced them with '...' in order to highlight  
AppStream's declaration of non-support for symbolic links. Here's the  
unedited error message (Paje's issue is that there's no file named  
'Paje' present in the archive):

* Icon-not-found
The icon 'Paje' was not found in the archive. This issue can have  
multiple reasons:
    The icon is not present in the archive.
    The icon is in a wrong directory.
    The icon is not available in a suitable size (at least 64x64px)
    On Debian and Ubuntu, the icon is a symlink. The generator cannot  
read symlinks on these distributions - make the icon a real file.
To make the icon easier to find, place it in /usr/share/icons/hicolor/ 
<size>/apps and ensure the Icon= value of the .desktop file is set  
correctly.


>>   TextEdit.app's package installs a custom .desktop file instead of
>> the one generated by gnustep-make. The custom file's Icon entry
>> happens to use the direct filepath, which is probably why AppStream's
>> able to find it:
>> Icon=/usr/share/GNUstep/TextEdit.app/accessories-text- 
>> editor_128x128x32.png
>
> But AppStream looks only in /usr/share/icons and /usr/share/pixmaps,
> so the mystery still applies.

    The fact that TextEdit.app successfully generates the metadata  
despite its icon being outside /usr/share/icons/ and /usr/share/ 
pixmaps/ shows that my initial guess about the path filtering was  
wrong; I thought that AppStream was rejecting *all* icon paths it  
found outside those two directories, whether the paths came from  
scanning the package contents or from scanning the text of  
the .desktop file.
    However, after looking at the code some more, it seems like the  
paths being rejected (at least in that part of the code) are only the  
paths from scanning the package contents, and the .desktop file is  
apparently scanned later (and probably without prefix-based rejection).

    The metadata for TextEdit.app shows that TextEdit.desktop is  
definitely being correctly scanned (so it doesn't appear to be a  
fluke), because the metadata's icon name uses a similar name to the  
one in the .desktop file, "accessories-text-editor_128x128x32.png" ->  
"textedit.app_accessories-text-editor_128x128x32.png":
http://appstream.ubuntu.com/bionic/universe/metainfo/textedit.app.html

    Another fact that might support the theory that the errors are  
caused by symlinks is that PRICE.app receives a different error from  
most other apps: 'Icon-format-unsupported' ('I-f-u') instead of 'Gui- 
app-without-icon' ('G-a-w-i'). This is in spite of PRICE.app sharing  
several common features with most of the apps with 'G-a-w-i' errors,  
such as an icon in TIFF format and a .desktop icon path with a /usr/ 
lib/GNUstep/Applications/ prefix.

    The likely reason for PRICE.app passing the 'G-a-w-i' error check  
(only to fail afterwards at the 'I-f-u' check - and it is likely that  
the 'I-f-u' check happens after rather than before 'G-a-w-i',  
otherwise, all the other TIFF-icon apps would instead have the 'I-f-u'  
error) is the following:

    Unlike most other apps, PRICE's package leaves PRICE's Resources  
directory (& all its resource files) inside /usr/lib/GNUstep/ 
Applications/PRICE.app/; It doesn't get moved to /usr/share/GNUstep/,  
so its .desktop file's /usr/lib/... icon path is actually a direct  
path instead of a symlinked path (unlike nearly every other app).


> Some apps (like GNUMail) have /usr/share/GNUstep in their Icon key as
> well, although the icon is in .tiff format.


    What would disprove the symlink guess would be if there's a  
GNUstep app that has all of the following:
a) a valid-format icon (PNG)
b) a .desktop file with a direct (non-symlinked) path to the icon
c) an AppStream icon error

    The only app I'm currently aware of that matches the first two is  
TextEdit - and it's the only app that doesn't return an AppStream  
error (doesn't match the third).

    If there are no other apps besides TextEdit with both a valid icon  
& a direct icon path, perhaps we could test the theory by updating a  
package? (Having a direct icon path instead of a symlinked one doesn't  
seem to be an issue for TextEdit.app). I'd be happy to send a patch  
for the pikopixel.app package, if it would be OK to push a 1.0-b9a-2  
update? (No upstream source changes needed, could just add another sed- 
command to debian/patches/desktop-file.patch).

Cheers,

Josh