Changing the default application associated with application/xml to Kate?

Michael Leupold lemma at confuego.org
Fri Aug 14 13:44:31 BST 2009


David Faure wrote:
> On Friday 14 August 2009, Michael Leupold wrote:
>> David Faure wrote:
>> > On Tuesday 28 July 2009, Raphael Kubo da Costa wrote:
>> >> I'm not sure if this should actually be taken to kde-devel; if so,
>> >> please tell me.
>> >> 
>> >> Bug 201162 (https://bugs.kde.org/201162) isn't actually a bug - the
>> >> default application associated with XML files is Konqueror, but when
>> >> the XML file isn't styled it just renders a blank page, confusing the
>> >> users.
>> > 
>> > Interesting, both khtml and kdewebkit render a blank page indeed.
>> > I was hoping webkit fixed that; guess not.
>> > 
>> > So I agree, real xml files could go to kate. But make sure that the
>> > xhtml subtype keeps going to konqueror.
>> 
>> Is this actually possible to decide before deciding on the KPart?
>> According to http://www.w3.org/TR/xhtml-media-types/ you can't decide on
>> the mime-type alone as XHTML documents MAY be served using
>> application/xml or text/xml in addition to the proper
>> application/xhtml+xml.
> 
> If you follow a link to an application/xml page in konqueror, the new page
> will still be shown inside konqueror, since the current part supports the
> mimetype.
> 
> But indeed, this means that typing a http URL in krunner could end up
> opening up the page in kate rather than konqueror. Bad.
> 
> I have no idea why they said that xkhtml documents may be served using
> application/xml, that's just broken since it means we can't differ between
> "xml that contains html tags" and "pure xml that a browser cannot
> understand"...

Yes, I fully agree on that. I'm currently contemplating writing a KXmlPart 
that can display xsl styled XML. The main problem I'll be facing is that 
given the current state I'll have to scout the XML and see if it's actually 
xhtml in order to pass it to an embedded KPart for the application/xhtml+xml 
mimetype.

I don't know if there's any way we can fix it. There are several ways a 
browser could handle it but I can't judge if they make to implement for KDE:
- Advanced document type detection using more than just the headers/mimetype
- Giving KParts the possibility to "reject" a document so the application 
can pass it to the next part supporting the mime-type. This seems 
unrealistic as advanced KParts reimplement openUrl. I also guess this might 
have to be implemented on a per-application basis.

Oh boy.. my regards to the respective W3C working group..

Michael





More information about the kde-core-devel mailing list