[Pkg-electronics-devel] Bug#567773: The desktop file for kicad and its KDE menu location

[Peter Clifton]

On Fri, 2010-03-12 at 13:51 +0100, Petter Reinholdtsen wrote: 
> [Peter Clifton]
> > not a variant which introduces a vast number of its own menus.
> 
> What are you talking about here?

I don't use Debian Edu, so I could well be mistaken.. but I downloaded
the meta-package, and noted that it shipped a number of ".menu" files: 

art.menu              economy.menu      kde-essential.menu  music.menu
astronomy.menu        electricity.menu  kids.menu           physics.menu
biology.menu          geography.menu    languages.menu      robotics.menu
chemistry.menu        geology.menu      literature.menu     sports.menu
computerscience.menu  graphics.menu     math.menu
construction.menu     history.menu      miscellaneous.menu

These might be sub-menus of course...

What I thought was that if you have a place you want to put
"electronics" teaching applications, you can just add a match for the
"Electronics" category inside one of these menus to gather those icons.

This then prevents the entry turning up in lost+found, and doesn't
detriment the usual categorisation on a desktop where users have
extra-xdg-menus.

Our typical users (not counting specialised Electronics distro-remixes
which have a huge number of electronics related packages), find the
single root "electronics" menu is sufficient to contain the small number
of specialist applications they have installed. Many of these people
will not have more than one or two extra root menus.

I appreciate that in an educational distro, there are a lot of
specialisations, so the root menu isn't welcome.


> The long list of toplevel KDE menues happen with the desktop files in
> the normal debian packages, and do not involve anything Debian Edu
> specific (except installing the set of packages we install in Debian
> Edu by default :).

Gnome doesn't show menus with no categories in it - thus there is no
harm in extra-xdg-menus shipping (for example), the "Ham radio"
category. (I didn't want that category myself, but was forced to inherit
it from the old "hamradio-menus" category.

When we introduced extra-xdg-menus, it was previously just a package
called "electronics-menu", as used in various other distributions. The
then ftp-master refused to include "electronics-menu", as "yet another"
package to provide a single .menu file and an icon.

The "compromise" reached was that I had to write an all-encompassing
package to wrap up all extra menus people might want to ship, such as
"Ham Radio" and "Electonics". Since not everyone would want each menu,
"extra-xdg-menus" ships with some crufty little scripts to insert and
remove sym-links to the extra menus it ships.

I personally don't like extra-xdg-menus, in spite the fact I wrote it. I
feel that shipping separate packages would have been a far superior
solution, and more in line with what other distros do. (Fedora has
"electronics-menu" for example, although due the large number
electronics apps in their FEL (Fedora Electronics Lab) remix, they use a
lot more sub-menus to categorise within the "Electronics" category than
I did.

[snip]

> I base this on the output from 'aptitude why extra-xdg-menus', which
> said it was because kicad depend on it.

Yes, "Depends" is too strong and really needs fixing.

> > (As an aside, I see Debian Edu lists a bunch of advanced ASIC design
> > packages, but missed the gEDA suite for schematic design which fits
> > nicely with the PCB package you have.)
> 
> We would love to get help reviewing the list of electronics related
> packages we install, to get the best set of packages. :) Perhaps a
> better solution is to drop kicad and install some simple tool that do
> not depend or recommend on extra-xdg-menus.

No, Kicad is good.. don't drop it! In order to get the install to work
"nicely" on a stock machine, the extra-xdg-menus needs to be at
"Recommends" level, otherwise it doesn't get installed, and the user
gets a bad experience.

> > We SHOULD NOT add bogus categories to .desktop files.
> 
> Yes.  And we should make sure no package show up in the Lost+found
> toplevel menu section, even when extra-xdg-menus is not installed.  (I
> suspect we have different definitions of bogus categories. :)

Perhaps, but all the other electronics upstreams and developers I've
talked to agree that "Science" is wrong, and "Education" is wrong.
It would be like saying "GIMP" should be in the "Education" category
because you're using it to teach an art class.

The package won't show up in "Lost+Found" if Debian Edu ships a .menu
file which pulls Electronics apps into a different category. I'll
happily take a look (next weds) to see how best to do this.

It is quite expected that desktop integrators (such as Debian Edu) might
want to ship revised .menu files to organise applications. Different
categorisations will make sense for different target audiences. As an
Professional Engineer, I don't expect any of my professional tools to
end up under an "Education" menu with the gcompris program installed to
for kids to play with!

Regards,

-- 
Peter Clifton

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

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)