[Sugar-devel] [GSoC] progress report
lucian.branescu at gmail.com
Thu Jun 4 23:20:42 EDT 2009
and epiphany-gecko. It triggers a security dialog, so I'll stop
worrying about random scripts on the internet making exploits
However, the bridge doesn't work in Browse. The logs don't say
2009/6/4 Lucian Branescu <lucian.branescu at gmail.com>:
> 2009/6/4 Tomeu Vizoso <tomeu at sugarlabs.org>:
>> On Wed, Jun 3, 2009 at 22:00, Lucian Branescu <lucian.branescu at gmail.com> wrote:
>>> Since I missed the meeting, here goes.
>>> I've had a really hectic past few days, with 2 exams, just getting my
>>> laptop back and constantly fighting my Uni network restrictions. But
>>> it's better now, finished with exams and I figured out how to trick
>>> the proxies.
>>> I played around with a template Site Specific Browser based on Browse,
>>> almost identical up to now. I think I have SSB generation mostly
>>> figured out, I need to start implementing it. I will probably have to
>>> either change the existing bookmark mechanism or add a new one,
>>> because bookmarks (specifically bookmarklets) should be part of data,
>>> not state.
>>> I also tried Tomeu's technique for getting Gears to work, but that
>>> xulrunner bug prevents any permissions being granted. My initial plan
>>> was to test Gears with GMail, but it's not quite possible right now.
>>> I'll look into it, but I'd rather not have to build xulrunner.
>> I think we can workaround the dialog sizing issue in hulahop, ping me
>> in IRC and we can see what we can do.
> Sizing isn't really an issue. The permission dialog appears and is the
> size I would expect, but there's nothing in it.
>>> Also, now I'm more inclined to do the dbus functionality through
>>> pyxpcom, mostly because of security issues.
>> In my experience with Flash activities using Gnash, rather than giving
>> access to the full DataStore API it's much more practical to provide
>> some very simple state-saving functionality at first. If the python
>> side can tell the JS side to load a buffer of data, and can ask it to
>> hand a buffer to save in the DS, we can make 90% of activities work
>> with very little effort. We can always make available later the full
>> API or even generic DBus access.
> Saving state is not really an issue. At least current web apps are
> built so that they do not lose any data if they suddenly die and some
> of them also resume from where the left off. For most, it would be
> enough to save the URL.
> Ideally, it would be better to serialise the webview, if possible.
>>> to handle security around that. Since my dbus needs are limited, I
>>> objects that do simple things (notifications, sounds, etc.). Of
>>> course, dbus is still a secondary objective.
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel