On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote:
> My GSoC project involves building an abstraction layer above
> pywebkitgtk/hulahop (wiki/AbstractBrowser).
>
> While the project itself isn't related, this abstraction layer and one
> of it's lower layers (i.e. pywebkitgtk) would become a
There already is a mostly complete pywebkitgtk activity, Surf.
There has been a lot of debate on whether webkit is better than gecko
for our purposes. I also plan to only support what is reasonably easy
to support and let the abstraction layer be leaky.
This way, the new Browse can much more easi
On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu
wrote:
> There already is a mostly complete pywebkitgtk activity, Surf.
>
> There has been a lot of debate on whether webkit is better than gecko
> for our purposes. I also plan to only support what is reasonably easy
> to support and let the abstra
This is part of why I think having an abstraction layer is more
important than having a complete pywebkitgtk browser activity.
It would be even cooler if Read could also use this abstraction layer for epub.
On 26 April 2010 21:10, Sayamindu Dasgupta wrote:
> On Mon, Apr 26, 2010 at 2:18 PM, Luci
This is part of why I think having an abstraction layer is more
important than having a complete pywebkitgtk browser activity.
I would be even cooler if Read could also use this abstraction layer for epub.
On 26 April 2010 21:10, Sayamindu Dasgupta wrote:
> On Mon, Apr 26, 2010 at 2:18 PM, Lucia
This is part of why I think having an abstraction layer is more
important than having a complete pywebkitgtk browser activity.
I would be even cooler if Read could also use this abstraction layer for epub.
On 26 April 2010 21:10, Sayamindu Dasgupta wrote:
> On Mon, Apr 26, 2010 at 2:18 PM, Lucia
I wrote surf a while ago, and it was quite an easy port. In fact, the
demo browser for pywebkitgtk was (at least at one point) based on
browse. I did most of the work in a day and a half, but ran into
problems with both webkit's packaging and the feature-completeness of
pywebkitgtk (the ability t
On Mon, 2010-04-26 at 23:29 +0100, Lucian Branescu wrote:
> This is part of why I think having an abstraction layer is more
> important than having a complete pywebkitgtk browser activity.
>
> I would be even cooler if Read could also use this abstraction layer for epub.
Now it makes sense. As lo
On Mon, Apr 26, 2010 at 8:38 PM, Bobby Powers wrote:
> I wrote surf a while ago, and it was quite an easy port. In fact, the
> demo browser for pywebkitgtk was (at least at one point) based on
> browse. I did most of the work in a day and a half, but ran into
> problems with both webkit's packag
I plan to use current hulahop/pywebkitgtk to start out since there's
less to figure out. Since it's an abstraction layer, the backends can
be switched later.
I need a lot of feedback on what the abstraction layer itself needs to
do. Afaik, only Browse and Read use browser engines so far. And then
On Mon, 2010-04-26 at 17:38 -0700, Bobby Powers wrote:
> I wrote surf a while ago, and it was quite an easy port. In fact, the
> demo browser for pywebkitgtk was (at least at one point) based on
> browse. I did most of the work in a day and a half, but ran into
> problems with both webkit's packa
> On Tue, Apr 27, 2010 at 8:56 AM, C. Scott Ananian wrote:
>>> There are also gir bindings for webkit (in webkit's trunk), so it
>>> might be worth investigating their completeness, especially since
>>> pywebkitgtk seems to be unmaintained, as Sayamindu pointed out.
>>
>> I believe we use the GIR
On Mon, Apr 26, 2010 at 22:10, Sayamindu Dasgupta wrote:
> On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu
> wrote:
>> There already is a mostly complete pywebkitgtk activity, Surf.
>>
>> There has been a lot of debate on whether webkit is better than gecko
>> for our purposes. I also plan to on
13 matches
Mail list logo
