Preferred end user 3rd party app installation method

[Albert Cahalan]

Dan Williams dcbw at redhat.com
> On Tue, 2007-04-03 at 02:41 -0400, Mike C. Fletcher wrote:

>> 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.

Fix it.

> 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.

Most of these are either in the nice-to-have category or easy.

> Adding a few D-Bus calls is trivial.

Nope, it is not. I've been spending much time lately digging though
a mess of Python to find what the requirements are. I've not yet had
any luck. My little "hello world" in pure Xlib is still unable to run.
The DBUS portion has great big "#if 0" sections because of the extreme
lack of documentation.

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

That's nice. You could do a "hello world" in each of these.
Start with C (with plain Xlib) to maximize the applicability.

> 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.

And if I don't?

Furthermore, these things do not inherently require DBUS.

> 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.

because you needlessly made DBUS a requirement

For example, Tux Paint can run on a little PDA. It still can't deal
with Sugar.

> 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.

That is unspeakable bloat.