Install spatialite-gui application icon in hicolor theme per Icon Theme Specification

[linux...@gmail.com]

With the deprecation of the menu files in Debian per CTTE #741573 the desktop file and associated icons have become much more important, but the spatialite-gui build system does not install them.

The attached desktop-file.patch updates the spatialite-gui.desktop file included in the gnome_resource subdirectory, it removes the shebang which is not required, and adds Exec variables for the file argument supported on the commandline, and adds Keywords to assist desktop searching. `desktop-file-validate gnome_resource/spatialite-gui.desktop` only hints at the duplicate categories now, that does not need to be changed.

The complementary install-icons.patch updates gnome_resource/Makefile.am to install the desktop file and the associated application icon for various sizes in the hicolor theme per the Icon Theme Specification.

Because support for binary files in patches still sucks this day and age, you need to extract the icons directory from the spatialite-gui-icons.tar.xz into the gnome_resource directory. The existing gnome_resource/spatialite-gui.png can be removed, it's not a valid icon size for the Icon Theme Specification (48x42 instead of 48x48).

The various sized icons > 128x128 were created from the win_resource/spatialite-icon.png because it's the highest resolution (693x613), the > 48x48 <= 128x128 were created from icons/icon_info.xpm, and the <= 48x48 icons from gnome_resource/spatialite-gui.png.

Ideally the source icon is in SVG format, which can then also be installed in $prefix/share/icons/hicolor/scalable/apps to have it available for any size, but as far as I can tell there is no SVG for the spatialite-gui icon.

My autotools-fu is not that great, so there is room for improvement of the changes in install-icons.patch. You probably want to skip the icon installation on OSX & Windows for example.

Kind Regards,

Bas

[a.fu...@lqt.it]

Hi Bas,

your patches have been accepted and are now integral part
of the current codebase into the Fossil repository.

it runs nicely in both Debian 8 Jessie and Fedora 23
(anyway on Fedora no icon is shown on the menu item:
I easily imagine that there is a little confusion about
FreeDesktop standard specifications)

thanks a lot for your useful contribution.

bye,
Sandr

[linux...@gmail.com]

Please consider the attached patch to also install 22x22, 36x36 & 42x42 application icons in the hicolor theme.

The 22x22 icon is required for Debian Policy 9.6:
"
 Unless hidden by default, the desktop entry must point to a PNG or SVG
 icon with a transparent background, providing at least the 22×22 size,
 and preferably up to 64×64. The icon should be neutral enough to
 integrate well with the default icon themes. It is encouraged to ship
 the icon in the default hicolor icon theme directories, or to use an
 existing icon from the hicolor theme.
"
https://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus

The additional icons are available in the tarball.

Kind Regards,

Bas

[linux...@gmail.com]

On Monday, March 14, 2016 at 3:48:19 PM UTC+1, sandro furieri wrote:

(anyway on Fedora no icon is shown on the menu item:
I easily imagine that there is a little confusion about
FreeDesktop standard specifications)

On Fedora $XDG_DATA_DIRS may be set to something other than /usr/share, on Debian $(datadir) and $XDG_DATA_DIRS both use /usr/share.

By default, apps should look in $HOME/.icons (for backwards compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in that order).

I don't have a Fedora VM to verify this, but I suspect the issue is Fedora is caused by a different path for $XDG_DATA_DIRS.

Kind Regards,

Bas

[a.fu...@lqt.it]

On Thu, 5 May 2016 12:09:28 -0700 (PDT), linux...@gmail.com wrote:
> The additional icons are available in the tarball.
>

Hi Bas,

your suggested patch has been accepted and is now
committed into the Fossil repository.

thanks a lot for you nice contributions,
Sandro

[a.fu...@lqt.it]

On Fri, 6 May 2016 06:01:39 -0700 (PDT), linux...@gmail.com wrote:
> By default, apps should look in $HOME/.icons (for backwards
> compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in
> that order).
>
> I don't have a Fedora VM to verify this, but I suspect the issue is
> Fedora is caused by a different path for $XDG_DATA_DIRS.
>

Hi Bas,

just for the sake of curiosity, on Fedora $XDG_DATA_DIRS is
set to "/usr/local/share:/usr/share"

- all icons corresponding to some system package are stored
into /usr/share/icons
- icons corresponding to custom built packages installed
on /usr/local/bin seems to be located on /usr/local/share

bye Sandro

[linux...@gmail.com]

On Sunday, May 8, 2016 at 9:40:27 PM UTC+2, sandro furieri wrote:

On Fri, 6 May 2016 06:01:39 -0700 (PDT), linux...@gmail.com wrote:
> By default, apps should look in $HOME/.icons (for backwards
> compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in
> that order).
>
> I don't have a Fedora VM to verify this, but I suspect the issue is
> Fedora is caused by a different path for $XDG_DATA_DIRS.

just for the sake of curiosity, on Fedora $XDG_DATA_DIRS is
set to "/usr/local/share:/usr/share"

- all icons corresponding to some system package are stored
   into /usr/share/icons
- icons corresponding to custom built packages installed
   on /usr/local/bin seems to be located on /usr/local/share

Since the paths are correct, I suspect that on Fedora gtk-update-icon-cache needs to be called explicitly. It's documented as a %posttrans section in spec files in [0]. On Debian gtk-update-icon-caches is run after package installation via automatic triggers.

[0] https://fedoraproject.org/wiki/Packaging:Scriptlets#Icon_Cache

Kind Regards,

Bas