GNOME Bugzilla – Bug 133085
I would like to be able to pipe the decoded file to
Last modified: 2018-09-21 15:51:03 UTC
I have some files in a couple of binary groups that are in jpeg2000 or bmp format for example. I would like to be able to pipe the decoded image to an external program like eeyes or jiv (jpeg2000 viewer). To my mind this would add quite a bit of flexablity in file handling... If I understand correctly the downloaded and unsaved article is already in cache. I had something in mind like "Pipe To External Command" and then having it ask me to enter the command and options for that I wanted it piped to. Now if it decoded it from uuendcode/yenc first that would be perfect <BG>. I know SLRN has this feature, cause thats how I print from it. (ie, I pass it to a2ps with what options I want.)
I could use this function. However, I'd suggest a bit different implementation, similar to what the "external editor" function does on a reply, only here "external viewer". This would be a single program, set in preferences or wherever, probably with a "%f" allowed for the file location, or defaulting to the end of the command if it wasn't present, thereby allowing only a single choice. However, that single choice could be an external script that would invoke the proper command for that sort of file, or a web browser or similar, equipped to deal with multiple file types and route them accordingly. Thus, there'd be as much flexibility as a user desired, but it wouldn't involve opening a dialog in pan each time. (The script or app a user selected could of course open a dialog, if that's how the user wished to deal with it, but it could be more automated than that if desired, as well.)
I could use this as well.
I submitted the request and would still use it.
I think we could merge some of Duncan's suggestion in with the original request by having a combobox-style history with the last few scripts/commands run. Duncan: I don't understand what you mean by handling multiples, though. Is that for when there's more than one image attached?
Combo-box would work. I wasn't referring to multiple files per message, tho there's that to consider as well. What I was referring to was the fact that if we implemented it as a single "external viewer", that normally, one application only works with a limited number of file types, say still images (bmp, png, gif, jpeg2000, etc), not movies (mpeg, avi, mov, etc) or sounds (wav, ogg, mp3, etc), or txt, or html or pdf or whatever. The original request would popup a dialog in which one would have to enter a command to pipe to (BTW, there's pipe and there's simply feeding it a tempfile path). That sort of solves the problem, but isn't very automated. Keeping a history in a combobox makes it a bit better, but is still rather manual. If instead we make it an external viewer (single entry in prefs or whatever), one could choose a single filetype viewer, or a general purpose app such as a browser that would presumably either handle the file itself, possibly with an appropriate plugin, or popup its own open dialog, or create a script to handle things in as customized a way as desired. If a user wanted to pipe the attachment to some app, he could do so via the script, with a popup dialog if desired or not. If instead she wanted to hand the app the the tempfile name, that could be arranged via the script as well. I really like the external viewer idea as I'd soon have a bash script doing exactly what I wanted, that I could customize as necessary. In fact, what I'd likely do is make it use an extension file (maybe mc compatible), so those without bash skills could simply change the extension file as necessary to associate whatever app they wanted with the various file extensions. I'd then post it to the user list. Others might create similar scripts or modify mine to use KDE's (I might do that too or instead) or GNOME's associations, or Firefox's mime config, or whatever, and these could be saved to a utils dir on pan.rebelbase and/or shipped in the source tarball as user installable options. However, a popup with a history would be fine as well. To me, it just doesn't quite fit the way a normally GUI app works, is all. A single external viewer prefs entry seems more in keeping with the way pan has done things before and with its GUI nature. However, that's just my opinion. Either solution would be fine (and used) here, and I can see how my external viewer solution, while more flexible, might be more challenging for those who don't do scripting at all, and who'd end up changing the entry every time they switched from the movie groups to the mp3 groups.
Maybe a quick configuration dialog that says: file extension path to application (Full path not needed if in $path) txt gedit jpg eog gif eog Possibly if the user opens a file that does not have an extension listed they could be prompted to create an association via a browse dialog? I know the file extension system isn't a Linux thing, is it possible that gmime can detect the file type and prompt maybe for an application to open type image/jpg?
gmime doesn't do that kind of mime :) it does the email MIME formatting stuff, not the content-type sniffing stuff. I know there exists some content-type (referred to as mime-type a lot of times) sniffing code in gnome-vfs, but you probably don't want to rely on that. There is movement to rewrite gnome-vfs and include it in glib tho... or gtk? so this may eventually be something pan could easily take advantage of.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pan/issues/9.