LWN: Comments on "Desktop entry specification 1.0" https://lwn.net/Articles/194502/ This is a special feed containing comments posted to the individual LWN article titled "Desktop entry specification 1.0". en-us Tue, 02 Sep 2025 23:11:51 +0000 Tue, 02 Sep 2025 23:11:51 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Desktop entry specification 1.0 https://lwn.net/Articles/194547/ https://lwn.net/Articles/194547/ cortana The same reason why it's not a good idea to have an SSL and a non-SSL version of every protocol scheme; we end up with millions and millions of protocol schemes, when we only need one (http).<br> Tue, 08 Aug 2006 17:17:46 +0000 Desktop entry specification 1.0 https://lwn.net/Articles/194523/ https://lwn.net/Articles/194523/ pj why not submit the whatever to the W3C or whomever to make them non-fake?<br> Tue, 08 Aug 2006 16:12:35 +0000 Desktop entry specification 1.0 https://lwn.net/Articles/194521/ https://lwn.net/Articles/194521/ cortana What about a way for an application to inform callers that it wants to take the URL of a resource? Then it would be possible to click on a link to an iCalendar file, RSS feed or other HTTP resource, and hand its processing off to an external program, without increasing the proliferation of fake protocol schemes such as hkp://, feed://, webcal:// and so on.<br> Tue, 08 Aug 2006 16:09:01 +0000 Desktop entry specification 1.0 https://lwn.net/Articles/194511/ https://lwn.net/Articles/194511/ iabervon I don't see any good way of distinguishing this from other similarly-formatted files by magic, even though the specification says the system should handle files without the distinctive extension this way. Why not start the file with "#!desktop" or something of the sort, which would fix this issue as well as making it possible to use from the command line (provided you have a suitably-named executable) and justify requiring the execute bit to mitigate the security risk?<br> Tue, 08 Aug 2006 15:52:20 +0000