kdenox vs. the rest of the world

Simon Hausmann konq-e@mail.kde.org
Wed, 3 Apr 2002 19:47:52 +0200


(moving to konq-e list, easier to read for me as I read kde-devel
with digest :)

On Wed, Apr 03, 2002 at 02:03:36PM +0000, you wrote:
> In article <20020402225432.GB32671@master.kde.org> you write:
> >On Tue, Apr 02, 2002 at 05:39:27PM +0000, you wrote:
> >> I've just committed support in kdenox for ftp: urls.
> >
> >Yippee :)
> 
> Did you ever get a start on text/plain support, btw ?

Never got around it, yet. I only spent thinking about it.

Half of the problem is detecting the proper mime-type. I'm not sure
what's the best way here, but probably relying on the content-type
the server reports (the ioslave sends) should work best, without
adding much code from kdelibs like the kmimemagic stuff. And after
all we don't need a perfect detection, we just need a positive-list
approach: We only render as html or plain-text if we are 100% sure.
Anything else we skip (or leave to someone else :) . That also
solves the various ugly crashes when binary garbage gets filled in,
like for an <iframe src="somecrappyflashdocument.swf"> .

(but then again, I'm not sure what's the easier way to implement
this for ftp / file. Maybe just by looking at the extension should
work best in our case)

About the actual text/plain implementation... I'm not 100% sure
what's the best approach. One thing I have in mind is a filter-like
system, where a filter gets put on top of what the iojo delivers as
data. By default there's no filter, for text/plain there could be a
filter that just encloses the data within a <pre> tag.

A completely different approach would be to skip using khtml for
that and simply use a QMultiLineEdit widget for that. The
disadvantage is that it requires more new code, in terms of
enlarging the binary, as you need to implement some kparts
interfaces and the like.

> I gather it's not that hard to do, but I'm still finding my way
> in kde sources... I love the design though. First project of that
> size built with rational apis, so that you can write local code that
> works without bothering with the rest.

:)

> >I guess it depends on the amount of ifdeffery. But of course the
> >maintainer (David) decides. For now I'd say (with respect to the 2.2
> >branch) to keep modifications as separate patch, or work with a
> >complete copy in the CVS. It's just temporary until Qt/E 3 comes
> >into play.
> 
> Any ETA on that ?

I heard rumors that Qtopia will switch to Qt3 this or next month. If
it doesn't happen till the end of next month I think we should go
ahead, possibly temporarily disabling Qtopia support.


Simon