On Fri, Jul 10, 2020 at 02:02:31PM +0900, Charles Plessy wrote: Thanks Charles for your reply!
> My own take on that problem is to make it "optional" instead of > "standard", so that people can develop alternatives, or try to entirely > live without it (probably using XDG as a replacement). This sounds sensible to me. > One problem is that the mime-support ships /etc/mime.types, which is > needed by many programs beyond the mailcap system. I proposed to move > it to base-files and the answer was "I don't think it would be a good > idea". So maybe we need a mime.types package, priority standard, that > contains this single file. Or maybe you can help me to make Santiago > change his mind. http://bugs.debian.org/787571 I do understand Santiago's reasoning, and I don't see a problem in having mime-support only provide /etc/mime.types, and depend or recommend a mailcap package with lower priority, that other packages can provide. The mailcap package could Provides: run-mailcap, opening the way for other packages to provide alternative implementations, like via xdg-open. In this way, packages that depend on mime-support for /etc/mime.types would keep working, and I understand they are the majority. Packages that depend on mime-support for run-mailcap or /etc/mailcap can keep working because of the dependencies, and can get warned to depend on run-mailcap or mailcap depending on what interfaces they need of it. > Second problem: I proposed on debian-devel to make mailcap optional in > 2019 and the only answer I got was: "I don't really see a benefit to this." > https://lists.debian.org/debian-devel/2019/08/msg00306.html > Frankly speaking, this makes me fear that resistance can spark after I > would have invested my time in working on it. My impression was, rather than of hostility, of not many people understood the situation or cared much about it. Personally, I ignored the existance of mime-support for 20 years, and got aware of it only when I started to dig on why mutt opened files with the most annoying possible program depending on machines. I had had other mailcap related issues in the past, which were solved by a quick google search and copypaste of some reasonable sounding line from stackoverflow to ~/.mailcap without digging further. > (I also proposed to hijack /usr/bin/open so that Mac users would feel > at home, but as you can guess, the answer was kind of "no", or more > precisely: wait 5 years before seing it happen. Actually, I wish I had > done it. https://lists.debian.org/debian-devel/2014/04/msg00822.html) That seems like worth doing to me in general. In my system I do indeed have openvt but not open, and I see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732796 has been fixed, liberating open for just this. > In summary, I think xdg-open could be the standard default on all > systems even if they do not have a Destkop environment installed. > Actually, xdg-open falls back on mailcap in these cases and I think that > a bunch of tools are already calling xdg-open directly. So we would > need a tool that draws information from /usr/share/applications instead > of /usr/lib/mime, and voilà we would just have to make xdg-open aware > of it. Indeed! > Thanks again for your thoughts; it is long overdue that the mailcap > systems evolves and at least stops standing in the way of change. If I > can count on your support and on Debian's benevolence, I am more than > happy to push major changes. I'm happy to support improvements on this. Nobody can guarantee Debian's benevolence, although I think discussions have become somewhat easier since 2014. On Fri, Jul 10, 2020 at 02:57:24PM +0900, Charles Plessy wrote: > I just remembered it is more complicated: the FreeDesktop menu entries > do not contain priority values. The informations used by the Desktop > Environment systems to sort entries in their menus are somewhere else, > and I have not found yet... I'm surprised hearing that priority values exist in mailcap, and PDFs still open in Calibre. I had thought it just used alphabetical ordering. Admittedly, the user experience is somewhat confused by some programs using run-mailcap and some xdg-open. For example, right now in my system I have a sane default for JPEG files in mailcap but not in xdg-mime: $ run-mailcap --norun /usr/share/gimp/2.0/scripts/images/texture1.jpg geeqie '/usr/share/gimp/2.0/scripts/images/texture1.jpg' $ xdg-mime query default image/jpeg darktable.desktop But when I open a file using mutt, mc, or a file manager, it's not clear which of the two backends is being making the wrong choice. So if I opened a PDF in mutt, run-mailcap would frustrate me with calibre, and if I clicked on a JPEG in pcmanfm, xdg-open would frustrate me with darktable, but the UI hides from me what it is that I could debug. How do priority values work at the moment, and are they being effectively used? I looked into https://wiki.debian.org/MimeTypesSupport which points to https://www.debian.org/doc/debian-policy/ch-opersys.html and I didn't see anything that, for example, the Calibre maintainer could do to give it less priority than evince on PDF files. I see /etc/mailcap.order exists and is not used in my system, and it seems something made for the system administrator, while I'd expect control of ordering to be done by package developers for a default, and users for an override. With regards to FreeDesktop, I see that https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s10.html There should be no priority for MIME Types in this field, or any form of priority in the desktop file. Priority for applications is handled external to the .desktop files. And I found this issue, which is effectively the same user issue of mailcap on xdg-open: https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/43 and it sounds like still a work in progress. I guess the issue for xdg-open is mitigated by a better UI, where users who are surprised by the selected program can right click on it, choose "Open with..." and have the system remember the proper one from that point on. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: PGP signature
