Preferred end user 3rd party app installation method

[Dan Williams]

On Tue, 2007-04-03 at 02:41 -0400, Mike C. Fletcher wrote:
> sbspammagnet at aol.com wrote:
> > Hi,
> >  
> > A few application installation questions as I'm not clear how much
> > of the documentation in the wiki actually works at the moment and
> > how much is intended to work:
> AFAIK at the moment all activity installation is manual.
> > How does an end user install third party written C based applications
> > today? (i.e. is there a GUI/device insertion triggered method or do you
> > have to do it from a shell?)
> At the moment, the shell is required AFAIK.
> > If, for example, we have an application on a USB memory key and we
> > would like it to auto install when the key is inserted or better still 
> > (for
> > our application) run from directly from the key, is there a mechanism
> > to do this?
> >  
> > To actually get the application to show up in Sugar do we have to
> > wrap the application with an activity which contains a python
> > bundle referenced by something like 'class=MyCAppBootstrap' that then
> > bootstraps the C app or can we reference the application directly using
> > 'class=MyCApp' or perhaps 'exec=MyCApp'?
> You can *almost* get an application to work just by specifying an exec.  
> The application will start (I just tried this with the Inkscape SVG 
> illustrator running on an emulated developer system, it should work the 
> same on a real laptop), but Sugar uses a number of dbus messages to 
> track the state of each activity.  Because your C application won't 
> respond to those messages Sugar will "lose track" of the application and 
> won't know to hide the frame or show the application in its activities 
> view or otherwise continue to manage it once it is started.
> 
> We'll likely want to fix that so that Sugar doesn't *rely* on the dbus 
> responses to track the applications.  That should be a straightforward 
> change AFAICS.

I'm not really sure we're going to do that.  There's only going to be
more specific interfaces in the OLPC environment, not just in the shell.

You already have to modify your application, if only for screen size,
rotation support, B&W operation, memory consumption, look & feel,
spurious wakeups, graphics depth, aggressive timers, etc. You are also
not guaranteed to be able to write files anywhere you want, access
devices any time you want, or talk to the network any time you want.
Adding a few D-Bus calls is trivial.

D-Bus has mainloop integration and bindings with most languages, glib,
Qt, python, C#, C++, C, Perl, Java, etc

If you want access to the presence service, easy collaboration features,
data store and/or journal, clipboard, etc, you will need to use D-Bus.

The point here is that this is not a traditional desktop machine.  If
people think they can just change window size and throw their app onto
the OLPC, they are wrong.

We may end up with a "classic" activity which runs traditional
applications within a Xephyr instance as an activity.  A non-native
application would run there, not in the normal Sugar environment.

Dan