Colin Watson <cjwat...@debian.org> writes: > * There's no reason that "has a .desktop file" should imply "shows up > in modern desktop environments", and so I think that the question of > coverage is to some extent a red herring; the systems have different > coverage because they've always had different coverage, not because > the .desktop format is inherently unable to meet the needs of trad > menu consumers.
That's my view -- the two systems are split because they use a different file format, and not through any carefully considered reason. > On the other hand, Keith's draft seems highly aspirational to me. While > it seems to me to be broadly the right kind of long-term technical > direction, there is an awful lot of work in there for people who want > something like trad menus which is being glossed over. I think the only piece of work necessary is to add support for .desktop files to the 'menu' package. With that, other packages are free to transition from menu files to .desktop files and any existing menu programs will continue to work as before, while .desktop file consuming menu programs will slowly see more and more applications to present. > So, I prefer Ian's position in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the > purposes of how the policy text should remain for the time being, and in > terms of the philosophy of not ripping out work from under people's > feet. I guess I'm not sure what work we're ripping out from under people's feet here. The only significant change proposed is to require support for .desktop files in the 'menu' package. I would imagine that the simplest way to add .desktop file support to the 'menu' package would be to translate .desktop files into menu files and process those through the existing code base. > I prefer Keith's position as a long-term direction, but agree > with Ian that it is lacking an awful lot of transitional thought, and > feel that it has a lot of things-should-be-done without it being clear > who will do them. I feel like there's a mis-characterization of what it would mean to switch to .desktop files, and whether the change would need to be all-at-once or could be done incrementally. Here's the transition that I imagine would occur: 1) Support for .desktop files is added to the 'menu' package. This ensures that applications providing only a .desktop file would continue to appear in menu programs using the existing menu package infrastructure. 2) Packages would be encouraged to transition to shipping only .desktop files. Over time, more and more would start to appear in menu programs with native .desktop support. 3) .desktop-based menu program users would start exploring the broader range of applications shown to them and enjoy the benefits of this broader selection of tools. None of these steps places any specific burden on developers, although skipping step 1) would regress menu programs using menu package support, dropping any programs which choose to not ship a menu file. I would expect that to be sufficient incentive for the 'menu' package to add .desktop file support though. -- keith.pack...@intel.com
pgpKTOr3jEr31.pgp
Description: PGP signature
