katepart displays source code without konqueror knowing it

David Faure david at mandrakesoft.com
Tue May 14 20:05:10 BST 2002


On Tuesday 14 May 2002 18:38, Erik Sjölund wrote:
> This is a reflexion over:
> Bug#42464: Konqueror doesn't switch between 
> text editor KPart and web broswer mode
> 
> 
> I'm not so familiar with the code, so
> this is more like speculating...
> 
> 
> The katepart is able to display source code
> of different mime types, e.g.
> 
> text/x-makefile, text/html, text/x-c++ .... 
> 
> These mime types are all listed in the file
> kdelibs/kate/data/katepart.desktop
> 
> Let say konqueror has just shown a text/plain
> file. After that a text/html url is requested by
> the user. Konqueror checks if the previously loaded 
> view can handle the newly requested service type.
> Katepart can handle text/html, so konqueror uses 
> it ones more. The requested html page now gets 
> shown in source code format.

100% correct.

> What I just showed here was that konqueror 
> didn't know how the part was going to display 
> the URL.
> A suggestion:
> 
> Maybe, one could introduce a new entry
> type in the desktop files, such as
> 
> X-KDE-SourceViewer=yes

Too hackish to my taste. Everyone writing a text viewer/editor
will not think of adding that line.

What other options do we have? We could check if the current part supports
text/plain, when trying to open something for text/html - if it does, it's not
"good enough", it's a source viewer. Still hackish, but at least can all be done
inside of Konqueror.

The option to "always switch back to the preferred viewer for a given mimetype"
is more generic, but doesn't sound too good to me, it prevents reusing the same
handler that's not the preferred one..... Thinking of e.g. an image viewer it would
be an unexpected behaviour.

-- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KDE, Making The Future of Computing Available Today





More information about the kfm-devel mailing list