You are not logged in.
Hi everybody,
I was surfing and found that Vim can be run in server mode (similar to emacs, no flames please) So I set up a small script so I can run gVim like this from Nautilus, not too fancy but works for me.
#/bin/bash
SERVER=`gvim --serverlist`
if [ "$SERVER" == "" ]; then
`gvim --servername VIMSRV -p $@`
else
`gvim --servername $SERVER --remote-tab $@`
fi
Anyway, I trying to set up Nautilus to use this script when opening *any* text file. After googling, I found the default.list method, but it's not working. I edited the file, created an .desktop file pointing to my script, killed Nautilus, but it didn't work. Kept googling but everybody says this or manually change change the preferences for each filetype, which looks insane to me...
Anyone can help me with this?
Thanks in advance
masterLoki - Trying to understand the universe
Offline
Anyway, I trying to set up Nautilus to use this script when opening *any* text file. After googling, I found the default.list method, but it's not working. I edited the file, created an .desktop file pointing to my script, killed Nautilus, but it didn't work. Kept googling but everybody says this or manually change change the preferences for each filetype, which looks insane to me...
Anyone can help me with this?
Thanks in advance
Here are some things to check:
- Is your desktop file valid? You can verify with this command (I have a nautilus script that handles this via right-click for convenience):
desktop-file-validate <file.desktop>
- Does your desktop file contain the mime-types you're trying to associate under the file's 'MimeType=' option?
- Does your mimeapps.list file already contain references to the mime-types you are trying to associate with your script via the defaults.list file?
The references in mimeapps.list will override the contents of your defaults.list. The entries in the mimeapps.list file are automatically generated when you right-click on a file and change its association via the 'Nautilus Properties -> Open With' tab. So, you can either:
-- remove each association for the desired mime-types from mimeapps.list by using the Open With facility of Nautilus (tedious and this is part of what your post says you want to avoid);
-- manually open the mimeapps.list file and delete the relevant associations; or
-- similarly to the above but mimicking the behavior of auto-generated entries, cut the associations from the [Added Associations] section and paste them under the [Removed Associations] section.
- Does your defaults.list file contain all the mime-types you desire to associate with the script? There has to be an entry for each mime-type. For example, these are some of my defaults.list entries for Scite:
application/javascript=SciTE.desktop
application/rdf+xml=SciTE.desktop
application/x-lua=SciTE.desktop
application/xml=SciTE.desktop
application/x-perl=SciTE.desktop
application/x-shellscript=SciTE.desktop
text/html=SciTE.desktop
text/plain=SciTE.desktop
text/x-log=SciTE.desktop
text/x-patch=SciTE.desktop
text/x-python=SciTE.desktop
- Does your defaults.list point to the the real name of the desktop file? What Nautilus displays is not always the real underlying name of the file.
If you decide to further edit the files please make backup copies first.
It's just my opinion and how I do things, but once you decide to start using the defaults.list file, minimize your use of the 'Nautilus Properties -> Open With' facility as it will add more and more entries to the mimeapps.list. Because of the format of that file and because of the aforementioned fact that it overrides defaults.list, conflicts between the two files become harder to track down. It can be managed if you understand what files are doing what, so ultimately it's no big deal. And you can always just delete all the entries and start over.
Offline
Thanks MrWeatherbee, I began from the first solution you proposed and it worked, I had some errors on my .desktop file and now those are gone.
The script is now working with almost all kind of text files, but there are still some missing, like .c, .cs which are associated with gVim and MonoDevelop, but this is an easier issue to deal with.
The odd thing is that I'm using text/* as mimetype in default.list and .desktop files, and mimeapps.list doesn't have and association for those files. Any idea where might they be?
masterLoki - Trying to understand the universe
Offline
Thanks MrWeatherbee, I began from the first solution you proposed and it worked, I had some errors on my .desktop file and now those are gone.
The script is now working with almost all kind of text files, but there are still some missing, like .c, .cs which are associated with gVim and MonoDevelop, but this is an easier issue to deal with.
The odd thing is that I'm using text/* as mimetype in default.list and .desktop files, and mimeapps.list doesn't have and association for those files. Any idea where might they be?
Are you saying that you are literally using a single (wildcard) entry 'text/*' in the files or you are just using that as a placeholder in your post for a bunch of entries you didn't want to type out for sake of brevity?
If you are using a single wildcard entry in the actual files instead of using a separate entry for each desired type, that's a new one on me if it's working for you in any form or fashion. Based on my knowledge of how the mime-types system works, I wouldn't think it should work, so I never even attempted it until now. I just tried it out of curiosity, and I can't get it to work like that.
Anyway, skipping that part until further clarification from you, I'll introduce another file to the mix that is relevant to your question of where are default associations that aren't in defaults.list or mimeapps.list:
mimeinfo.cache
The mimeapps.list file only gets its entries when you change something via the Nautilus 'Open with' facility (when you change an association the first time via 'Open with', an entry is added to the [Added Associations] section of that file; change it again and the new entry is added to the [Added Associations] section and the old one is moved to the [Removed Associations] section). If you leave a mime-type to be opened with the 'default' application, no entry will be created in mimeapps.list. For example, if you install 'Geany', a desktop file will be added to '/usr/share/applications'. That desktop file will contain mime-types to be opened by Geany, but an entry for each of the mime-types specified in the desktop file will also be added to '/usr/share/applications/mimeinfo.cache'. For example, you might see this entry in mimeinfo.cache:
text/x-csrc=geany.desktop;gvim.desktop;someothereditor.desktop;
This is how Nautilus knows how to open files for which you have not specifically changed associations. The cache is culled from all the 'MimeTypes=' entries in the desktop files installed along with an application. If you manually add or edit a desktop file, and you need the entry added to the cache (this is especially important if you are not manually adding an entry to defaults.list), you run:
update-desktop-database
I'm not sure, but I believe (I have not tested explicitly) that as each application is installed and the cache is updated, the most recently installed application is placed at the front of the list where you see geany in the above example (there is at least one potential complication that I'll skip discussing). This is why you may find on occasion that associations you have become accustomed to have been changed / overridden. If you have explicitly changed an association via the 'Open with' facility (which means you have an auto-generated association in mimeapps.list) , or if you have an entry in the defaults.list, these arbitrary association re-assignments will not occur for these specific mime-type entries as mimeapps.list overrides defaults.list which overrides mimeinfo.cache.
I think. Maybe others have some added corrections or clarifications.
Offline
Are you saying that you are literally using a single (wildcard) entry 'text/*' in the files or you are just using that as a placeholder in your post for a bunch of entries you didn't want to type out for sake of brevity?
If you are using a single wildcard entry in the actual files instead of using a separate entry for each desired type, that's a new one on me if it's working for you in any form or fashion. Based on my knowledge of how the mime-types system works, I wouldn't think it should work, so I never even attempted it until now. I just tried it out of curiosity, and I can't get it to work like that.
Sorry for the long delay in answering, but it was one of those days....
Yes I'm using the wildcard in the actual files (.desktop file, default.list) and it did work well, now almost all files open with my script.
I already checked the mimeinfo.cache but there are no associations with text/x-csrc or any of the other files that won't open with my script. From this point it seems like I will have to associate the files manually.
But in the end, somehow, my question remains. GEdit is the default editor for //GNOME, but somehow it was changed for gVim? How did this happen?
Many thanks for the help!, it really saved me.
[------------------------------------------------------ ADDITIONAL NOTES ------------------------------------------------------]
Files used
rgvim.desktop
[Desktop Entry]
Encoding=UTF-8
Name=rgVim
Exec=/home/masterloki/scripts/remoteVim.sh
MimeType=text/*;
Type=Application
Icon=gVim
default.list
[Default Applications]
text/*=rgvim.desktop
application/vnd.nokia.xml.qt.resource=Nokia-QtCreator.desktop
application/vnd.nokia.qt.qmakeprofile=Nokia-QtCreator.desktop
text/x-c++hdr=Nokia-QtCreator.desktop
application/x-designer=Nokia-QtCreator.desktop
application/vnd.nokia.qt.creatorproject"=Nokia-QtCreator.desktop
text/x-xsrc=Nokia-QtCreator.desktop
application/pdf=evince.desktop
video/mp4=smplayer.desktop
text/x-c++src=Nokia-QtCreator.desktop
text/html=chromium-browser.desktop
Despite some source files associated with QtCreator, they're actually opened with gVim (but not from my script)
masterLoki - Trying to understand the universe
Offline
Yes I'm using the wildcard in the actual files (.desktop file, default.list) and it did work well, now almost all files open with my script.
Definitely doesn't work here.
I went so far as to remove all text-editor desktop files from system and local directories, created a desktop file per your notes** (and made it executable), modified the local defaults.list (added the text/* mime and removed all references to other text file associations), created the script per your notes (set as executable) and placed the script in /usr/local/bin. Additionally, just to be sure, I ran:
as user -
update-desktop-database
update-mime-database /home/user/.local/share/mime
as root -
update-desktop-database
update-mime-database /user/share/mime
I also rebooted and closed / refreshed Nautilus windows.
Here are the results:
1. Right clicking on appropriate files (txt, py, pl, log, etc.) shows that the association is not there ... only a generic 'Open' is available as opposed to 'Open with rgVim'.
2. Opening the file (double-clicking or choosing 'Open' from the context menu) produces an error dialog:
Could not display <file>. There is no application installed for <type> files.
Now, if I go back to the desktop file and defaults.list and change 'text/*' to 'text/plain', I get a nice 'Open with rgVim' upon right-click and opening the file works fine (I confirmed that it was actually the script launching the text editor by checking running processes just to be thorough).
** Notes:
- your desktop file indicates 'Icon=gVim'. If that works for you, I guess you have a custom icon with that name as the standard 'gVim' icon is named 'gvim' (lowercase 'v'). As it stands, on my system, 'Icon='gVim' just produces a placeholder icon.
- just FYI - if you create a desktop file without a file placeholder (%f, %U, etc.) in the 'Exec' option as you did (Exec=/home/masterloki/scripts/remoteVim.sh), the application (or script) will not show up in the list of applications under Nautilus Properties->Open with->Add application, though everything else may work fine. Changing to 'Exec=/home/masterloki/scripts/remoteVim.sh %U' is an example of what works.
I already checked the mimeinfo.cache but there are no associations with text/x-csrc or any of the other files that won't open with my script.
This also seems odd to me because the standard installation of gVim includes a desktop file with the following line in it:
MimeType=application/mathml+xml;application/xhtml+xml;application/x-perl;application/x-python;application/x-shellscript;audio/x-mpegurl;audio/x-scpls;image/svg+xml;message/news;message/rfc822;text/calendar;text/css;text/english;text/html;text/mrml;text/plain;text/rdf;text/rss;text/rtf;text/sgml;text/vnd.wap.wml;text/x-adasrc;text/x-bibtex;text/x-chdr;text/x-c++hdr;text/x-csrc;text/x-c++src;text/x-c;text/x-objc;text/x-csv;text/x-diff;text/x-java;text/x-katefilelist;text/x-latex;text/x-log;text/x-lyx;text/x-makefile;text/xmcd;text/xml;text/x-moc;text/x-mswinurl;text/x-objcsrc;text/x-pascal;text/x-perl;text/x-php;text/x-php-source;text/x-python;text/x-tcl;text/x-tex;text/x-vcalendar;text/x-vcard;text/x-xslfo;text/x-xslt;
Notice that 'text/x-csrc' is in the list of mimes for gVim. If it's there, it should be in mimeinfo.cache. After moving the gvim.desktop file back into /usr/share/applications (remember I had removed it and others for previous testing) and updating the mimeinfo.cache via:
su -c update-desktop-database
the following associations (among many others) appear in the file:
text/x-csrc=gvim.desktop
text/x-objcsrc=gvim.desktop
Are you sure you're using Gnome? Or maybe I'm not.
But in the end, somehow, my question remains. GEdit is the default editor for //GNOME, but somehow it was changed for gVim? How did this happen?
Remember this quote from my previous post:
... I believe (I have not tested explicitly) that as each application is installed and the cache is updated, the most recently installed application is placed at the front of the list where you see geany in the above example (there is at least one potential complication that I'll skip discussing). This is why you may find on occasion that associations you have become accustomed to have been changed / overridden. If you have explicitly changed an association via the 'Open with' facility (which means you have an auto-generated association in mimeapps.list) , or if you have an entry in the defaults.list, these arbitrary association re-assignments will not occur for these specific mime-type entries as mimeapps.list overrides defaults.list which overrides mimeinfo.cache.
The 'potential complication' I did not discuss previously (remark in above quote which is now (bold) emphasized) refers to my observation that if you have multiple 'conflicting' associations in the various files we've discussed, not only do the files have a hierarchy of precedence, but the associations within the files have a hierarchy: specific mime-types associated with applications override generic mime-types associated with applications.
For example, take a look again at the MimeType list from the gVim desktop file I posted above. Notice that it has a lot of very specific mime-types. Now, here is Gedit's MimeType entry in its desktop file:
MimeType=text/plain;
That's it. A single, generic entry. So along comes gVim, and it stomps on Gedit because although the types in gVim's mime list are also 'text/plain', they are very specific and thus override Gedit.
And to bring it all home, guess what happened to 'rgVim' when I put gVim's desktop file back in /usr/share/applications? It was overridden by gVim (in all expected cases) for the reasons described above since rgVim (on my system) had only a generic 'text/plain' mime-type associated with it. The generic mime-type does not compete with the specific.
Anyway, most of what I've written may have to be taken with a grain of salt because you seem to have some things going on that I cannot duplicate here.
Offline
guys, am I only supposed to add the defaults.list file in /usr/share/applications/ (and fill it with mime types) or do I have to do something else to make it work? for example I put this inside it application/x-php=gedit.desktop but gnome-commander still does not know how to open php scripts but instead throws the errror...
thank you
edit: my bad... I didn't put [Default Applications] at the begining of defaults.list, now it works
Last edited by pootzko (2010-08-25 18:19:03)
...I put on my robe and a wizard hat...
Offline