[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

electronics-menu REJECTED (discussion)


Introduction and motivation:

I'm seeking some discussion regarding adding extra menus for specific
"niche" sub-categories of programs, such as Electronic design
applications, Hamradio etc..

There exists a hamradiomenus package which adds a "Ham Radio" menu, and
as a developer and user of Electronic CAD packages, would like to see a
similar "Electronics" menu. None of the main XDG menu categories
actually fit this sort of application, and the spec conflictingly says
not to list categories which aren't applicable, and that a package
should list one of the main categories.

In gEDA, the .desktop files list "Electronics" and "Engineering" (both
of which are sub-categories), and without an additional XML file
describing a new menu, these applications will appear under "Others"
under gnome, or lost+found under KDE.

My proposed package:

Description: Menu for Electronics applications
 This package crates an "Electronics" submenu with icon for GNOME, KDE
 and other XDG menu-spec compliant desktop environments.

dpkg-query -L electronics-menu (snipped non file output)


This is similar to the "hamradiomenus" package, although I'm shipping a
more complete theme set of sized icons, rather than a single pixmap.

The rejection:

Hi Maintainer,

rejected, for now, as I disagree with an own package just for two simple
files (plus some graphics).

Any reason why that doesnt go into menu? That would be the more logical
place for it, IMO.

bye Joerg

My reply:

There was precedent, in the "hamradiomenus" package upon which the idea
for this package was based. Since the "Electronics" category in .desktop
files is only officially a subcategory in the XDG menu specification,
the intention was that this package would be installed at the user's
preference. (Probably suggested by packages which provide .desktop files
falling into the "Electronics" category).

The "menu" package doesn't seem to be the right place for this, as
"menu" appears to deal specifically with the Debian menu system, not the
XDG menus.

The nearest correct packages appear to be "gnome-menus" and
"kdelibs-data" which provide the default Gnome and KDE menu files:


It doesn't seem beneficial to duplicate the registration of the menu in
two packages, certainly as the installed icons would clash. Using either
of these would also stop it working with any other XDG desktops. (ROX?..
I don't know if that is Debian packaged or not).

This leads me to suspect that we do need it to be in some separate
package, even if it could be combined with others of a similar ilk.
Since the same "upstream" (me) sources for this menu and icons may be
used in different distributions, I'd make the case that a separate
package is appropriate here, since others may wish to use the same
shared data without dragging it out of a Debian specific package.

Joerg's reply:

This sounds like some kind of xdg-extra-menus package providing menus
like the electronics and hamradio one. Not a single package for every
5kb menu package.

I then sought advice from Joerg on IRC (a summary):

Ganneff: they are small, so disk space is not an issue. so maybe have a
way to let a user enable extra menus, in case he wants them.

pcjc2: I suspect in the cases of ham radio and electronics, the clashing
possibilities are low.. but if the user wanted to install an
"Engineering" menu then you'd get packages listed in both Electronics
and Engineering menus

Ganneff: if you provide a small app for that than the user could ven
chose on their own, not an admin for them.

Ganneff: you can have a app that symlinks menus into the users ~. iirc
there is a place within that ~ for own menu additions?

pcjc2: ~/.config/menus I think

Ganneff: and if not - it would be a script for the admin to
enable/disable the menus for the whole machine

Ganneff: so you install them all in /somewhere, admin runs script, that
symlinks the wanted menus to /wherever

Ganneff: that gives them only the menus they want and us not a trillion
of 5k packages. (which ftpteam *really* dislikes).

pcjc2: I'm basically an upstream on gEDA, PCB and gerbv, all of which
need an Electronics menu

pcjc2: We need collaboration with hamradiomenus and any others which
would be covered under this

(EDIT.. we are talking about two so far, not 1 trillion)

pcjc2: Are you going to delete hamradiomenus from the dist, and tell
them to fix theirs too? (If not.. I don't see how there is any incentive
for them to help with this)

Ganneff: im not deleting it, but strongly encourage to move it into the
generics menu package, as soon as that starts to live

Summary (and my thoughts):

Use case... user "apt-get install geda", and finds their electronics
applications under "Electronics".

Joerg is advocating creating a package "xdg-extra-menus" to gather any
possible extra menus which could be installed by the user.

I'm concerned about category clashes (duplication of apps), and (IMO)
the best way to resolve this is to apt-get remove electronics-menu or
engineering-menu (hypothetical) which each deal with one category each,
and are suggested by other packages as appropriate.

Joerg's suggestion is to install all categories from a single package
then provide an application to copy them into /etc/xdg/menus from an
admin program (or ~/.config/menus/) for the user-specific configuration
case. "pusling" on IRC suggested looking at the a2enmod scripts for
examples of how to do this).

I am however quite concerned about how applications will by default
install where they can be found in menus. No new user will know to run
whatever script is required to enable a particular menu, meaning at the
they should probably be shipped enabled (they only show if an
application has this category anyway). In this case, where applications
fall into multiple categories, they will appear multiple times.

Will all apps desiring a category specified in "xdg-extra-menus" have to
depend on it being installed, or will it be installed by default with
the desktop?

Should we call it "xdg-..." this isn't from the xdg people.. does that
break name-spacing, or mislead about its origins?

As an upstream developer for gEDA Electronics CAD software, I don't
think that I can create or maintain this... I just know that our users
complain about not being able to find our software, and was hoping to
provide a solution.


Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,

Tel: +44 (0)7729 980173 - (No signal in the lab!)

Reply to: