Matthias Urlichs wrote: > Hi, Herbert Xu wrote: > > If you think that it's so obvious, why don't you start by addressing my > > objections in the quoted bug report? > > > I see only one -- duplicate work, which has been beaten to death already. > But since you insist on my opinion ... Nowhere in Herbert's response to bug #219304 does he talk about "duplicate work". He's quite clearly talking about duplicated information in a package. Which would leads to duplicate menu entries for Dosemu in the Gnome and KDE menus for Dosemu if he were to add a .desktop file. Which would certianly be bad UI and confusing. > The fact is that it isn't. At time X, which is when a .desktop file has > been written, said file can be added to the package it's written for. > At time Y, which is when there is lossless conversion from .desktop files > to menu files and/or when all menu managers can process .desktop files > directly, the old menu files may be deleted. No, you're going about this backwards. Get the code written. Get the policy for Debian menu layout using .desktop files written. Make sure that there's a plan for how the transition will work. Only then does it make sense to begin asking maintainers to switch to .desktop files. > Given that there are a number of packages with old menu files which > require conversion, I do not see why, for any given package, the times X > and Y need to be identical. Because until you have code and a policy, you cannot test the menu items you are adding, and you do not know they will fit within the policies we will eventually devise for layout, wording, icons, whatever, for .desktop menu entries. And because in the meantime it leads to bloat, and to poor UI. By going about this backwards, you only double the amount of work that maintainers who add .desktop files will eventually have to do, and you do nothing to advance your goal of widespread use of .desktop files in Debian. If you would write some code, come up with a clear and workable transition plan, and go through regular channels to get it into policy, you would find that most developers would move to the new system with only a little nudging. As it is, you're setting yourself up for a fight every step of the way, and it's painful to watch. -- see shy jo
Attachment:
signature.asc
Description: Digital signature