geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

Dear all,

One market in which Linux-based software has flourished in recent
years is the scientific and engineering community, particularly in
Europe.  At both the universities I have attended, Linux workstations
were used for most computer-based teaching activities in engineering
and physical sciences.  In my time working in the electronic
engineering industry, the (extremely expensive and proprietary) tools
used for microelectronics design and simulation were Linux-based,
almost without exception.

Accordingly, more and more free and open source applications for
science and engineering are being written, released and included in
Linux operating system distributions.  I am one of the developers of a
such a piece of software: a GPL licensed electronics CAD suite called
gEDA (http://gpleda.org/), aimed at medium-complexity designs.

Unfortunately, the Desktop Menu Specification is turning into a
serious roadblock for developers like me who are trying to integrate
our software into the Linux desktop.

The Desktop Menu Specification describes the format of the desktop
entry files (.desktop files) that tell the desktop environment how to
display an application in its system menu.  These files allow
applications to be categorised (for example, spreadsheet applications
are usually placed in the "Office" category).  A small number of "Main
Categories" are defined, and a larger number of "Additional Categories".

The specification states that:

> The list of Main Categories consist of those categories that every
> conforming desktop environment MUST support. … Additional Categ=
ories
> should always be used in combination with one of the Main
> Categories.

"Science" and "Engineering" are currently Additional Categories.

All conforming implementations of the desktop specification (that I am
aware of) display *only* the Main Categories unless explicitly
configured otherwise.  Any application that fails to include one of
the Main Categories in its .desktop file is (at best) shown in a "Lost
and Found" virtual category, or not displayed at all.

This state of affairs is causing serious problems for developers and
packagers of science and engineering applications.  It is very
important for us that when a user installs our software, it shows up
in a location within the desktop menu structure that does not vary
depending on what distribution the user happens to be running.

Without appropriate Main Categories, it is not possible for us to
ensure this.  Here are some examples of applications that I have used
for which it is *obvious* that none of the existing Main Categories
are appropriate.

* ReplicatorG (http://replicat.org/) is a tool used to drive 3D
  printers and other CNC machines.

* gattrib (part of the gEDA suite) is a spread-sheet like tool for
  bulk modification of parameters in schematics for electronic
  circuits.

* GTKWave (http://gtkwave.sourceforge.net/) is a viewer for the output
  of electronics simulations.

These are merely the very pinnacle of a veritable mountain of
scientific and engineering software that, at the moment, is routinely
whimsically miscategorised between "Education", "Development" or
"Graphics".

Over the last 3-5 years, all attempts to get changes made to the
Desktop Menu Specification to fix this problem have been dismissed
with one of the following responses:

* "Few applications are misclassified."  But many applications are
  forcibly miscategorised -- in fact, the Fedora Electronic Lab is an
  Linux distribution where the *majority* of the desktop applications
  installed fit into none of the Main Categories!

* "The misclassified application is only used by a small number of
  users."  Even if this is true (and, free software being what it is,
  there is no way either to prove or refute such a claim), a thousand
  users multiplied by my estimate of at least a thousand misclassified
  applications adds up to a huge number of inconvenienced users and
  developers.

* "The goal is not to provide an ontology that is complete."  That is
  painfully obvious.  However, the very restricted and rarely
  appropriate selection of Main Categories, coupled with the
  requirement that all conforming .desktop files must include one,
  leads to a situation where the incomplete ontology is actively
  harmful.

We, the application developers, have told that we should bypass XDG
and the standards process entirely.  Instead, we are expected to
persuade desktop environment maintainers and distribution managers to
deviate from the Desktop Specification in two separate ways.

1. Our first challenge is to convince packagers to allow our
   applications' .desktop files *not* to include any of the current
   Main Categories, since none of them are appropriate.  Since it is
   common to use lint-like tools to ensure that .desktop files are
   valid, our distribution packagers then have a constant running
   fight on their hands to ensure that kindly souls do not "fix" the
   "bug".

2. Secondly, we must convince the distribution managers to ensure that
   desktop environments show the appropriate Additional Categories.
   This is often a lot of work, both technically (ensuring that it
   works with the distribution's infrastructure and conventions) and
   politically (getting all the required stakeholders to align
   themselves with our strategic initiative).  Once again, the
   arrangements are often fragile and require continual attention to
   avoid them being inadvertently broken by people who assume that
   only the Main Categories need ever be displayed as top-level
   categories.

How, exactly, are developers of science and engineering applications
-- many of whom are first and foremost scientists and engineers --
expected find the time to set up and maintain this for every
distribution that they hope to get their software included in?

Isn't this kind of nightmare *precisely* the kind of mess that the
Desktop Menu Specification was supposed to avert?

Will the maintainers of the Desktop Menu Specification reply to this
and attempt to reassure us that the specification is fine, despite the
reams of evidence to the contrary?  Or will they just ignore us
(again), in the vain hope that we'll go away for good this time?

Or will someone finally propose a way out of this situation?

                            Peter

--
Peter TB Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Applications Research Group
Surrey Space Centre