[Fwd: Re: Some questions about gtkwebcore and FYI]
- From: Philip Van Hoof <spam pvanhoof be>
- To: tinymail-devel-list gnome org
- Subject: [Fwd: Re: Some questions about gtkwebcore and FYI]
- Date: Mon, 15 May 2006 18:27:44 +0200
FYI
--- Begin Message ---
- From: Kimmo Kinnunen <kimmok iki fi>
- To: Philip Van Hoof <pvanhoof gnome org>
- Subject: Re: Some questions about gtkwebcore and FYI
- Date: Mon, 15 May 2006 18:44:13 +0300
Hello Philip,
Would it be(come) possible, using the standard gtkwebcore api, to
disable loading images, stream HTML 'and' image-data in and to disable
javascript?
Certainly this is possible. Gtk-webcore was/is based on WebCore-145+,
which was already used in Apple's Mail client. All needed hooks are in
the engine. Disabling image loads and javascript might even be connected
in the gtk-webcore public (gobject c) api, I don't quite remember did I
completely implement that one. It is not possible to write custom url
handlers with the public API. There is few url handlers in NRCit C++
code, namely ones for file:// and http://.. One should implement a
public api for this and then hook it up to the NRCit loader stack..
I'm planning to add support for gtkwebcore to tinymail. However,
tinymail does not have the attached images (mime parts in e-mail
terminology) of a message stored on a disk nor available on a url. And
the ones that are located on some url shouldn't be loaded (for well
known anti-spam reasons).
The gtkhtml component was once hacked for evolution and does have these
features. But I'd prefer to use for example gtkwebcore.
Yes, so the basic thing is, that custom url handlers can be written and
above settings can be set in the rendering engine, so that certainly
this kind of feature can be implemented. The biggest part is defining
the public gobject c api (maybe with GInterface or some signals which
carry ids in args), and then implementing in NRCit C++ side the file
hooks that connect the public api to webcore.
The reason why it would be great to have the possibility to 'stream'
data rather than putting it on a filesystem and loading a "file://" url
is that with proper streaming I can make the system in such a way that
unused mime-parts are never downloaded from the e-mail service nor ever
Yes, image view on demand is possible. I don't know how the html mail
refers to attached images, but anyway the drill is always the same.
Process the html and filter unsecure stuff, convert img/css/etc urls to
some custom url scheme, for example 'attachment:'. Then feed the data
(html mail) to the engine. If the image viewing is on, the engine issues
the load to loader stack, where there can be custom loaders implemented
through the public API. The loaders then can do what ever they like, for
example stream IMAP data through base64 encoding filter back to the engine.
> So if it would
> be possible not to load the mime parts in the memory nor to download
> them from the service: I wouldn't.
In any case, if you are showing the attachments, you of course need to
have the attachment in the memory. In practice the data will be there
many times, usually the minimum is that you have the compressed image
and the drawn image.
Imagine 'viewing' an E-mail with a 10mb attachment on a device that has
only 15 mb ram: Using streaming I can stream that attachment piece by
piece to the target filesystem.
Well, I'd say it'd be challenging to open 10mb attachment on device with
64mb or 128mb ram. With 15mb ram linux device you cannot even run
programs linking to webcore. But anyway, I get your idea.
Oh and, for your information. The current release doesn't compile on a
Dapper:
Yes, there's some C++ related compile errors which have been fixed in
the cvs version. They're due to recent g++ being more strict or c++ std
changes.. I don't know if the gtk / gdk / glib / gobject parts compile
on Drapper, I would expect not, since lots has happened with the
libraries during the inactivity perioid. :)
I doubt that you should try to use gtk-webcore as-is, because it's
pretty unstable. It's based on ages old WebCore version and the code I
wrote (NRCit) is pretty much crap. In order to have even moderately
secure mail client with webcore rendering html mail, one would first
need to re-port the WebCore from webkit.opendarwin.org svn and then
re-write the component equivalent to WebKit/NRCit..
I even have some unfinished code related to that. It was left unfinished
because I lost interest in tracking apple changes and writing the dull
GObject classes / interfaces by hand.
There's some activity in webkit community to port the recent webcore of
the apple's webkit to gtk/linux. The port has been initiated by this one
guy, but nothing has been released AFAK. Of course after webcore port
there's the job of writing webkit equivalent code (I wrote the NRCit,
the part that sucks probably the most in gtk-webcore) which has not
started at all. So it'll take a while before this can be used.. If you
are interested, check out webkit.org and there the mailing-lists.
I saw from your blog that you're already working with mozembed.. That's
good alternative also, and certainly more stable than my gtk-webcore work =)
BR,
Kimmo
--- End Message ---
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]