I've tried the javascript-dbus bridge and it works nicely in firefox and epiphany-gecko. It triggers a security dialog, so I'll stop worrying about random scripts on the internet making exploits targeting Sugar.
However, the bridge doesn't work in Browse. The logs don't say anything relevant. 2009/6/4 Lucian Branescu <lucian.brane...@gmail.com>: > 2009/6/4 Tomeu Vizoso <to...@sugarlabs.org>: >> On Wed, Jun 3, 2009 at 22:00, Lucian Branescu <lucian.brane...@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. > >> >> Regards, >> >> Tomeu >> >>> This >>> http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes >>> would provide dbus accessibility directly to javascript and I'd need >>> to handle security around that. Since my dbus needs are limited, I >>> prefer to instead do everything python-side and inject javascript >>> objects that do simple things (notifications, sounds, etc.). Of >>> course, dbus is still a secondary objective. >>> _______________________________________________ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel