[sugar] Wrapping Sugar activities for other desktops

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Pesenti Gritti wrote:
> On Sat, Nov 8, 2008 at 10:56 PM, Benjamin M. Schwartz
> <bmschwar at fas.harvard.edu> wrote:
>> There are two issues here:
>> 1.  I don't know how the inner workings are designed, but as a Python
>> activity author I never have to write a datastore call.  My impression is
>> that the Journal asks Rainbow's launcher service to start the activity
>> with a particular object-id.  The launcher service starts the activity,
>> loads the file from the Journal, and then calls the activity's read_file()
>> method on the resulting filename.
> 
> Yeah, the Activity class has high level read_file/write_file methods
> which could be probably replaced with a non-datastore implementation.
> But not all activities are using the high level API.
> 
>> 2.  I'm not suggesting that we "work without a datastore/journal".  I am
>> suggesting that the sugar-wrapper will instantiate a D-Bus daemon that
>> provides the datastore API.
> 
> Ok. But afaict that's not what Martin is proposing here.
> 
> Using the datastore and providing a Journal view would be certainly
> the most straigth forward implementation, but the level of integration
> with the rest of desktop would be very low. Maybe it's fine until we
> get a POSIX compatible datastore though?

Argh.  We are speaking at cross purposes.

My point is simply that we could create a very thin dummy layer that
provides the launcher API and datastore API but implements them very
simply.  For example, the object selector would simply pop up the GTK
filechooser pointed at $HOME, and the launcher would just provide the
filename indicated by an argument to sugar-wrapper.  This functionality is
exactly what "wrapper" means to me.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkWDscACgkQUJT6e6HFtqROCgCfX+Cv5EGquwok1i31auJaGFI6
HoMAnin+B18fNMH4n+lph4nTlZIMw5oQ
=7ipL
-----END PGP SIGNATURE-----