Re: Another problem about launching external applications
Eirik Byrkjeflot Anonsen <[email protected]> Fri, 19 Aug 2011 13:51:33 +0200
| Newsgroups | gmane.comp.web.opera.linux |
|---|---|
| Message-ID | <[email protected]> |
Ranousse <[email protected]> writes: > It seems that opera is able to read informations in > ~/.local/share/applications (desktop file) > and > ~/.mailcap > > I have in ~/.mailcap, > application/pdf; pdftotext '%s' -; needsterminal > > And in the download window (ctrl-j), if I right clic on a pdf, open with > propose pdftotext. What's strange is that it does not work. Could it be > possible that opera has a problem with the needsterminal information. I don't really know anything about this code, but I find it quite possible that we are missing some bits and pieces. It probably deserves a bug report. > Another strange thing is that there's in the menu the line > - false > I wonder if there could be a problem with > Terminal=false (in desktop file) > or > test=something (in .mailcap) That also sounds like worthy of a bug report. I think you probably could add the information to the same bug report as above. > Another problem. At the beginning I probably made a mistake. > I had a .ram file (playlist file containing a .rm url). > With my wrong configuration > xdg-open file.ram open the file with vi and for a reason I don't know > yet, xdg-open file.ram works in a terminal but not without terminal > (although I used needs terminal, but it's not opera's problem) > The problem is that when I ask opera to open the file with this wrong > xdg-open application, opera freeze and the only to close it seems to be > kill -9 (the -9 is necessary). Even if I made a mistake forgetting > needsterminal somewhere, it would probably be better that opera handles > this case without crashing. Opera usually catches many signals (e.g. SIGTERM and SIGINT) so it can shut down gracefully. Unfortunately, when opera is frozen, it obviously does not shut down, gracefully or otherwise. So that's probably why you needed to SIGKILL. But opera shouldn't freeze like that. Please file a bug report. Ranousse <[email protected]> writes: > And here's another thing I don't understand > I have in operaprefs.ini > audio/mp3=7,xterm -e mplayer,,,mp3,| > and > audio/x-mpegurl=7,xterm -e mplayer -playlist,,,m3u,| > > This means open with xterm -e mplayer [-playlist] and pass directly the > url to the applications (7). > When I clic on a mp3 file it opens a dialog box asking if I want to > download the file or open it or .... If I choose open, the file is > opened with the correct application, and the url is passed directly to > the application (good) > When I clic on a m3u playlist opera does the same thing except that it > opens the file without showing the dialog box. > > Obviously it's not linked with -playlist word. I also tried with other > filetypes avi, ... > video/x-msvideo=7,xterm -e mplayer,,,avi,| > and obtains the same result as with m3u. > > Why is there a difference only with mp3 files? > In fact I prefer the way mp3 files are handled here. That sounds really odd. Maybe there is another entry that matches the mp3 file? If you change 'xterm -e mplayer' to 'xterm -hold -e echo', do you get an xterm showing the url? eirik -- Opera-Linux: https://list.opera.com/mailman/listinfo/opera-linux More lists: https://list.opera.com/mailman/listinfo/ Unsubscribe: mailto:[email protected]?subject=unsubscribe