Adding metainfo.xml files to each pkg

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding metainfo.xml files to each pkg

Colin Macdonald-2
Hi folks,

I've started making GNU Octave and our pkgs appear in GUI package
managers like Gnome Software (I think there is a KDE one too).  I attach
some screenshots to show why we should do this... otherwise users may
not find our software.

Here is what I've done so far.

 * GNU Octave itself is now fixed and appears again [1].

 * a patch for Image [2], also attached for reference.

 * I've done Symbolic and Doctest.

 * If anyone wants to help, I'm tracking progress here [3].

    - If you make a patch or update your package, please
      update the "upstream" column or add a link.

    - I did not include every pkg: quickly looked at
      sourceforge, listed ones with high downloads.
      But we should do most of them eventually.

    - Probably we should emphasize pkgs which end users
      would install.  I guess we can skip pkgs which are
      usually dependencies (e.g., General---I assume).

    - See here [4] for spec, in particular "<summmary/>
      should be less than 101" characters.

 * I'm focusing on Fedora b/c that is what I use, but its
   not supposed to be distro-specific.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1293561
[2] https://savannah.gnu.org/patch/index.php?8866
[3] https://fedoraproject.org/wiki/Workstation/AddonAppdata#GNU_Octave
[4]
http://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html

best,
Colin

add-metainfo-xml.patch (1K) Download Attachment
screenshot_top.png (236K) Download Attachment
screenshot_bottom.png (109K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding metainfo.xml files to each pkg

Oliver Heimlich
On 18.01.2016 21:41, Colin Macdonald wrote:
> Hi folks,
>
> I've started making GNU Octave and our pkgs appear in GUI package
> managers like Gnome Software (I think there is a KDE one too).  I attach
> some screenshots to show why we should do this... otherwise users may
> not find our software.



>  * I'm focusing on Fedora b/c that is what I use, but its
>    not supposed to be distro-specific.

Sounds interesting, although I haven't found out how the files are used
in other distributions.  For example in Debian they are located at
/usr/share/appdata/, but I have never used them.

To some extend the files overlap with our current DESCRIPTION and NEWS
files for packages. There is not trivial way to avoid redundancy, isn't
it? For example, should we put a description into the appdata files? Or
should we limit ourselves to what you prepared for octave-image: package
name, a summary line, license and contact information?

It is an interesting feature to localize the content in appdata files.
Should we bother with this, given that Octave packages typically have no
i18n?

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Adding metainfo.xml files to each pkg

Colin Macdonald-2
On 19/01/16 15:25, Oliver Heimlich wrote:
> To some extend the files overlap with our current DESCRIPTION and NEWS
> files for packages. There is not trivial way to avoid redundancy, isn't
> it?

Not that I see.  Even the short license tag is in different formats :(
(I guess pkgs could use spdx.org license tags in DESCRIPTION if they want.)

> For example, should we put a description into the appdata files? Or
> should we limit ourselves to what you prepared for octave-image: package
> name, a summary line, license and contact information?

I just put what fields were recommended by the reference I gave: I guess
its probably ok to have others from the larger appdata spec.

In fact I asked about <keywords> and @hughsie said:
>> You certainly can do; any keywords added to the metainfo
>> get promoted to the “parent” application for the search.
[https://blogs.gnome.org/hughsie/2016/01/07/the-importance-of-keywords-for-the-software-center/]

So I think we *should* add keywords to the metainfo.xml for each
package: that way, when someone searches for "image processing" or
"interval arithmetic" they find GNU Octave.

> It is an interesting feature to localize the content in appdata files.
> Should we bother with this, given that Octave packages typically have no
> i18n?

Indeed that can be done.  I also have not yet encountered a pkg that has
i18n: I guess when someone starts doing that, we can update the
metainfo.xml as well.

best,
Colin

Reply | Threaded
Open this post in threaded view
|

Re: Adding metainfo.xml files to each pkg

Colin Macdonald-2
On 19/01/16 17:19, Colin Macdonald wrote:
> So I think we *should* add keywords to the metainfo.xml for each
> package: that way, when someone searches for "image processing" or
> "interval arithmetic" they find GNU Octave.

@oheim, assuming no one grumbles too loudly about these files, maybe we
can re-use the information for your recent Octave-Forge design?

*  100 char <summary> might be nice to have, as sort of medium length
blurb cf., short/long in DESCRIPTION.

*  <keywords>

*  possibly screenshots?

*  not sure about the icons you used.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Adding metainfo.xml files to each pkg

Oliver Heimlich
On 20.01.2016 02:19, Colin Macdonald wrote:
> On 19/01/16 15:25, Oliver Heimlich wrote:
>> To some extend the files overlap with our current DESCRIPTION and NEWS
>> files for packages. There is not trivial way to avoid redundancy, isn't
>> it?
>
> Not that I see.  Even the short license tag is in different formats :(
> (I guess pkgs could use spdx.org license tags in DESCRIPTION if they
want.)


However, this meta information is unlikely to be changed often.  So it's
not too bad.


> So I think we *should* add keywords to the metainfo.xml for each
> package: that way, when someone searches for "image processing" or
> "interval arithmetic" they find GNU Octave.


Sounds perfect!


>> It is an interesting feature to localize the content in appdata files.
>> Should we bother with this, given that Octave packages typically have no
>> i18n?
>
> Indeed that can be done.  I also have not yet encountered a pkg that has
> i18n: I guess when someone starts doing that, we can update the
> metainfo.xml as well.


Given the purpose of these files—finding software that suits
you—translation of the meta data should be useful anyway.


On 20.01.2016 02:24, Colin Macdonald wrote:
> @oheim, assuming no one grumbles too loudly about these files, maybe we
> can re-use the information for your recent Octave-Forge design?
>
> *  100 char <summary> might be nice to have, as sort of medium length
> blurb cf., short/long in DESCRIPTION.


That's a good idea. I have prepared a summary line for each package back
then (see below). Eventually, we simply use the first sentence of the
description on Octave-Forge, which is not perfect.


> *  <keywords>

Definitely.

> *  possibly screenshots?

Screenshots for addons are not as useful as for the main application.
I'd say rather no. But there are packages where this might make sense,
e. g., vrml or vibes, which interface an external application.

> *  not sure about the icons you used.

No. Icons in the appdata are meant for desktop shortcuts.



Here are the package summary lines that I have prepared back then
(partly based on the package descriptions):



bim
Solving Diffusion Advection Reaction (DAR) Partial Differential Equations

cgi
Common Gateway Interface

communications
Digital Communications, Error Correcting Codes (Channel Code), Source
Code functions, Modulation and Galois Fields

control
Computer-Aided Control System Design

data-smoothing
Algorithms for smoothing noisy data

database
Interface to SQL databases, currently only PostgreSQL

dataframe
Data manipulation toolbox similar to R data.frame

dicom
Digital communications in medicine (DICOM) file I/O

divand
n-dimensional variational analysis (interpolation) of arbitrarily
located observations

doctest
Execute example code from the documentation and confirm that the output
is correct

econometrics
Econometrics functions including MLE and GMM based techniques

fem-fenics
Resolution of partial differential equations based on fenics

financial
Financial manipulation, plotting functions and additional date
manipulation tools

fits
Functions for reading, and writing FITS (Flexible Image Transport
System) files

fpl
Export data produced by Finite Elements or Finite Volume Simulations in
formats used by some visualization programs

fuzzy-logic-toolkit
Mostly MATLAB-compatible fuzzy logic toolkit

ga
Genetic optimization code

general
General tools

generate_html
Generate HTML pages that contain the help texts for a set of functions

geometry
Create, transform, manipulate and display geometric primitives

image
Processing images, statistics, transformations, filtering and much more

image-acquisition
Capture images from connected devices (v4l2)

instrument-control
Low level I/O for serial, i2c, parallel, tcp, gpib, vxi11 and usbtmc
interfaces

interval
Real valued interval arithmetic

io
Input/Output in external formats

level-set
Time-evolution of the level-set equation and extracting geometric
information from the level-set function

linear-algebra
Additional linear algebra, including general SVD and matrix functions

lssa
Spectral decompositions of irregularly-spaced time series

ltfat
Time-frequency analysis, wavelets and signal processing

mapping
Simple Mapping and GIS .shp file

mechanics
Classical mechanics and structural analysis

miscellaneous
Tools that don't fit somewhere else

mpi
Message Passing Interface (MPI) for parallel computing

msh
Triangular and tetrahedral meshes for Finite Element or Finite Volume
PDE solvers

mvn
Multivariate normal distribution

nan
Statistics and machine learning for data with and w/o missing values

ncarray
NetCDF files as multi-dimensional arrays

netcdf
NetCDF interface

nurbs
Creation, and manipulation of Non-Uniform Rational B-Splines

ocs
Circuit Simulator

octclip
Boolean operations with polygons using the Greiner-Hormann algorithm

octproj
PROJ.4 library for cartographic projections transformations

odepkg
Solving ordinary differential equations

optics
Various aspects of optics

optim
Non-linear optimization

optiminterp
N-dimensional optimal interpolations of arbitrarily distributed data points

parallel
Parallel programming

quaternion
Quaternion class with overloaded operators

queueing
Queueing networks and Markov chains analysis

secs1d
Drift-Diffusion simulator for 1d semiconductor devices

secs2d
Drift-Diffusion simulator for 2d semiconductor devices

secs3d
Drift-Diffusion simulator for 3d semiconductor devices

signal
Signal processing, including filtering, windowing and display functions

sockets
Socket functions for networking

sparsersb
RSB sparse matrix format

specfun
Special functions including ellipitic functions

splines
Additional spline functions

statistics
Additional statistics functions

stk
Interpolation and regression (kriging)

strings
Manipulation and analysis of strings

struct
Additional structure manipulations functions

symbolic
Symbolic calculation, variable precision arithmetic and more

tisean
Non-linear time series analysis

tsa
Stochastic concepts and maximum entropy methods for time series analysis

vrml
3D graphics using Virtual Reality Modeling Language

windows
COM interface and additional functionality on Windows




Reply | Threaded
Open this post in threaded view
|

Re: Adding metainfo.xml files to each pkg

Carnë Draug
In reply to this post by Colin Macdonald-2
On 18 January 2016 at 20:41, Colin Macdonald <[hidden email]> wrote:

> Hi folks,
>
> I've started making GNU Octave and our pkgs appear in GUI package
> managers like Gnome Software (I think there is a KDE one too).  I attach
> some screenshots to show why we should do this... otherwise users may
> not find our software.
>
> Here is what I've done so far.
>
>  * GNU Octave itself is now fixed and appears again [1].
>
>  * a patch for Image [2], also attached for reference.
>
>  * I've done Symbolic and Doctest.
>
>  * If anyone wants to help, I'm tracking progress here [3].
>
>     - If you make a patch or update your package, please
>       update the "upstream" column or add a link.
>
>     - I did not include every pkg: quickly looked at
>       sourceforge, listed ones with high downloads.
>       But we should do most of them eventually.
>
>     - Probably we should emphasize pkgs which end users
>       would install.  I guess we can skip pkgs which are
>       usually dependencies (e.g., General---I assume).
>
>     - See here [4] for spec, in particular "<summmary/>
>       should be less than 101" characters.
>
>  * I'm focusing on Fedora b/c that is what I use, but its
>    not supposed to be distro-specific.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1293561
> [2] https://savannah.gnu.org/patch/index.php?8866
> [3] https://fedoraproject.org/wiki/Workstation/AddonAppdata#GNU_Octave
> [4]
> http://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html
>

Those screenshoots look pretty good.  It is now also done for the image
and statistics package.

Like Oliver, I'm not very happy with the duplication of information but
I guess this stuff rarely changes.

Having it at the root of the package also itches me a bit.  Does anyone
have an opinion about it?  I guess this is the type of stuff where
downstream packagers are the best to answer.

Carnë