Talk:Default applications

From ArchWiki
Jump to: navigation, search

Futher improvement

Would be great to see such detailed explanation for KDE too. --AlexanderR 23:57, 22 January 2012 (EST)

It might be worth to mention that Enlightenment's file browser (in version e19) still uses the depreciated defaults.list file. --Drtebi (talk) 09:01, 25 December 2014 (UTC)

This can be placed in section "File managers" as a subsection for "Application launchers" (Andy Crowd - 蔡依林 14:16, 20 May 2016 (UTC)).

Output examples by tools

Almost for every output I use my lsdesktopf script or adding new functions to make need output, it feels like making of the useful advertisement. I am not sure if it is OK to write everywhere "See also:" "Use to show:" for my script that only shows everything to stdout or for other programs that manages mime-types in console and have some kind of output? (Andy Crowd - 蔡依林 21:27, 15 May 2016 (UTC)).

I see what you mean, your tool is very useful for complex searches. You can of course use a Template:Tip in a place where you think lfdesktopf is particularly handy for readers. Two further ideas: (1) You could change the second lsdesktopf example you provide in Desktop_entries#List_or_search_in_.2A.desktop_files for the tool to one that handling MIME-type information relevant here. (2) We still also have Xdg-open, which is more about tools to configure. It has Xdg-open#Usage examples about searching MIME type, which can be crosslinked as examples too.
Apart from a tip, I would not use much more examples for tools in this article at the current time. First, it should be decided what happens to Xdg-open. After Talk:Xdg-open#Move_suggestion and Talk:Xdg-open#About_Merge are clear, we should have a place where some more useful tool command examples (incl. mimeo and lsdesktopf) can be put.
Ok? --Indigo (talk) 16:43, 16 May 2016 (UTC)
I am done with the 1st advice. But in xdg-open replacements can be moved to Utilities to manage MIME types, but I must rewrite section "Utilities to manage MIME types" in style as table in "xdg-open replacements" for some tools that is not there yet, I can't provide so detailed info about missing yet. Other parts I haven't decided where I can put, but it can be minimized very much. (Andy Crowd - 蔡依林 19:56, 16 May 2016 (UTC)).
Alright, nice. I think it is simpler to convert all tools to Template:App, as suggested in the style template, and drop the table. --Indigo (talk) 18:34, 17 May 2016 (UTC)
I think that it is better with table because it is comparison of tools and not just description with a link as in Template:App. (Andy Crowd - 蔡依林 04:39, 18 May 2016 (UTC)).
Fair enough, I've merged into the table. --Indigo (talk) 12:06, 18 May 2016 (UTC)
After I will test all command line tools in table I will probably rewrite it in a table if I will find some bigger difference or similarity. Many programs are prioritizing *.xml instead of mimeapps*. It will be a big list of short examples for a while until I will short it down. And one more thing---- It is good to have a separator between examples but not section names, is it good if I will use bold text of tool names instead? (Andy Crowd - 蔡依林 16:17, 18 May 2016 (UTC)).
We can't have examples for too many different tools, so I think one example section and bold as separator is a good idea. By the way: Why do you use xdg-mine for the first examples in Default_applications#Examples_of_usage? If they are needed here, they should be crosslinked to Xdg-open#Configuration. --Indigo (talk) 19:05, 18 May 2016 (UTC)
I have edited table but it is so Ugly code inside, may be make new or it other was to make it look good. It might be also an alternative to have One More Table with Columns: Type(Launcher,Both,Setting,Incl. Tool),GUI(Yes,No),Prioritize Order(*.xml,file,other) (Andy Crowd - 蔡依林 18:13, 18 May 2016 (UTC)).
We can remake the table in simpler format. I can help, but not today. I also have to catch-up with all the great work you have already put into the article; I'll do that one of the next days.
The new columns "Type" and "GUI" read good. One question from me: What do you mean by prioritize order(*.xml,file,other)? To my understanding, the *.xml files are part of the packages and should not be user modified (see [1]). The new pacman hook does the automatic work for update-mime-database according to what the applications provide in the .xml specs. It is ok to mention the *.xml files, because they are part of the logic. However, to my understanding the configuration of the correct mimeapps.list should be the focus in his article, because this is where the user choice (app per mime type) is configured.
So, what do you mean by "prioritize" ? --Indigo (talk) 19:03, 18 May 2016 (UTC)
I have created an example table at the bottom that shows "prioritize order", *.xml = that it detects MIME-type by extension, Magic = if no description about extension is found in *.xml (Andy Crowd - 蔡依林 19:59, 18 May 2016 (UTC)).
I see and like how you are progressing with new ideas about the section and now also understand what you mean with "prioritize" (great you also adopted the archived AUR packages). The example you provide in [2] sounds like a xdg-mime bug to me actually - or was it a text that you renamed to foo-file.jpg to show the effect? Other than that I don't have more input at current. --Indigo (talk) 17:57, 19 May 2016 (UTC)

Just try examples with and without any extension or with wrong extension, if you have DE installed and necessary tools. I just added extension to "foo-file". (The discussion is too tight now so I start with a new begin.) (Andy Crowd - 蔡依林 18:07, 19 May 2016 (UTC)).

I think that I am done with all related to article name sections. I will not use many outputs per tool, only basic and little configuration.
  1. Default applications
    1. Description of what MIME-type is and ways Linux uses them.
    2. Set default applications
      1. Configure *.mimeapps.list files
      2. Configure *.xml files
      3. Use tools for configuration
    3. Get information about MIME-types
      1. in MIME-type database
      2. using tools
    4. Start default applications by
      1. using utilities
      2. configuring other applications to use tools for starting default applications
    5. Troubleshooting of *.desktop files if associated program doesn't start correct

(Andy Crowd - 蔡依林 13:52, 20 May 2016 (UTC)).

I went through the article until the Default_applications#Utilities_to_manage_MIME_types section, please have a look, thanks. I like your above TOC layout a lot. I have started to implement it in a similar manner ([3]) until the section I got today. --Indigo (talk) 18:00, 20 May 2016 (UTC)
You did great, but I didn't described completely when I used word "misconfiguration" in section "Variables in .desktop files that affect application launch", I meant that not all variables in "Exec" can be combined in the same *.desktop file or in the same "Exec"(in some *.desktop files I found more then one "Exec" that belongs to each new section that related to description in variable Actions, for each Action own Exec in the new section within same *.desktop file), e.g. to open file and to open device can't be in the same *.desktop file with "Exec" but standard changes so I didn't wrote about all details only that "misconfigured" Exec can affect start or be shown in the menu. For the section about tools I don't know what is good and how much I should write about each tool or in subsections, e.g. xdg-open may be need more details but article is not about xdg-utils but too much examples not good. May be it can be different between subsections (in one more examples and in another less or no examples, e.g. as it look like now). May be also add a section about file managers as in suggestion: Talk:Default_applications#Futher_improvement? Add information about GUI launchers that each DE is using? Add some "ERROR" template about that sections about tools is not complete and must be extended or something in that style (it is very messy in that part) because I think that it can take long time until it will be completed? I don't know how much time I will have to put on wiki but I will do my best to "finish"(until I have some ideas and time left) this article and also may be add some more info to Desktop entries. (Andy Crowd - 蔡依林 23:57, 20 May 2016 (UTC)).
Glad you are generally ok with my changes yesterday, if you see something wrong later - just change or tell me. Don't worry about time. The article is in a much better state already thanks to your expertise and careful work! If you want, you can also leave it to me to go over the Default applications#Utilities to manage MIME types section first, and see afterwards what of your ideas you want to implement as soon as you have time/want to work on it further.
For the "Variables in .desktop files that affect application launch" section: yes I think I understand. Perhaps one of us has an idea later how to improve it without mentioning too many exceptional cases, it is a complicated topic. I think it should stay in Troubleshooting though, like you put it above in the TOC.
For command output: I don't think we should mention much more about GUI tools/filemanagers of particular DE/WM. That should be left to the DE/WM (e.g. GNOME#Default applications, Xfce#Menu), so that this article can stay more general. For more see my reply below to Kynikos. --Indigo (talk) 12:15, 21 May 2016 (UTC)
As for he ToC structure, this freedesktop.org introduction mentions three layers involved in the association between MIME types and applications. The last sentence of the introduction says that the scope of this page is only the third layer, yet it tries to describe also the other two layers quite extensively. I have no problem with adjusting the scope according to the content, but the ToC should reflect how the layers build on each other, especially describing the lowest layer (i.e. the shared MIME database) in the middle of the article is a bad idea.
I can get involved more deeply than just criticising in a couple of days, so you can just wait for me...
-- Lahwaacz (talk) 11:27, 25 May 2016 (UTC)
I've adjusted scope with [4] for now. I think the order of layers we chose is ok, because most users will not have to care about the database. Either way round it is tricky anyway, because the middle layer is handled with desktop entries. Glad to wait for your input how to improve clarity further. --Indigo (talk) 14:09, 25 May 2016 (UTC)
Well, this took me much longer than I'd like to admit, but I finally have a draft: User:Lahwaacz/Default applications. What do you say about the structure and overall? However, I think it would be better to start a new section if there will be longer discussion... -- Lahwaacz (talk) 19:42, 1 August 2016 (UTC)
To be honest, as much as I've enjoyed getting a toe wet and learn about a subject new for me back in May; I've lost touch with the subject again. The others who contributed most to this subject should definetely be better for feedback on a new draft at this point. You may wait for that, open a new item for it (hard to see it in-tree here) or merge your changes. All fine with me. --Indigo (talk) 19:26, 2 August 2016 (UTC)
Alright, thank you for your reply anyway. I'll think of something in a couple of days, unless somebody replies first of course... -- Lahwaacz (talk) 19:36, 2 August 2016 (UTC)
I've outlined my gripes with the article through the templates I've added. Looking at the draft, it gradually solves the outlined issues so +1 from me. -- Alad (talk) 20:43, 2 August 2016 (UTC)

I haven't followed this discussion closely, but after merging xdg-open I do think that at least some examples from the xdg-open#Configuration section should be restored here, because for example the tables in Default_applications#Detect_MIME-type are quite informative, but at a glance it doesn't even look like they're talking about actual commands :) — Kynikos (talk) 09:37, 21 May 2016 (UTC)

Yes, we all agree on this I think (see Andy's above reply). I think for now it is pretty simple to add back more command output, because Andy had actually written a meaningful command example before. In my view it should suffice for now to add back the commands leading to the Default_applications#Detect_MIME-type tables for now and then see how it works out.
Btw, can you name a couple of specifics for the top-level style template you put? I'd like to fix them on the next go through. --Indigo (talk) 12:15, 21 May 2016 (UTC)
Is it OK to have a section with additional practical examples for other tools too as I started in Default applications#Extended practical examples, without any cryptic descriptions (instead Type/Extension use video/flv)? I don't see a better way of adding more examples without destroying logical layout of other sections. (Andy Crowd - 蔡依林 18:39, 21 May 2016 (UTC)).
Thanks Andy, your solution works for me.
@Indigo, I've fixed several formatting/punctuation non-compliances, however I've left the values in the tables almost untouched for the moment; in theory options and variables should all be shown with Template:ic, and I'm not sure under which Help:Style/Formatting and punctuation category we could consider MIME types to belong.
Kynikos (talk) 05:46, 22 May 2016 (UTC)
Thanks for fixing, Kynikos. It was actually my confusion when I used Template:ic for .desktop extension et al. When I did so, I recalled Lahwaacz had reminded me to something similar a good year ago, but got misled trying to find it again in the style guide ^^
For the MIME types: I don't think we can fix these 100%. I'd say they can be either properties or (e.g. for custom x-* ones) Help:Style/Formatting and punctuation#File content. So, monospace in my view when mentiioned in text, but I'd like to keep them normal text in the tables. --Indigo (talk) 11:43, 23 May 2016 (UTC)
I agree with using monospace for MIME types, and, as long as it's done consistently, I have no problems with keeping the tables in plain text :) — Kynikos (talk) 09:30, 24 May 2016 (UTC)

"Reason: The MIME database is located at"

Read here: [5]. "XDG MIME-type database" is in the /usr/share/mime but mimeinfo.cache is located in other folders and updates automatically after update or installation of new programs:
find /usr/ -type f -name "mimeinfo.cache"
/usr/local/share/applications/mimeinfo.cache
/usr/share/applications/mimeinfo.cache

(Andy Crowd - 蔡依林 17:05, 23 May 2016 (UTC)).

The section title is "Shared MIME-info database", there are two links to [6] and the update-mime-database.hook updates the database in /usr/share/mime/. The mimeinfo.cache files are different database handled by update-desktop-database.hook. Also, there is an incomplete sentence around the first link. -- Lahwaacz (talk) 17:26, 23 May 2016 (UTC)
Yes, you are right, it must be rewritten and corrected. (Andy Crowd - 蔡依林 22:21, 23 May 2016 (UTC)).
Thanks for the info, Changed and removed template with [7], please proof-read again. Closing. --Indigo (talk) 11:49, 24 May 2016 (UTC)
Well, the description of the "shared MIME-info database" and the "desktop file MIME type cache" are still all mixed up. I can do a rewrite in a few days, so I'll leave this open until then. -- Lahwaacz (talk) 11:14, 25 May 2016 (UTC)

Which application ends up being default "by default"?

Is there a rule for determining which application (.desktop file) is going to handle the mime type in the absence of any explicit config in mimeapps.list? -- Pmartycz (talk) 21:49, 15 November 2016 (UTC)

Yes, see the last paragraph in [8]. -- Lahwaacz (talk) 08:47, 16 November 2016 (UTC)
Well, it doesn't mention what happens when there is no default entry specified in any of mimeapps.list files. The other section states: In the absence of such an entry, the next mimeapps.list is checked. Once all levels have been checked, if no entry could be found, the implementations can pick any of the .desktop files associated with the mimetype. In other words, there is no way to tell which .desktop file is going to be picked as far as the standard is concerned. E.g. if you install a new audio player it might "hijack" associations from your favourite player unless you set an explicit mapping for every supported media type in mimeapps.list (and there are a lot of them for audio). -- Pmartycz (talk) 10:52, 16 November 2016 (UTC)
You are correct that there is no method specified by the standard. The default application in that case is implementation-specific. Silverhammermba (talk) 19:21, 16 November 2016 (UTC)