| 1 |
On Wed, 2003-08-13 at 17:16, Heinrich Wendel wrote: |
| 2 |
> They have to change to use the new menu system. |
| 3 |
|
| 4 |
Even though ours conforms better to the current way both KDE and Gnome |
| 5 |
do it? |
| 6 |
|
| 7 |
> > Are you planning on changing all of the |
| 8 |
> > ebuilds which provide any form of .desktop entries? |
| 9 |
> At the moment i see no other way. |
| 10 |
|
| 11 |
That sounds like a complete fuster-cluck and a total waste of developer |
| 12 |
time. This means we would have to make modifications to hundreds of |
| 13 |
ebuilds and either create source patches for packages or manually move |
| 14 |
and modify .desktop files from ebuilds/packages which currently provide |
| 15 |
them. As I see it, that is a worst-case scenario and probably the most |
| 16 |
labor-intensive way to go about it. |
| 17 |
|
| 18 |
> > What would an |
| 19 |
> > ebuild submitter need to do to make sure their ebuild's .desktop files |
| 20 |
> > meet the requirements? |
| 21 |
> |
| 22 |
> I will create a validater. |
| 23 |
|
| 24 |
I hope you plan on having it added to repoman, because I know that many |
| 25 |
developers are not going to care and won't bother running a stand-alone |
| 26 |
application to validate the menu entries in an ebuild. Many people |
| 27 |
would consider that "non-essential" behavior of a package. |
| 28 |
|
| 29 |
> > Would there have to be anything added to the |
| 30 |
> > ebuild to have the menus created properly, or is it done on-the-fly and |
| 31 |
> > transparently? |
| 32 |
> |
| 33 |
> take a look at portage/domenu in cvs, so a ebuild would have to add one |
| 34 |
> command: domenu foo.directory |
| 35 |
|
| 36 |
Like I said, it looks like a kludge. Would a better way of going about |
| 37 |
it not be to generate the menus from the already existing structures in |
| 38 |
place? Then no modification would need to be done to an ebuild to |
| 39 |
ensure proper menu usage. If, say, a new Gnome app was added and it |
| 40 |
adds its own .desktop entry to /usr/share/applications as it should, |
| 41 |
then update-menus should detect that application and modify the menus |
| 42 |
accordingly, rather than the developers having to modify the intended |
| 43 |
behavior of the package to suit our needs. If we were providing a |
| 44 |
near-stable tree of binary packages, I could see this happening easily, |
| 45 |
but Gentoo is too much of a moving target and quite frankly, I don't |
| 46 |
know many developers that want to be spending a large amount of time |
| 47 |
patching up ebuilds to make sure that they install their .desktop files |
| 48 |
into /usr/share/menu/applications or wherever we decide they should be. |
| 49 |
Maybe I am just not understanding exactly hwo this is going to work |
| 50 |
out. Perhaps you could shed some light? |
| 51 |
|
| 52 |
-- |
| 53 |
Chris Gianelloni |
| 54 |
Developer, Gentoo Linux |
Archives