https://bugs.kde.org/show_bug.cgi?id=387061
--- Comment #44 from Wolfgang Bauer <wba...@tmo.at> --- (In reply to RJVB from comment #43) > > TBH, I think even QtWebKit would struggle with these large mails > > That would be simple to test in konqueror with the webkit backend, or > Otter-Browser, and the rebooted QtWebKit. Or in epiphany. > 1 caveat emptor: we don't actually know what clever tricks the web email > interface pulls. I do use QtWebKit with konqueror, and opening large OBS logs (which are just text files) do take a while. > > Anyway, this is kind of a different problem than comment#35 (or comment#0). > > I don't see how it could be fixed from the kmail side, except for not trying > > to display mails larger than a certain size at all. (or maybe just display > > it as plain text instead then, but that probably means a large rewrite of > > the code, and I'm not sure it's possible at all) > > - Don't dump the entire message into the rendering widget but use a paged > approach > - wrapper code can be written that connects to different backends. If you > don't want to support QtWebkit, fine, but there's also QTextBrowser which > should be sufficient even for simple HTML emails (it's what Qt's assistant > uses by default since whatever Qt version that obsoleted QtWebkit). I've > done a compile-time version of such wrapper code for KDevelop's help browser > (which supports both QWE and QWK). I think it should be possible at least to > chose between backends as a startup option. That's what I meant with a "large rewrite" amongst other things. Please note that I'm not a kmail developer though. > Out of curiosity: does that humongous QWE process exit when you close the > message view, or do you have to quit KMail to recuperate all that RAM? I think that the QWE process is reused. I'm not sure though, nor if it frees the resources when you switch to a different mail (I think it does). -- You are receiving this mail because: You are watching all bug changes.