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 <[email protected]> Remote Sensing Applications Research Group Surrey Space Centre -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
