[sugar] Web activity & ebook reading

[Marco Pesenti Gritti]

On Sat, 2007-05-05 at 19:46 -0500, Ian Bicking wrote:
> So we've been talking about "the" ebook reader, and how it might work.
> For reading HTML or things that would be converted into HTML (e.g.,
> Crossmark), the browser seems like an obvious basis for a reader.
> There's not a huge number of basic features that aren't in the browser
> currently.  So we're thinking about how we might add these extra features.
> 
> I've been reading the list of methods as described here:
>    http://www.pygtk.org/pygtkmozembed/class-gtkmozembed.html
> and there's not a lot of methods.  Changing buttons, maybe allowing you
> to switch modes, all seems pretty reasonable -- the code at least all
> looks simple enough.  But some of what we want to do involves getting at
> the document object.
> 
> As an example, if you get to the bottom of a document, and the document
> has a <link rel="next"> tag, then a page-down from there should take you
> to the linked page.  Then you can flow through a linear but multi-page
> document fairly seamlessly (assuming it's been marked up nicely).
> There's a variety of things we'd like to do, including injecting the
> Javascript to implement the ubiquitous annotation.
> 
> Is the current browser activity -- and more specifically pygtkmozembed
> -- the right basis for this kind of work?  In the short term, are there
> ways we can start adding these features (even if the implementation may
> have to be discarded later)?
> 

If you are planning to put this in the Read activity it should not be
based on the Web activity but rather on the sugar.Browser component. 

gtkmozembed API is very limited. There are multiple ways we can allow
activities to access the full mozilla API (and hence being able to do
stuff like manipulating the DOM etc).

The two ways that makes more sense to me are:

1 Hook up pyxpcom support to sugar.Browser. In theory this would allow
you to access the full xpcom mozilla API from python. My only doubt
about this approach is that pyxpcom has not been used a lot so far (and
development does not seem to be very active).

2 Implement come sort of extension system on the top of xpcom components
(extensions could be written in javascript, c++ and maybe python at that
point)

Approach 1 would probably end up being a lot cleaner if we manage to get
it to work.

> 
> Looking at details, we were thinking that maybe browser.append_data()
> could be used to inject at least a little Javascript.  I tried adding
> this to WebActivity.__init__:
> 
>    self._browser.connect('notify::net-stop', self._doc_loaded_cb)
> 
> Then:
> 
>    def self._doc_loaded_cb(self, embed, *args):
>        data = '<script>alert("hey!")</script>'
>        embed.append_data(StringIO(data), len(data))
> 
> But I couldn't get the signal to fire at all; I couldn't get any signals
> to work except notify::title.  Maybe there's something magic that I
> don't understand here.  Anyway, that might give me a crude way to hack
> on stuff.

The notify:: prefix is used to get signals on gobject properties
changes. You want just "net-stop" there.

Marco