[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: [kde-linux] KOnqueror and file-bindings
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2003-11-30 22:52:54
[Download RAW message or body]

Christoph Eckert wrote:
> Hi,
> 
> Am Sonntag, 30. November 2003 06:36 James Richard Tyrer wrote:
> 
> 
>>>Unfortunately, I'm not glad with the file bindings of
>>>konqueror. 
> 
> [...]
> 
>>>* When I tell konqui to open jpg files with my favorite
>>>image viewer, konqui also opens jpgs on web pages with
>>>the image viewer.
>>>
>>>* When I tell konqui to always open text files in my
>>>favorite text editor, also text files on the web are
>>>opened with the text editor instead showing them inline
>>>in konqui.
>>>
>>>* When I try to assign my favorite HTML-editor to open
>>>local html files, also on the web HTML pages are shown in
>>>the editor but in line.
>>
>>In general what you say is true and might be considered to
>>be a bug.
> 
> 
> I'd not call it a bug. The behaviour is simply different from 
> other OS.
> Otherwise, I'd call it at least a missing feature ;-) .
> 
> 
>>A suggestion has been made that Konqueror should
>>be able to make a distinction as to whether or not the URL
>>started with: HTTP: or FTP:.  This is going at it the other
>>way but it would accomplish what you want.
> 
> 
> This could be a possibility of three I think about:
> 
> * setting the bindings depending of the protocol. The 
> difficulty is, that there are more protocols defined by 
> IOslaves. I think about fish:/ and similar. Should they act 
> more than ftp/http or like file:/ etc.?
> So, has the user to define the behaviour for each protocol? 
> Would be nice, but this is simply too much and would need a 
> complex UI.
> 
What I am suggesting (not formally yet) is that we create an additional pseudo-MIME type 
(we already have: "inode/directory" etc.).  I suggest that the root type be: "web".  Then 
we would have subtypes: "http" & "ftp" which would apply to URLs starting with: http: or 
ftp: and override the actual MIME type for the file.  So, these wouldn't affect: 'fish' or 
other communication protocols.

NOTE: there appears to already be something in KDE that knows if it would have to download 
a file before it could open it.

> * setting the file bindings depending on the view mode (web 
> browser / file manager). This would be also a possibility, 
> but it is possible for the user to define new view modes. 
> Maybe also not be the best option.
> 
This probably wouldn't work too well since many users (e.g. me) don't make any distinction 
between the two profiles.  Mine are exactly the same except for the default home URL.
> 
>>I was supposed
>>to write up a wish list item for this, and will try to
>>remember to cc you on it.  There is no urgency here because
>>it isn't going to be in 3.2.
> 
> 
> Yes, of course it's too late for 3.2. I'd bee glad to be in 
> the CC of the entry at bugs.kde.org.
> 
> 
>>On the other hand, this is a configuration problem.  The
>>only way I know of to fix this is to edit by hand:
>>"$HOME/.kde/share/config/konqueorrc".  Look for the line:
>>
>>	askSaveapplication/x-rpm=Yes
>>
>>and delete it.  If it isn't there, something else is wrong.
> 
> 
> Thanks a lot, I'll have a look at it.
> 
> Otherwise, I can work around that.

You shouldn't have to work around this because it works properly on my system.  When I 
click an RPM on my local system, it runs KPackage and when I click an RPM either on HTTP 
or FTP, up pops the widget asking if I want to open it or save it to disk.

So: as I said, KDE knows the difference already.  All that is needed is for it to also be 
able to use this information when you have specified an embedded viewer for that MIME type.

--
JRT

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic