Linux,  Mandriva

Improving Mandriva’s menu structure

I finally started writing a new paper evaluating the new menu structure as was introduced in Mandriva 2008.0. Generally, I think the new menu structure was a huge improvement: no more having to go two or three levels deep to start a simple audio player or an compression utility, is a big advantage.

Some things can still be improved though, especially in KDE, where some menus tend to become a bit long. I’m trying to write down some proposals to fix these problems. I’m also going to write a bit about default choice of installed applications, as this also influences how menus look right after the installation. Don’t expect a complete new menu structure again, as that would be useless now, but some proposals for smaller improvements to the current structure, which should not be difficult to implement.

If anybody has any practical proposals for improvements, let them know here. Which menus are too long for you, and what are their contents? How would you propose fixing the problem? Which applications are installed by default, but do you remove immediately after installation because you never use them? Or the inverse, which extra applications do you install immediately after the installation of Mandriva?


  • Frederic Crozat

    Just for the record, Mandriva KDE team will try to add for 2008.1 (if possible) tooltip support for KDE menu, to show comment field for menu entries (just like GNOME). I think it will improve KDE menu a lot since many KDE applications have cryptic names (this problem is a little less visible under GNOME).

    But I agree we still have room for tuning the new menu structure.

  • Frederik

    There seem to be indeed useful comments on that page. Unfortunately, I don’t speak Portuguese :-( As far as I can see, it seems this user has found some applications with wrong desktop categories. Has he filed separate bugs about these in Mandriva’s bugzilla? That’s the only way to get them fixed…

  • Frederik

    While that would be a nice improvement for KDE’s menus, I don’t think it is crucial. Actually the biggest issue in KDE’s menu, is that Mandriva by default only displays the application’s name, while there is an option to show the name followed by the GenericName. This should be the default setting, and would already fix the biggest problem.

    A related problem in GNOME, is that it seems the practical implementation of the GNOME HIG Menu Item recommendation ( conflicts with the spirit of the desktop entry specification (

    The GNOME HIG says that application menu entries should include the generic name in the menu item. If this was done according to the spec, than for example in f-spot.desktop there should be:
    GenericName=Photo Manager
    Comment=Organize, enjoy and share your photos

    and than the Gnome menu should be configured to show the Name field immediately followed by the GenericName field, to comply with the GNOME HIG.

    Unfortunately, GNOME decided to put the GenericName immediately in the Name field and does never show the GenericName field (which is used by KDE). It’s very annoying that these two desktops implement this differently, because that makes it difficult to always have correct results.

    Take for example a look at this commit for the GTK+ Transmission bittorrent client:

    Following the spec, this change is correct, but now what is shown in GNOME’s menu does not comply anymore with the GNOME HIG :-(

  • Frederic Crozat

    I don’t agree with you about using “Name (GenericName)” as default for KDE. This would clutter menu way too much, causing them to become unreadeable. This is why I think tooltips are better for this.

    Feel free to open a bug on gnome-menus (not gnome-panel) about what is used on to fill panel items, I’m sure Vincent Untz will be delighted to fix it ;)

    Remember also that GenericName comes from KDE (before fd.o “unification) which explains why it was never used by GNOME.

  • Kalvy

    As you have seen, I have found some applications with wrong desktop categories.

    However, those categories are wrong not because they make an entry appear somewhere in the menu where it shouldn’t be, but because the categories are very generic, or are just wrong.

    I mean, for example, Base should include “Database” category, because it IS a database application, but not to make it appear somewhere in the menu. I don’t know if I’m being clear…

    I know that I should fill bugs for them, but I haven’t made it yet because I have very little free time.

    Anyway, that thread is an effort to develop a package to use the classic menu in Mandriva 2008 ;) So I don’t think that it will be useful to you.

    Oh, and it is Spanish, not Portuguese :)

  • Kalvy

    Sorry, but I haven’t understood you.

    What is the problem in having a “Database” category (along with the other categories it has now) in Base desktop file and making it appear in Office menu? I think that you were refering to it, but I’m not sure.

  • Frederic Crozat

    It would clutter the menu (we specifically killed all double instances of menu items) and it would cause a Development top menu entry to appear when is installed, since Database is inside Development top menu.

  • Frederik

    I have not verified if it would be possible according to the spec, but maybe we could make a difference between the categories Office;Database; and Development;Database;? Applications having Office;Desktop (used by OOo Base, Glom and other user oriented DB apps) should appear in our Office menu, while Development;Desktop; (phpmyadmin, mysqladmin,…) appears in our Development menu.

  • dexter11

    “Generally, I think the new menu structure was a huge improvement”

    Well at least you.

    “Some things can still be improved though, especially in KDE, where some menus tend to become a bit long.”

    Those menus become long from the number of installed applications no matter what you do. Since they organized in less subcategories after a certain installed applications these new menus become cluttered and confusing. No matter if the programs are only two level deep if I have to browse a long list to find them. It just takes more time find what you need.
    The only way to avoid it is to keep a minimal system. This means that by using this menu you are forcing the user the uninstall everything he can. Personally I don’t like being forced.
    For me it would have been a good compromise if the menu just wouldn’t display subcategories which has only one program. E.g K3b used to be under System -> Archiving -> CD-Burning -> K3b. For me K3b was the only installed CD burner so it was the only entry under the CD-Burning subcategory. So with my proposal the CD-Burning subcategory wouldn’t be displayed and K3b could be find under System -> Archiving -> K3b.
    I think it’s a good compromise between too deep and too cluttered menus.

    “Which applications are installed by default, but do you remove immediately after installation because you never use them?”

    Fax packages. Kfax and KDEprintfax. And KGhostview, KPDF is a way better.

  • dexter11

    I forgot two things from my previous post.
    First the menu structure should be easily usable from a Kickoff style menu because that will be the default in KDE4. Or at least currently it looks it will be. And the current menu is failing in this.

    Second I forgot to write the possibly only thing which I like in the new menu and that is the OpenOffice programs are finally look organized and neat in the menu.

  • Kalvy

    You shouldn’t have removed the “Database” category from Base desktop file to avoid that. If a desktop file has the right categories for an application and the application doesn’t show in the menu as it should, the problem is in the menu, not the desktop file. Changing the categories in the desktop file isn’t a solution, just a workaround.

    A desktop file should list all the categories that clearly apply. If due to those categories an application shows in a menu layout somewhere not intended, you can use, for example, the exclude element in the menu layout for that specific application, or a combination of categories (such as Office and Database).

    But “fixing” it removing the “offending” category from the desktop file is just a solution for a specific menu layout, not a real solution. Menu layouts should adapt themselves to the information provided by the desktop files (so they should provide the most accurate categories), and not the other way around.