Re: [gentoo-dev] GLEP #16: Gentoo Menu System

[Paul de Vrieze]

Hi,

Here will be my comments on this GLEP. I will first give some general
comments, and then comment on foser's points.

In general I would like to see a gentoo menu system. There are some
conditions that I would like to see.

- It should be easy to offer menu items for a particular application.
- There should be an upgrade path for packages that allready exist on the
  system
- The menu system should not move the default menu items of a windowmanager
  away from the default location. Of course it should be possible for the
  user to manually rearange any menu item.
- The system should be transparent, and avoid update problems (like when a
  menu needs to be generated). We need to look at the extend to which this
  can be achieved.
- The complexity of the code to be maintained by gentoo needs to be kept
  low. To this respect we might opt for actually patching the windowmanagers
  to work with the desktop and menu specifications we opt to use. If well
  implemented it seems likely that upstream authors want to include this
  code and take away maintenance from us. This would also solve many
  problems with updating etc.


Now my comments on foser's comment:

> In Rationale the freedesktop specifications are first defined as just
> that, but in the advantages list it becomes 'standards'. They're not
> standards yet, they are to be implemented and nothing supports them yet.
> Neither are they finalized, the specifications are still under active
> discussion and might change over time. We should be careful in
> implementing big changes on such uncertain grounds.
> Another advantage mentioned is 'integrate with small changes to our
> ebuildtree', while in Drawbacks it sais that 'it involves changing a lot
> of ebuilds'. This really clashes in my opinion.
>

I too want to see the changes in ebuilds avoided if at all possible. One
thing is that I think that if an application allready provides some
desktop file this file needs to be taken (and changed so that it is valid
for our specification) automatically (possibly with an inherit statement).

> Next Specification. In 1.1 we follow icon spec 0.9.4, current GNOME and
> KDE .desktop files follow this or slightly older specifications already.
> Changes between this and previous specs are minimal, so current .desktop
> files can be used without a problem. The categories field of menu spec
> 0.7 seems only to have been extended with more 'official' categories, so
> no need to change current .desktop's for that either.
> Next we get to 1.4, where we have to install a desktop by 'hand' in
> every ebuild. Current gnome ebuilds already do this fine, i see no need
> to change this behaviour and add a .desktop to every GUI application
> files dir. This would probably become a mess soon, where developers
> forget to update the desktop, leaving newer translations out, etc.
> (defying much of the 'i18n support' advantage). This advantage doesn't
> go for GNOME and KDE anyway, those already support i18n fine (know too
> little about the other WMs to comment).

See above, I think too that we should just use the desktop files that come
with an app. If they are available.

> In point 2 a 'rules file' has to be added for every WM, in GNOME the
> current suggested implementation results in 2 user menus. I find this
> more confusing than helpful. For other WMs i don't know how it would
> work out, but i would prefer to see an effort being made to make these
> follow the suggested menu spec.
> Most of point 4 can be skipped, it's all in the menu spec.
>
I agree with it.


> Now to the Drawbacks, as mentioned I'm against changing every
> application ebuild to support such a system. A specialized desktop entry
> should be unneeded, leaves only the menu generation to the package. In
> gnome we should be able to cope with this trough the eclass if
> necessary, but ideally i wouldn't even want to add this. If the WMs
> implement the menu spec directly, there is no need to regenerate a bunch
> of menus (file hierarchies) after every application merge (are these WMs
> able to handle updates during use anyway ?).
>
I agree with native support if that is achievable for this wm with minimal
code changes. To that respect I think we need a support library that can
read the desktop entries and can be used as a plugin to the patched wm's.
If the plugin is present we use it's menu, else use the native menu.

> One of the big points here is providing 'per user menus', if these wms
> do not support that, how will this be done without proper menu spec
> support ? If we have to create menus systemwide from spec + rules file,
> there still is only 1 menu for the system. I can only look at the
> proposed patch to be included for GNOME, that is not user specific for
> sure. Or am i missing something important here ?
>
With a support library and a patched wm we should be able to have a user
menu, as the menu is retrieved at runtime.

> I'm all for supporting both the desktop-entry spec (although also
> slightly older versions than 0.9.4) and the menu-spec. Current
> GNOME/GTK/KDE apps should need no changes to support this with their
> current .desktop files. The menu spec has support for 'legacy menu
> hierarchies', so no need to mess with older ebuilds with .desktops
> either (eg. gnome1/gtk1 apps), leaves only GUI apps without a .desktop
> to be provided with a local gentoo .desktop .
> Gnome could (with some backporting) probably support the menu spec
> natively within a relatively short timeframe, i'm not sure what the KDE
> status on that is. Leaves only the other WMs, which i think should be
> pushed to support these specs as well, instead of creating another layer
> we should maybe work on implementing these specifications in the
> upstream code ourselves.
>
It should be easy enough to create support for it in kde. The interfaces
in kde are quite clean. As stated above I am too inclined to create
support in wm's instead of creating ways to generate menu's. The latter is
destined to create problems with users editing the menu through the native
menu editor and then finding out that sometimes their changes "disappear"
after they installed a new application.

> In short, i think very little changes in the tree are needed and focus
> should not be on providing our own menu layer, but to patch the
> non-supporting WMs to support the recommended specifications. If that is
> the case, then there is no need for a menu specific USE flag, the whole
> thing would be transparent enough to be used Gentoo wide.

I agree we should aim to need as little changes to the tree as possible.
Changing the tree is a lot of work. Look at the metadata.xml files. There
are still many packages without such a file.

I agree with foser on patching non-supporting WM's to support the
specifications. The easiest way I see is to have a plugin provided by the
menu ebuild. If that plugin is present in the filesystem the windowmanager
will use the gentoo menu system (either through the plugin or natively
(gnome, kde)). This will also make transparent the enabling of the menu
system based on the menu system being merged. It will also make sure that
the windowmanagers can use the system immediately.

Paul


--
gentoo-dev@g.o mailing list