Hi, Sorry to ask something perhaps really dumb, but when I click on some links, eg a pdf file, I get prompted to save the file. Is it possible for me to transfer the file to some external program (say /usr/bin/epdfview) to open after download? Does this have to programmed in somewhere? Where? As a dpi? If the latter, where are the instructions? I looked at hello.c for an example but I was no sure what to do with the C program. Where do i compile it and how? Thanks for the help! Best wishes, T
Globe Trotter wrote:
Sorry to ask something perhaps really dumb, but when I click on some links, eg a pdf file, I get prompted to save the file. Is it possible for me to transfer the file to some external program (say /usr/bin/epdfview) to open after download? Does this have to programmed in somewhere? Where? As a dpi? If the latter, where are the instructions?
I think that the DPI interface is perhaps overly complicated for the common case where we just want to save the data to a temporary file and point some external program at it. Perhaps the config could specify a map from MIME types to helper functions, eg: application/pdf = epdfview %s Thoughts? Regards, Jeremy Henty
On Wed, 14 Sep 2011 15:41:48 -0400, Jeremy Henty <onepoint at starurchin.org> wrote:
Globe Trotter wrote:
Sorry to ask something perhaps really dumb, but when I click on some links, eg a pdf file, I get prompted to save the file. Is it possible for me to transfer the file to some external program (say /usr/bin/epdfview) to open after download? Does this have to programmed in somewhere? Where? As a dpi? If the latter, where are the instructions?
I think that the DPI interface is perhaps overly complicated for the common case where we just want to save the data to a temporary file and point some external program at it. Perhaps the config could specify a map from MIME types to helper functions, eg:
application/pdf = epdfview %s
Thoughts?
Regards,
Jeremy Henty
Seconded. The DPI itself is just an external program anyway, so we may as well cut out the middleman. ~Benjamin
--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Wednesday, September 14, 2011, 4:18 PM On Wed, 14 Sep 2011 15:41:48 -0400, Jeremy Henty <onepoint at starurchin.org>?
wrote:
Globe Trotter wrote:
Sorry to ask something perhaps really dumb, but when I click on some links,? eg a? pdf? file, I? get prompted? to? save the? file. Is? it possible for me? to transfer the file to? some external program (say /usr/bin/epdfview)? to? open? after? download?? Does? this? have? to programmed in somewhere?? Where? As a dpi? If? the latter, where are the instructions?
I think that? the DPI interface is perhaps? overly complicated for the common case? where we just want to? save the data to? a temporary file and? point some? external program? at? it.? Perhaps? the config? could specify a map from MIME types to helper functions, eg:
? ???application/pdf = epdfview %s
Thoughts?
Regards,
Jeremy Henty
Seconded.? The DPI itself is just an external program anyway, so we may as? well cut out the middleman.
Is this something that is easily done? If so, where? Many thanks!
On Wed, 14 Sep 2011 17:50:06 -0400, Globe Trotter <itsme_410 at yahoo.com> wrote:
Is this something that is easily done? If so, where?
Many thanks!
It's not in Dillo yet -- it's something we'd have to code and add in. But it wouldn't be too hard to do. In the meantime, you can just download the file normally and open it from your computer; it's a little less convenient, but that at least should work for now. ~Benjamin
--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Wednesday, September 14, 2011, 6:07 PM On Wed, 14 Sep 2011 17:50:06 -0400, Globe Trotter <itsme_410 at yahoo.com> wrote:
Is this something that is easily done? If so, where?
Many thanks!
It's not in Dillo yet -- it's something we'd have to code and add in.? But it wouldn't be too hard to do.
In the meantime, you can just download the file normally and open it from your computer; it's a little less convenient, but that at least should work for now.
Yes, of course! But it would be nice to have this little feature because that would make it easier to use dillo for routine things. I have been trying to adopt it increasingly, despite the absence of frames, and I find this to be somewhat disconcerting. My minor annoyance at this minor lack of feature aside, thanks for all your hard work!! Best wishes, T
On Wed, Sep 14, 2011 at 03:37:22PM -0700, Globe Trotter wrote:
--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Wednesday, September 14, 2011, 6:07 PM On Wed, 14 Sep 2011 17:50:06 -0400, Globe Trotter <itsme_410 at yahoo.com> wrote:
Is this something that is easily done? If so, where?
Many thanks!
It's not in Dillo yet -- it's something we'd have to code and add in.? But it wouldn't be too hard to do.
In the meantime, you can just download the file normally and open it from your computer; it's a little less convenient, but that at least should work for now.
Yes, of course! But it would be nice to have this little feature because that would make it easier to use dillo for routine things. I have been trying to adopt it increasingly, despite the absence of frames, and I find this to be somewhat disconcerting.
On the flip, I just love accidentally clicking on a link/URL within Google thinking it's going to spawn a new tab with an HTML page, only to find-out acroread or epdfview trying to start on my short-of-resources computers. Half the time, it's nice to see Seamonkey automatically open PDF's, other times, it's a pain because I can't do anything until the resource hog applications complete after their execution process. (Oh, including the wait for download because I thought it was an HTML page.) Seems the only middle-of-the-road solution for me, disable the auto-open feature for PDF files and use Google "view as HTML" links (if my eye catches them!). As far as opening other file types such as text/diffs/patches/any_thing_else_you_can_think_of, etc., I'm all for it. -- Roger http://rogerx.freeshell.org/
On Wed, 14 Sep 2011 20:11:14 -0400, Roger <rogerx.oss at gmail.com> wrote:
On the flip, I just love accidentally clicking on a link/URL within Google thinking it's going to spawn a new tab with an HTML page, only to find-out acroread or epdfview trying to start on my short-of-resources computers.
Half the time, it's nice to see Seamonkey automatically open PDF's, other times, it's a pain because I can't do anything until the resource hog applications complete after their execution process. (Oh, including the wait for download because I thought it was an HTML page.)
Seems the only middle-of-the-road solution for me, disable the auto-open feature for PDF files and use Google "view as HTML" links (if my eye catches them!).
As far as opening other file types such as text/diffs/patches/any_thing_else_you_can_think_of, etc., I'm all for it.
Easy solution: ask the user whether to open the file, or just save it to disk. ~Benjamin
--- On Wed, 9/14/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Wednesday, September 14, 2011, 8:16 PM On Wed, 14 Sep 2011 20:11:14 -0400, Roger <rogerx.oss at gmail.com> wrote:
On the flip, I just love accidentally clicking on a link/URL within Google thinking it's going to spawn a new tab with an HTML page, only to find-out acroread or epdfview trying to start on my short-of-resources computers.
Half the time, it's nice to see Seamonkey automatically open PDF's, other times, it's a pain because I can't do anything until the resource hog applications complete after their execution process.? (Oh, including the wait for download because I thought it was an HTML page.)
Seems the only middle-of-the-road solution for me, disable the auto-open feature for PDF files and use Google "view as HTML" links (if my eye catches them!).
As far as opening other file types such as text/diffs/patches/any_thing_else_you_can_think_of, etc., I'm all for it.
Easy solution: ask the user whether to open the file, or just save it to disk.
I agree. I also agree with the Roger about the pain caused by things just opening up on their own with major action required to stop it...... T
On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin Johnson wrote: On Wed, 14 Sep 2011 20:11:14 -0400, Roger <rogerx.oss at gmail.com> wrote:
times, it's a pain because I can't do anything until the resource hog applications complete after their execution process. (Oh, including the wait for download because I thought it was an HTML page.)
Seems the only middle-of-the-road solution for me, disable the auto-open feature for PDF files and use Google "view as HTML" links (if my eye catches them!).
Easy solution: ask the user whether to open the file, or just save it to disk.
So, the prompt saves my butt 5% of the time, the other 95% of the time I'm harassed by a prompt like in Windows. IMO, configuring for the fewest clicks possible is best. And like you said, provide a file with an option to to link in external apps if the user so wishes. (ie mutt's $HOME/.mutt/mailcap is a good example) Keeping a file type pointing to null or commented, gets default (download) action? I didn't want to say much more without being able to help code it, but I don't want to see another prompt popping-up. (ie. Dillo quit prompt) :-/ -- Roger http://rogerx.freeshell.org/
On Wed, 14 Sep 2011 23:34:33 -0400, Roger <rogerx.oss at gmail.com> wrote:
On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin Johnson wrote:
Easy solution: ask the user whether to open the file, or just save it to disk.
So, the prompt saves my butt 5% of the time, the other 95% of the time I'm harassed by a prompt like in Windows.
IMO, configuring for the fewest clicks possible is best. And like you said, provide a file with an option to to link in external apps if the user so wishes. (ie mutt's $HOME/.mutt/mailcap is a good example)
Keeping a file type pointing to null or commented, gets default (download) action?
I didn't want to say much more without being able to help code it, but I don't want to see another prompt popping-up. (ie. Dillo quit prompt) :-/
Then add a "Remember this choice" option so it won't prompt you again. I disagree that all prompts are automatically bad. After a while they do get annoying (and there should be some way to disable them), but for new users the verbosity can be helpful. More importantly, it avoids surprising the user when the program doesn't behave as expected -- it opens instead of downloads, or vice-versa -- and of course, different users will have different expectations for which behavior is "correct." (In my own software, I always err on the side of verbosity, no matter how annoying it is to me personally -- because as the developer, I know how to disable it on my own machine!) ~Benjamin
--- On Thu, 9/15/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Thursday, September 15, 2011, 1:21 PM On Wed, 14 Sep 2011 23:34:33 -0400, Roger <rogerx.oss at gmail.com> wrote:
On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin Johnson wrote:
Easy solution: ask the user whether to open the file, or just save it to disk.
So, the prompt saves my butt 5% of the time, the other 95% of the time I'm harassed by a prompt like in Windows.
IMO, configuring for the fewest clicks possible is best.? And like you said, provide a file with an option to to link in external apps if the user so wishes.? (ie mutt's $HOME/.mutt/mailcap is a good example)
Keeping a file type pointing to null or commented, gets default (download) action?
I didn't want to say much more without being able to help code it, but I don't want to see another prompt popping-up. (ie. Dillo quit prompt) :-/
Then add a "Remember this choice" option so it won't prompt you again.
I disagree that all prompts are automatically bad.? After a while they do get annoying (and there should be some way to disable them), but for new users the verbosity can be helpful.? More importantly, it avoids surprising the user when the program doesn't behave as expected -- it opens instead of downloads, or vice-versa -- and of course, different users will have different expectations for which behavior is "correct."
(In my own software, I always err on the side of verbosity, no matter how annoying it is to me personally -- because as the developer, I know how to disable it on my own machine!)
Is it possible to get either option (or both) into dillo3? Best!
--- On Thu, 9/15/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Thursday, September 15, 2011, 1:21 PM On Wed, 14 Sep 2011 23:34:33 -0400, Roger <rogerx.oss at gmail.com> wrote:
On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin Johnson wrote:
Easy solution: ask the user whether to open the file, or just save it to disk.
So, the prompt saves my butt 5% of the time, the other 95% of the time I'm harassed by a prompt like in Windows.
IMO, configuring for the fewest clicks possible is best.? And like you said, provide a file with an option to to link in external apps if the user so wishes.? (ie mutt's $HOME/.mutt/mailcap is a good example)
Keeping a file type pointing to null or commented, gets default (download) action?
I didn't want to say much more without being able to help code it, but I don't want to see another prompt popping-up. (ie. Dillo quit prompt) :-/
Then add a "Remember this choice" option so it won't prompt you again.
I disagree that all prompts are automatically bad.? After a while they do get annoying (and there should be some way to disable them), but for new users the verbosity can be helpful.? More importantly, it avoids surprising the user when the program doesn't behave as expected -- it opens instead of downloads, or vice-versa -- and of course, different users will have different expectations for which behavior is "correct."
(In my own software, I always err on the side of verbosity, no matter how annoying it is to me personally -- because as the developer, I know how to disable it on my own machine!)
~Benjamin
_______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Is it possible to consider providing the option on how to open links, etc.....i don't mind having it in some preferences file....i understand it may be some work, but this would certainly be very useful to have....? thanks very much!!
On Wed, Sep 14, 2011 at 07:34:33PM -0800, Roger wrote
Easy solution: ask the user whether to open the file, or just save it to disk.
So, the prompt saves my butt 5% of the time, the other 95% of the time I'm harassed by a prompt like in Windows.
IMO, configuring for the fewest clicks possible is best. And like you said, provide a file with an option to to link in external apps if the user so wishes. (ie mutt's $HOME/.mutt/mailcap is a good example)
Keeping a file type pointing to null or commented, gets default (download) action?
Can we have 3 options? 1) The "out-of-the-box" default is to ask what to do 2) Save to disk 3) Specify a helper application. Allow to specify parameters as required. And for number 3; puhleeeese don't "pull a Firefox" by de-referencing symlinks. For instance... $ ll /usr/bin/abiword lrwxrwxrwx 1 root root 11 Sep 3 02:53 /usr/bin/abiword -> abiword-2.8 When you tell Firefox to use abiword for *.doc files, it de-references the symlink and uses /usr/bin/abiword-2.8. So a few weeks from now, an update upgrades me to abiword-2.9 and Firefox whines about not being able to find /usr/bin/abiword-2.8 when I click on a link to a *.doc file. See also https://bugzilla.mozilla.org/show_bug.cgi?id=176486 Warning, some strong language from annoyed users. See especially comments 46, 47, and 48. -- Walter Dnes <waltdnes at waltdnes.org>
On Sun, 18 Sep 2011 00:48:37 -0400, Walter Dnes <waltdnes at waltdnes.org> wrote:
Can we have 3 options? 1) The "out-of-the-box" default is to ask what to do 2) Save to disk 3) Specify a helper application. Allow to specify parameters as required.
That's exactly what I was thinking. Good; that probably means neither of us is crazy. (Or else we're *both* crazy, but at least neither of us is crazy alone!)
And for number 3; puhleeeese don't "pull a Firefox" by de-referencing symlinks. For instance...
$ ll /usr/bin/abiword lrwxrwxrwx 1 root root 11 Sep 3 02:53 /usr/bin/abiword -> abiword-2.8
When you tell Firefox to use abiword for *.doc files, it de-references the symlink and uses /usr/bin/abiword-2.8. So a few weeks from now, an update upgrades me to abiword-2.9 and Firefox whines about not being able to find /usr/bin/abiword-2.8 when I click on a link to a *.doc file. See also https://bugzilla.mozilla.org/show_bug.cgi?id=176486 Warning, some strong language from annoyed users. See especially comments 46, 47, and 48.
What's the point of dereferencing symlinks, anyway? Symlinks in /usr/bin are usually there for a reason, and dereferencing them would actually take *more* code than not. I'm tempted to fire up my Unix machine and just start coding now... and yes, I do keep an OpenBSD install and unpatched mainline sources handy, in case anyone thinks I only code for the one platform :-) ~Benjamin
--- On Sun, 9/18/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote:
From: Benjamin Johnson <obeythepenguin at gmail.com> Subject: Re: [Dillo-dev] how to open links etc To: dillo-dev at dillo.org Date: Sunday, September 18, 2011, 10:05 AM On Sun, 18 Sep 2011 00:48:37 -0400, Walter Dnes <waltdnes at waltdnes.org> wrote:
???Can we have 3 options? 1) The "out-of-the-box" default is to ask what to do 2) Save to disk 3) Specify a helper application.? Allow to specify parameters as required.
That's exactly what I was thinking.? Good; that probably means neither of us is crazy.? (Or else we're *both* crazy, but at least neither of us is crazy alone!)
???And for number 3; puhleeeese don't "pull a Firefox" by de-referencing symlinks.? For instance...
$ ll /usr/bin/abiword lrwxrwxrwx 1 root root 11 Sep? 3 02:53 /usr/bin/abiword -> abiword-2.8
???When you tell Firefox to use abiword for *.doc files, it de-references the symlink and uses /usr/bin/abiword-2.8.? So a few weeks from now, an update upgrades me to abiword-2.9 and Firefox whines about not being able to find /usr/bin/abiword-2.8 when I click on a link to a *.doc file.? See also https://bugzilla.mozilla.org/show_bug.cgi?id=176486 Warning, some strong language from annoyed users.? See especially comments 46, 47, and 48.
What's the point of dereferencing symlinks, anyway?? Symlinks in /usr/bin are usually there for a reason, and dereferencing them would actually take *more* code than not.
I'm tempted to fire up my Unix machine and just start coding now... and yes, I do keep an OpenBSD install and unpatched mainline sources handy, in case anyone thinks I only code for the one platform :-)
Great!! Let me encourage you, Benjamin!! This will, of course, be a great help! Best wishes. T
Benjamin wrote:
On Wed, 14 Sep 2011 15:41:48 -0400, Jeremy Henty wrote:
Globe Trotter wrote:
Sorry to ask something perhaps really dumb, but when I click on some links, eg a pdf file, I get prompted to save the file. Is it possible for me to transfer the file to some external program (say /usr/bin/epdfview) to open after download? Does this have to programmed in somewhere? Where? As a dpi? If the latter, where are the instructions?
I think that the DPI interface is perhaps overly complicated for the common case where we just want to save the data to a temporary file and point some external program at it. Perhaps the config could specify a map from MIME types to helper functions, eg:
application/pdf = epdfview %s
Seconded. The DPI itself is just an external program anyway, so we may as well cut out the middleman.
I, for one, am at least open to this in principle, for what that's worth.
participants (6)
-
corvid＠lavabit.com -
itsme_410＠yahoo.com -
obeythepenguin＠gmail.com -
onepoint＠starurchin.org -
rogerx.oss＠gmail.com -
waltdnes＠waltdnes.org