[Sugar-devel] [Sugar-Devel] Sugar Web Engine

[Lucian Branescu]

On 8 June 2010 15:01, Peter Robinson <pbrobinson at gmail.com> wrote:
> Hi Luncian,
>
> On Sun, Jun 6, 2010 at 2:33 PM, Lucian Branescu
> <lucian.branescu at gmail.com> wrote:
>> I've received even less feedback from upstreams about their respective engines.
>>
>> There are still 2 issues:
>> 1) Mozilla have given up on having xulrunner work as a distro-provided
>> VM and now they just bundle it.. They plan some major changes to
>> embedding and they have no plan forward that would allow hulahop to
>> exist. It's no longer just about maintaining hulahop, but the entire
>> stack up from gecko.
>
> Sorry, the statement above seems inconclusive. Have you actually
> received confirmation from Mozilla that xulrunner is no longer going
> to be supported or is it just assumed due to their silence? Is that
> published somewhere if its official?
I went by what was on the wiki. Considering feedback I did eventually
get from Mozilla, the wiki was exaggerating.
>
> There are a number of both open and closed projects that depend on
> xulrunner so I would be somewhat surprised if they dropped support for
> it. Songbird. TomTom Home, Komodo IDE and OpenKomodo are all based on
> xulrunner. Its also used as part of a number of Mozilla projects.
>
> The other component that hulahop uses that caused us issues during the
> SoaS v3 release time frame was the support of pyxpcom was dropped from
> the main codebase. My understanding for the reason for this was
> actually a request from ActiveState (developers of Komodo/openKomodo)
> who are the maintainers of that code so they could develop and release
> it on a separate timeline to the main xulrunner release. Its still
> supported even if not in certain distros. You might find contacting
> them directly to find out their plans might yield quicker and better
> results.
>
>> 2) pywebkitgtk does not have a clear future. The changelog shows
>> activity, but stable maintenance is not assured
>>
>> 3) webkitgtk+ and PyGI might be the best solution, but it doesn't yet
>> work everywhere. From a technical p.o.v. the bits missing from PyGI
>> should not (significantly) hinder Browse, since web engines tend to
>> have comparatively little interaction with their GUIs.
>>
>> Right now, the only option that would actually works everywhere we
>> care about is pywebkitgtk. While it may not be future-proof, PyGI
>> would be targeting the same webkit API, so switching should be very
>> easy.
>>
>> Since it's already late into the project, unless someone has a better
>> idea, I'll stick to fully porting Browse to pywebkitgtk, using any
>> Surf code that is relevant. This should result in a fully-working
>> Browse with SSB features in time for GSoC that also has a clear enough
>> future.
>
> Sorry for the delayed response. It might be better in the short term
> to stick with hulahop / xulrunner until PyGI gets to a state that its
> usable. Let me know if I can help.
This week I'll try to finish the prototype abstraction layer. If that
works decently, I'll go with that and fully implement hulahop and
pywebkitgtk backends. If not, I'll stick to hulahop, fix whatever bugs
there are and implement SSB features.
>
> Peter
>
>> On 31 May 2010 13:41, Lucian Branescu <lucian.branescu at gmail.com> wrote:
>>> Since I got little feedback about the time, there will be a meeting in
>>> #sugar-meeting at 3PM GMT
>>>
>>> On 31 May 2010 10:09, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>>>> On Sun, May 30, 2010 at 01:58, Lucian Branescu
>>>> <lucian.branescu at gmail.com> wrote:
>>>>> In case you don't already know, I'm doing a GSoC project on improving
>>>>> the browser engine situation in Sugar
>>>>> http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser
>>>>>
>>>>> My exams haven't finished yet (last one on Wednesday), so before I
>>>>> start working, I want the opinion of people that use web engines in
>>>>> sugar applications or that are otherwise interested in web engines for
>>>>> sugar on how to proceed.
>>>>>
>>>>> I'd like answers to questions like "Should I drop hulahop and focus on
>>>>> webkit?" or "Is an API like hulahop's nice?", etc.
>>>>
>>>> What we need to find out in order to find the right answers to that is
>>>> what's the future of xulrunner. If Mozilla plans to drop some part of
>>>> their platform essential for hulahop, or if distros are not willing to
>>>> keep packaging it in a way that hulahop can work, then we should just
>>>> forget about it and move to webkit.
>>>>
>>>>> I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM
>>>>> and 9 PM GMT, depending on the availability of attendees.
>>>>
>>>> Great idea!
>>>>
>>>> Regards,
>>>>
>>>> Tomeu
>>>>
>>>>> Individual chats/ml are also welcome, but an IRC meeting would be ideal.
>>>>> _______________________________________________
>>>>> Sugar-devel mailing list
>>>>> Sugar-devel at lists.sugarlabs.org
>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>
>>>>
>>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>