| 1 |
Hi, |
| 2 |
|
| 3 |
i will go trough this GLEP point by point. |
| 4 |
|
| 5 |
In Rationale the freedesktop specifications are first defined as just |
| 6 |
that, but in the advantages list it becomes 'standards'. They're not |
| 7 |
standards yet, they are to be implemented and nothing supports them yet. |
| 8 |
Neither are they finalized, the specifications are still under active |
| 9 |
discussion and might change over time. We should be careful in |
| 10 |
implementing big changes on such uncertain grounds. |
| 11 |
Another advantage mentioned is 'integrate with small changes to our |
| 12 |
ebuildtree', while in Drawbacks it sais that 'it involves changing a lot |
| 13 |
of ebuilds'. This really clashes in my opinion. |
| 14 |
|
| 15 |
Next Specification. In 1.1 we follow icon spec 0.9.4, current GNOME and |
| 16 |
KDE .desktop files follow this or slightly older specifications already. |
| 17 |
Changes between this and previous specs are minimal, so current .desktop |
| 18 |
files can be used without a problem. The categories field of menu spec |
| 19 |
0.7 seems only to have been extended with more 'official' categories, so |
| 20 |
no need to change current .desktop's for that either. |
| 21 |
Next we get to 1.4, where we have to install a desktop by 'hand' in |
| 22 |
every ebuild. Current gnome ebuilds already do this fine, i see no need |
| 23 |
to change this behaviour and add a .desktop to every GUI application |
| 24 |
files dir. This would probably become a mess soon, where developers |
| 25 |
forget to update the desktop, leaving newer translations out, etc. |
| 26 |
(defying much of the 'i18n support' advantage). This advantage doesn't |
| 27 |
go for GNOME and KDE anyway, those already support i18n fine (know too |
| 28 |
little about the other WMs to comment). |
| 29 |
In point 2 a 'rules file' has to be added for every WM, in GNOME the |
| 30 |
current suggested implementation results in 2 user menus. I find this |
| 31 |
more confusing than helpful. For other WMs i don't know how it would |
| 32 |
work out, but i would prefer to see an effort being made to make these |
| 33 |
follow the suggested menu spec. |
| 34 |
Most of point 4 can be skipped, it's all in the menu spec. |
| 35 |
|
| 36 |
Now to the Drawbacks, as mentioned I'm against changing every |
| 37 |
application ebuild to support such a system. A specialized desktop entry |
| 38 |
should be unneeded, leaves only the menu generation to the package. In |
| 39 |
gnome we should be able to cope with this trough the eclass if |
| 40 |
necessary, but ideally i wouldn't even want to add this. If the WMs |
| 41 |
implement the menu spec directly, there is no need to regenerate a bunch |
| 42 |
of menus (file hierarchies) after every application merge (are these WMs |
| 43 |
able to handle updates during use anyway ?). |
| 44 |
|
| 45 |
One of the big points here is providing 'per user menus', if these wms |
| 46 |
do not support that, how will this be done without proper menu spec |
| 47 |
support ? If we have to create menus systemwide from spec + rules file, |
| 48 |
there still is only 1 menu for the system. I can only look at the |
| 49 |
proposed patch to be included for GNOME, that is not user specific for |
| 50 |
sure. Or am i missing something important here ? |
| 51 |
|
| 52 |
I'm all for supporting both the desktop-entry spec (although also |
| 53 |
slightly older versions than 0.9.4) and the menu-spec. Current |
| 54 |
GNOME/GTK/KDE apps should need no changes to support this with their |
| 55 |
current .desktop files. The menu spec has support for 'legacy menu |
| 56 |
hierarchies', so no need to mess with older ebuilds with .desktops |
| 57 |
either (eg. gnome1/gtk1 apps), leaves only GUI apps without a .desktop |
| 58 |
to be provided with a local gentoo .desktop . |
| 59 |
Gnome could (with some backporting) probably support the menu spec |
| 60 |
natively within a relatively short timeframe, i'm not sure what the KDE |
| 61 |
status on that is. Leaves only the other WMs, which i think should be |
| 62 |
pushed to support these specs as well, instead of creating another layer |
| 63 |
we should maybe work on implementing these specifications in the |
| 64 |
upstream code ourselves. |
| 65 |
|
| 66 |
In short, i think very little changes in the tree are needed and focus |
| 67 |
should not be on providing our own menu layer, but to patch the |
| 68 |
non-supporting WMs to support the recommended specifications. If that is |
| 69 |
the case, then there is no need for a menu specific USE flag, the whole |
| 70 |
thing would be transparent enough to be used Gentoo wide. |
| 71 |
|
| 72 |
- foser |
| 73 |
|
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-dev@g.o mailing list |
Archives