Xfce 4.2 : desktop menu buglets

[Danny Milosavljevic]

Hi,

Am Sonntag, den 10.10.2004, 15:00 -0400 schrieb purslow at sympatico.ca:
> 041009 Brian J. Tarricone wrote:
> > On 10/09/04 11:05, purslow at sympatico.ca wrote:
> >> generally, the auto-generated menu is an excellent idea,
> >> but the present implementation does seem a bit crude & limited.
> >> might i gently suggest it check  /usr/local/bin
> >> &/or a predetermined list of common apps via 'which app' ?
> > nope.  the blacklist is hack-y enough;
> > i'm not willing to add a bunch of unmaintainable crap to the codebase.
> > if you want to generate menus based on a known list of apps, try menumaker.
> 
> so what is the point of the auto-generated menu ?

That if the distribution is set up correctly, everything will magically
show up.  (And you can always choose not to use it and use menumaker or
just menu.xml)

> IMHO it's not fit to include in 4.2 as it stands:
> it gets a limited set of apps -- KDE + a few random others -- ,

Well then it would be best for the apps to include desktop files as they
should in the first place.

> is vulnerable to spurious  xxx.desktop  files it finds
> & misses a lot of important items, eg Open Office.

huh ? It finds the open office desktop files just fine. (I even tested
it with them back when we wrote the menu spec stuff :))

> 
> i can roll my own by hacking  menu.xml  (excellent help: yours?),
> perhaps by using the menu editor or by using some non-Xfce tool.
> even a small amount of work in that way will create something
> a lot more useful than the auto-generated stuff.
> 
> am i missing something ?

No, you summed up the current state quite well.

So, to reiterate, points are:
- since unix puts executables all in one dir(mostly), there is a need
for a desktop menu (otherwhise the need itself wouldn't manifest at all)
- something needs to be done to make it possible for applications to
categorize themselves (like their directory structure would if there
were one to begin with), so that desktop menus dont have to guess.
- that has been standardized quite stable and long now to be by the
means of putting freedesktop.org ".desktop" files in also standardized
locations.
- if gui apps don't add a desktop file, thats most probably a bug
(probably just a oversight from the author, or they werent common back
when the project was started)
- if apps add desktop files and leave required lines out (yes, that
means you, KDE), that is a bug too and it is already quite hackish to
remove them by blacklist from the xfdesktop menu

Now there are two ways to go:
1. put workarounds in for all those apps that dont install / install bad
desktop menu entries
  * manage blacklists for totally broken files
  * manage renames
  * manage tons of mappings
  * maintenance effort to keep that stuff up to date
  * add menu entries for console apps, foreign apps, wine emulated
apps, ... where does it stop ?

or:
2. just have the apps fixed
  * no maintenance, no static lists, no hacks
  * takes longer since the apps have to incorperate the fix into their
release cycle

I stay with 2., and I believe its general consens to stay with 2..
It takes slightly longer but it will be perfect and not a horrible
kludge, and since we dont have time pressure, there is no problem.
And it is better to have it that way and have users complain (not to us,
but to the app authors!), since then, workload for creating a good menu
will be evenly split among all people, and not forced on every desktop
menu implementation author to reimplement the wheel (or, the threads to
keep a broken wheel together and reasonably round :)).

Its just a human-readable, documented, small file per app. Really.
Shouldn't be hard to add.
And is more worthwhile to write than yet-another-/usr/bin-scanner.

And there is still choice not to use the 'desktop system menu'
autogenerated menu and just roll your own menus. 

cheers,
   Danny

-- 
www.keyserver.net key id A334AEA6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20041010/0bc3596b/attachment.pgp>