You are not logged in.
Well, now I tried using only mimeo on a fresh install but.. >.>
I created a zathura.desktop which worked fine, however, when I intended to --prefer zathura with pdfs i got the following:
[04:18:55 bugger ~]$mimeo --create zathura.desktop zathura "/usr/bin/zat %f" "application/pdf"
[04:19:43 bugger ~]$mimeo --prefer 'application/pdf' zathura.desktop
Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1782, in main
mimeo.update_defaults(added, removed)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1009, in update_defaults
os.makedirs(app_dir)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 17] File exists: '/home/bugger/.local/share/applications'
Judging from your last comment you possibly made it fail if the directory exists already and he can't create it? Or possibly I just suck and did something wrong xD
Offline
@demonicmaniac
I missed an "if it exists" statement when I copied and pasted the code from another section further up. It should be fixed now.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
mimeo --prefer 'application/pdf' kde4-okularApplication_pdf.desktop
This gives me .local/share/applications/defaults.list like this:-
[Default Applications]
application/pdf=kde4-okularApplication_pdf.desktop
but empty .local/share/applications/mimeinfo.cache. In any case, evince.desktop is still shown from -d
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
but empty .local/share/applications/mimeinfo.cache. In any case, evince.desktop is still shown from -d
Did you mean that it failed to update $XDG_DATA_HOME/share/applications/mimeinfo.cache, or that it emptied the file?
I'm assuming that you meant the former. I've added the equivalent of an automatic "--update" option to each option that changes associations, so the cache should be rebuilt automatically now.
Let me know if works as expected now (get it from my repo).
Last edited by Xyne (2011-03-10 22:29:22)
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
It did not update it, just created it, and emptied any manual changes I'd made.
Testing more, when I use mimeo --add to create my own okular.desktop that works fine. But I can't seem to get the okular.desktop installed by kdegraphics-okular to be used. Perhaps the problem is that its in /usr/share/applications/kde4/okular.desktop instead?
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
It did not update it, just created it, and emptied any manual changes I'd made.
Your wording isn't very clear, as the second part implies that the file already existed, i.e. that it was not created, only overwritten.
I assume that you had manually added associations for the desktop files in /usr/share/applications/kde and that mimeo removed them because it considered them invalid (because it couldn't find the matching desktop files).
I've updated mimeo to search subdirectories of the XDG_DATA_* directories, according to what I found in the GNOME Documentation Library. If someone determines that this is non-standard behavior, let me know and point me to the relevant specification so that I can fix it.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
ngoonee wrote:It did not update it, just created it, and emptied any manual changes I'd made.
Your wording isn't very clear, as the second part implies that the file already existed, i.e. that it was not created, only overwritten.
Sorry, was in a bit of a rush at the time. I tried multiple times. If I start with one I'd created myself, it would empty it. If I start without one, it would create an empty one.
I assume that you had manually added associations for the desktop files in /usr/share/applications/kde and that mimeo removed them because it considered them invalid (because it couldn't find the matching desktop files).
I've updated mimeo to search subdirectories of the XDG_DATA_* directories, according to what I found in the GNOME Documentation Library. If someone determines that this is non-standard behavior, let me know and point me to the relevant specification so that I can fix it.
Precisely, this works fine (but is not compatible with xdg-mime/xdg-open). What they do is specify the folder structure. Hence this is the filepath to the actual file:-
/usr/share/applications/kde4/okularApplication_pdf.desktop
And this is what appears in defaults.list
application/pdf=kde4-okularApplication_pdf.desktop
I'm not saying this should be followed, but I'm used to it in xdg-open/xdg-mime, and it MAY be a standard of some sort. I don't know, though (obviously).
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Hi Xyne, it could be beneficial to add support for file:// urls to mimeo. I'm not very familiar with python, so there may be room for improvements, but here is a working patch:
--- a/Mimeo.py
+++ b/Mimeo.py
@@ -35,6 +35,7 @@
from collections import OrderedDict
from pipes import quote
from sys import argv
+from urllib import unquote
import locale
@@ -737,6 +738,8 @@
else:
# Replace the normal error message with a more appropriate one.
error_msgs = list(self.error_msgs)
+ if re.match(r'^file://', arg):
+ arg = unquote(re.sub(r'^file://', '', arg))
desktop_name = self.get_associated_desktop_name_by_path(arg)
if desktop_name:
try:
edit: updated patch to make sure only file urls are unquoted
Last edited by xduugu (2011-03-11 21:21:58)
Offline
@ngoonee
I couldn't find a specification for subdirectory handling, but I assume that xdg-open follows it, wherever it may be, so I've updated mimeo to emulate its behavior. Let me know if there are further discrepancies that I need to resolve.
@xduugu
Good idea. I've implemented it using only a slightly different approach (with "urlparse"). It also let me to add support for URIs in general using the "x-scheme-handler/" MIME-type.
Thank you both for the feedback.
Supporting subdirectories required the propagation of many little changes, so I have probably introduced new bugs. I have also changed the output of some of the information operations (e.g. "-d", "-m"). The information should be more useful now, but any scripts that relied on the previous format will be broken.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
@xduugu
Good idea. I've implemented it using only a slightly different approach (with "urlparse"). It also let me to add support for URIs in general using the "x-scheme-handler/" MIME-type.
Thanks, looks good. Just one little thing: afaik the file uri needs to be url-unquoted for full support. I'm not sure how important this actually is, but it's probably better to fix it right away before someone complains about 'strange things' happening. Just check the uris in your browser to get an idea of the correct behaviour.
$ echo a > Desktop/'a b'
$ echo b > Desktop/'a%20b'
$ # opens the (wrong) file with the b in it
$ mimeo file:///home/xduugu/Desktop/a%20b
$ # does not find the file
$ mimeo file:///home/xduugu/Desktop/a%2520b
error: no associations or custom launchers found for "/home/xduugu/Desktop/a%2520b"
That's why I used urllib in my patch. Sorry for not making it clear.
Supporting subdirectories required the propagation of many little changes, so I have probably introduced new bugs.
I've just encountered a small one:
mimeo https://www.archlinux.org
Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2098, in main
for cmd in mimeo.get_cmds(args):
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 817, in get_cmds
if desktop[DEG]['Terminal']:
KeyError: 'Terminal'
Offline
I understand how percent-encoding works. I just assumed that "urlparse" would, well.... parse the URI, including the escapes. (Yeah, the documentation clearly states that it doesn't, but I missed that part.)
I've wrapped it in "unquote" now. I'm keeping "urlparse" to ensure that only the path of the URI is passed through. If query arguments and other parts of the URI are supposed to be handled they would need to be split off and dealt with separately.
*after checking handling of file URIs*
Hmmm, the urlparse module treats "file://" URIs differently from e.g. HTTP and HTTPS URIs. It doesn't fully split the URI. That only leaves the host to consider, and if that's included then the file probably shouldn't be queried on the local machine. I'm not really sure what the best way to handle that is (ignore it, fail, try to handle remove files). I'm open to suggestions.
I have also restructured that section of the code to pass through the file URI first to see if there are any dedicated applications for handling it (i.e. anything that supports "x-scheme-handler/file") before extracting the path.
The second error should also be fixed now.
Thanks again for the feedback.
Last edited by Xyne (2011-03-13 14:45:25)
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Thanks for unquoting the uris. Works fine.
Hmmm, the urlparse module treats "file://" URIs differently from e.g. HTTP and HTTPS URIs. It doesn't fully split the URI. That only leaves the host to consider, and if that's included then the file probably shouldn't be queried on the local machine. I'm not really sure what the best way to handle that is (ignore it, fail, try to handle remove files). I'm open to suggestions.
Something like 'mimeo file://localhost/home/xduugu/Desktop/a%20b' works for me, so I'm not sure what you mean.
The second error should also be fixed now.
Unfortunately not completely. I now get a new error:
$ mimeo https://www.archlinux.org
Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2101, in main
for cmd in mimeo.get_cmds(args):
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 815, in get_cmds
desktop[DEG]['Exec'] = cmd,
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1551, in __setitem__
raise TypeError("type must be 'str', not '%s'" % (value.__class__.__name__))
TypeError: type must be 'str', not 'tuple'
cmd is 'firefox %F' in line 815 in my case.
Offline
Something like 'mimeo file://localhost/home/xduugu/Desktop/a%20b' works for me, so I'm not sure what you mean.
In that file URI, the host is "localhost" and the path is "/home/xduugu/Desktop/a b". Using "urlparse", the path is extracted and everything else is ignored, and then the path is treated as though it's a local file path, which is correct in this case.
"file://foo/home/xduugu/Desktop/a%20b" might also be a valid file URI, but in that case it would specify the path "/home/xduugu/Desktop/a b" on host "foo", which could be another computer, and thus it would not be correct to search for "/home/xduugu/Desktop/a b" on the local computer.
Maybe file URIs aren't allowed to specify other hosts, but if they are then Mimeo should probably raise an exception instead of searching for local files, unless there is some standard way to support such requests, which I doubt.
The second error should be fixed now.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
xduugu wrote:Something like 'mimeo file://localhost/home/xduugu/Desktop/a%20b' works for me, so I'm not sure what you mean.
In that file URI, the host is "localhost" and the path is "/home/xduugu/Desktop/a b". Using "urlparse", the path is extracted and everything else is ignored, and then the path is treated as though it's a local file path, which is correct in this case.
"file://foo/home/xduugu/Desktop/a%20b" might also be a valid file URI, but in that case it would specify the path "/home/xduugu/Desktop/a b" on host "foo", which could be another computer, and thus it would not be correct to search for "/home/xduugu/Desktop/a b" on the local computer.
Maybe file URIs aren't allowed to specify other hosts, but if they are then Mimeo should probably raise an exception instead of searching for local files, unless there is some standard way to support such requests, which I doubt.
Ah, that's what you meant. Unfortunately, the file scheme does support remote hosts, but since their use is very limited and unusual I would just ignore the host part. For an error message you'd have to investigate all the host names of the local machine to check if the host actually is an remote host or not and that's too much overhead for little benefit in my opinion.
http://www.cs.tut.fi/~jkorpela/fileurl.html
ftp://ftp.funet.fi/pub/doc/rfc/rfc1738.txt
The second error should be fixed now.
Thanks. Much better now.
Offline
Getting a bunch of errors:
[~] mimeo --app2desk pidgin
Traceback (most recent call last):
File "/usr/bin/mimeo", line 5, in <module>
Mimeo.main()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 2087, in main
for desktop in mimeo.get_desktop_by_app(arg):
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 674, in get_desktop_by_app
desktop = self.load_desktop(fpath)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 567, in load_desktop
desktop.load()
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1713, in load
next_group_name = group.load(f)
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1592, in load
self[key] = value
File "/usr/lib/python2.7/site-packages/Mimeo.py", line 1528, in __setitem__
raise ValueError("expected 'true' or 'false', not '%s'" % (value))
ValueError: expected 'true' or 'false', not '0
Anything suggestions as to where I might start looking?
Offline
You have an invalid desktop file that is using '0' instead of an actual boolean value ("true" or "false") to set a field.
I've updated Mimeo to catch the error and display more information about invalid files. It should make it easy to track down the file and either correct it or remove it. If it belongs to a package, please inform the maintainer.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Hi Xyne, today a gvim update killed off my mime-type association for *.tex files. The reason is that the new gvim.desktop file has a vastly abbreviated MimeType list compared to previously. Here's the previous MimeType line:-
MimeType=application/mathml+xml;application/xhtml+xml;application/x-perl;application/x-python;application/x-shellscript;audio/x-mpegurl;audio/x-scpls;image/sv
g+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;tex
t/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-sou
rce;text/x-python;text/x-tcl;text/x-tex;text/x-vcalendar;text/x-vcard;text/x-xslfo;text/x-xslt;
And here's the current one:-
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Obviously, text/x-tex is not supported anymore by this desktop file. What can I do short of using mimeo --add to create my own desktop file?
EDIT: Sorry for the noise, the actual problem was somewhere else:- https://bugs.archlinux.org/task/25304 was just filed by me. The new gvim.desktop has Terminal=0 for some strange reason....
Last edited by ngoonee (2011-07-29 05:23:37)
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
I wanted to use mimeo to define chromium-browser as the default browser to open links from applications such as zim (requires xdg) or thunar-dropbox.
My mimeo.conf
/usr/bin/chromium-browser %U
^http://
^https://
My mimeapps.list
text/html=chromium-browser.desktop;
However, links are still not opened with chromium-browser. I use the binary version from aur.
No further settings are made. gvfs is uninstalled.
xdg-open http://google.com opens a new chromium window.
What to do?
Last edited by orschiro (2011-09-27 10:45:37)
Offline
@orschiro
Try the following:
mimeo --prefer 'glob:application/x-extension-*ht*' chromium-browser.desktop
mimeo --prefer 'glob:application/*htm*' chromium-browser.desktop
mimeo --prefer 'glob:text/*htm*' chromium-browser.desktop
mimeo --prefer 'glob:x-scheme-handler/*' chromium-browser.desktop
Here's the list of matched MIME-types on my system, all of which are associated with my default browser:
application/x-extension-html
application/x-extension-htm
application/x-extension-shtml
application/x-extension-xhtml
application/x-extension-xht
application/xhtml+xml
text/html
text/html
x-scheme-handler/chrome
x-scheme-handler/ftp
x-scheme-handler/https
x-scheme-handler/http
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
I appreciate your reply.
I run the mimeo commands above. My *.lists are as follows:
defaults.list
[Default Applications]
application/vnd.ms-htmlhelp=chromium-browser.desktop;
application/vnd.pwg-xhtml-print+xml=chromium-browser.desktop;
application/vnd.sealedmedia.softseal.html=chromium-browser.desktop;
application/xhtml+xml=chromium-browser.desktop;
application/xhtml-voice+xml=chromium-browser.desktop;
text/html=chromium-browser.desktop;
x-scheme-handler/http=chromium-browser.desktop;
x-scheme-handler/magnet=chromium-browser.desktop;
mimeapps.list
[Added Associations]
application/pdf=zathura.desktop;
application/vnd.ms-htmlhelp=chromium-browser.desktop;
application/vnd.pwg-xhtml-print+xml=chromium-browser.desktop;
application/vnd.sealedmedia.softseal.html=chromium-browser.desktop;
application/xhtml+xml=chromium-browser.desktop;
application/xhtml-voice+xml=chromium-browser.desktop;
image/jpeg=geeqie.desktop;
text/html=chromium-browser.desktop;
text/plain=gvim.desktop;
video/x-ms-asf=gnome-mplayer.desktop;
video/x-ms-wmv=gnome-mplayer.desktop;
video/x-msvideo=gnome-mplayer.desktop;
x-scheme-handler/http=chromium-browser.desktop;
x-scheme-handler/magnet=chromium-browser.desktop;
I tried again to open a link out of thunar-dropbox context menu and zim.
Taken zim as the example I want to open the link http://localhost:8080.
However, still nothing happens. On the other hand, opening a link in a skype chat works flawlessly and opens a chromium window as expected.
May it be a problem related to the bin version of chromium?
Regards
Last edited by orschiro (2011-09-30 00:29:50)
Offline
Check that Mimeo is correctly configured by trying to open a link directly with mimeo in a terminal.
It that doesn't work, then double-check the following:
* name of the Chromium desktop file
* the "Exec" key of the Chromium desktop file (is the path correct?)
Once mimeo works, check that your applications are using mimeo to try to open links etc (double-check the app settings). Run the apps in terminals and check the output when you try to open something. There should be an error message if it doesn't work.
I have never used it myself, but you can also try using xdg-utils-mimeo from the AUR.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Thanks for your help.
Eventually I figured out that it is a problem with Dropbox which has firefox hardcoded in the source code.
As for zim I was able to solve it by putting DE and BROWSER variable in .xinitrc.
Regards
Offline
Hi,
not sure if this is the right place to make a bug report..
If you have mimeo globally installed you don't want to use
#!/usr/bin/env python2
but
#!/usr/bin/python2
directly, because `env python2` points to another python version if you're in a virtual environment.
Cheers,
Daniel
Offline
@dakra
If that's the case then I will update it, but why would "env python2" not point to python2 in the virtual environment.
I admittedly don't use virtual environments, but shouldn't it be a compatible version?
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
"env python2" does point to the python2 in the virtual environment and that's exactly the problem, because in the virtualenv
I don't have mimeo installed, so when the mimeo script uses my python2 from my virtual env it can't find the python mimeo package
because it's installed in the global site-packages and NOT in my virtualenv.
So I get something like:
---
$ mimeo XXX.pdf
Traceback (most recent call last):
File "/usr/bin/mimeo", line 3, in <module>
import Mimeo
ImportError: No module named Mimeo
---
Hope it's clear what I meant now.
Thx,
Daniel
Offline