KDE-Forum.org

In the settings of konqueor (or in KControl) you can see the filetype associations, that is, the programs that handle each filetype. I don't know the exact submenu but its there. You just need to add a new one called
[code:1]application/x-bittorrent[/code:1]
and set it to open the torrent gui (browse and find it).

I think if you open a torrent for the first time you can choose and application and select "remember association" (or something). The problem with this is that it probablly wont work when downloading from a site.

(sorry for being so vague but i'm using WinXP at the moment)
(relax I'm just trying to install Suse and messed up the MBR :oops

my guess is, that the webserver sends the file using application/octet-stream as its MIME type.
Usually there is not application assoicated with application/octet-stream because it can be anything.

You could try to fetch the URL with wget in a shell.
It says which MIME type it received.

Cheers,
_

Quoted

Original von Rinse

Quoted

Original von anda_skoa

my guess is, that the webserver sends the file using application/octet-stream as its MIME type.
Usually there is not application assoicated with application/octet-stream because it can be anything.

Ok, so i should fill in a wishlist for Konqueror to also check the file extension when there is no application available for the mime type that the webserver is sending.

At least on application/octet-stream

Quoted

This also explains why Konqueror tries to open mpg-files in kwrite on some websites :?

No, this case is different.
The webserver is sending the wrong MIME type: text/plain while video/mpeg would have been correct

If a source is capable of delivering metadata such as the MIME type, it always overrules guessing.
But I agree that application/octect-stream should be treated as if the source wasn't able do deliver a MIME type.

Cheers,
_

Quoted

Original von Rinse


Yep, but other browser open the link in mplayer or another associated mediaplayer. I know that the webdeveloper is to blame, but from a user perspective, it doen't make sence that he/she can't open the link..

Well, it would be a one-minute fix for the webdeveloper but a workaround will take a lot more time and still be just a workaround.

Quoted

Technicly, this is correct, but for users it is odd that Konqueror tries to open the movie in kwrite, and that they have no way to correct this.

I think "open with" is always an option in the context menu.

Quoted

So my opinion is that konqueror should either check the file extension before the mime type from the server, or present a dialog where the user can change the applcation Konqueror tries to open the file with..

Both things would be annoying.
The first suggestion would have any URL ending in php open in a text editor.
The second suggestion would mean Konqueror would popup a dialog on every click.

One would need another option in KDE's file association settings to allow MIME type override by extension for certain types.

If this is really imortant to you, you should file a wish report on bugs.kde.org.
I am just afraid it is too late for 3.2

A mail to the content provider might get faster results

Cheers,
_

Quoted

Original von Rinse

Trouble is that only Konqueror has this problem. Other browsers, like opera, simply open the link with the associated application, based on the extension, and not based on the mime type that the server is sending..

Yes, and that can be a nightmare. I had a lot of fun with different versions of IE (5.0, 5.5 and 6.0),
Mozilla and Konqueror that all behaved differently in this respect.

I wanted to create a dynamic download page in PHP for different document types.

To make *all* browsers happy at the same time I had to send the correct
Content-Type header (of course), but the link had to be of the form:
http://myemployer.com/xyz/dl.php/docname.pdf?docid=myid&dummy=dummy.pdf

Some browsers looked at the Content-Type header (which is correct IMHO),
some at the extension of the "file name"
(which was manipulated by me because the real file name was dl.php in this example),
and one crappy version of IE even looked at the "extension" at the end
of the request URI(!) (and this behaviour only showed if
the request URI's length exceeded a certain number
of characters. Seems to me like a bug.).
What's even worse, IE's behaviour depended on the
type of the document itself. A URL that worked for .doc
didn't work for .pdf!

File extension magic is evil.


Back to KDE and konqi:
I think anda_skoa's proposal of ignoring certain mime-types (application/octet-stream, ...)
if set as Content-Type header and then falling back to other means makes a lot of sense.

I'd also like to be able to treat a link as a certain
mime type, e.g. an entry "open URL, overriding
mime-type" in the context menu that shows when you right click a link.
This could pop up a selector where the user could select the mime type
he wants the resource at the URL to be treated as
(this one time only, it should be only temporary).

Quoted

Original von Rinse


[code:1]
======================================================
= Would you like to open file.mpg with kwrite? =
= =
= [open] [save to disk] [open with other application]=
======================================================
[/code:1]

Ok, but that would only work with content that isn't
displayed inline. That box wouldn't pop up.

Quoted

Original von Rinse

Correct.
Is there also a problem with inline links?

Rinse

No, not really a problem. It's more like a feature request.

In Konqi, I'd like to be be able to say:
I want to open *this* link or element in the
configured external viewer for jpegs (although image/jpeg
is configured to be displayed inline).
Or:
I want to open *this* link or element in program xxx
(although image/jpeg is configured to be displayed inline by app yyy).

Having that possibility would also provide you with a tool
to circumvent problems from an incorrect HTTP header.

Not sure if this would be end-user compatible, though...
Does Jane Doe even know what a mime type is?
She wouldn't ever use it.
Think also "menu clutter".

Personally, in such cases I'd go for a keyboard shortcut
because that doesn't get in the way of regular users,
but this feature is context-sensitive so that wouldn't
work well.

Maybe Shift-Click plus your enhanced Save-As box would do the trick.

Quoted

Original von Rinse

Correct.
Is there also a problem with inline links?

Rinse

Ooops, I guess I'm not making much sense here.
There already *is* the "open with" option in the
context menu.

I got confused by the context menu you get
when you're hovering over an image. In order
to open the *image* in an arbitrary app you have
to select "view image" first and then "open with".
Otherwise you'd open the enclosing HTML in the
image viewing app.

OTOH, if you're hovering over a link you'll open
the *link location* when selecting "open with".
I find that somewhat inconsistent...

Quoted

Original von cmbofh


In Konqi, I'd like to be be able to say:
I want to open *this* link or element in the
configured external viewer for jpegs (although image/jpeg
is configured to be displayed inline).
Or:
I want to open *this* link or element in program xxx
(although image/jpeg is configured to be displayed inline by app yyy).

Open With is always part of the context menu IIRC

Quoted

Maybe Shift-Click plus your enhanced Save-As box would do the trick.

The problem with the dialog is, that it doesn't make sense in all applications.

Keep in mind that Konqueror is not only a web browser using its own IO subsystem, but a very versatile viewing-application using KIO.
The user and the system have to be sure that an URL is treated equally by all KIO using applications.

This is one of the main problems on Windows. One program determines a MIME type for an URL or an attachment and thinks its save (image/jpeg) and then tells Windows to open it.
Windows performs a different check and sees that it is in fact an executable and executes it -> security breach.

Cheers,
_

Quoted

Original von anda_skoa

Open With is always part of the context menu IIRC

Yes, you're right. I already noticed myself:
http://www.kde-forum.org/viewtopic.php?p=4956#4956

Thanks.

Quoted

Original von anda_skoa

Quoted

Maybe Shift-Click plus your enhanced Save-As box would do the trick.

The problem with the dialog is, that it doesn't make sense in all applications.

Keep in mind that Konqueror is not only a web browser using its own IO subsystem, but a very versatile viewing-application using KIO.
The user and the system have to be sure that an URL is treated equally by all KIO using applications.

This is one of the main problems on Windows. One program determines a MIME type for an URL or an attachment and thinks its save (image/jpeg) and then tells Windows to open it.
Windows performs a different check and sees that it is in fact an executable and executes it -> security breach.

I read about those problems with the content-type mismatch
as a form of attack on Windows.

But would this be a problem here? The user is asked whether he wants
to open it with the configured app or one that he chooses.
Isn't this *less* automatism, the opposite of what happended on Windows?

Quoted

Original von Rinse

Yep, got trapped by that one on more then one occasion, I expected that when I hoover over a link, and select "open with", the link would be opened with the selected application.
But in stead the webpage itself gets opened in the selected app.

But that's how it works. The *link* is opened.
I right clicked the link in your signature and chose to
open it in kate -> I got dutch source code ;-)

And this behaviour makes sense. I would have
expected konqi to do the same for images.
But then again, there are also images with links around them
so it's probably impossible to find a solution that's intuitive
and consistent under all circumstances...