Active activities as Widgets

[Gerard J. Cerchio]

Yoshiki Ohshima wrote:
>   Hello,
>
>   
>>> I would like the ability to exploit other active activities in my own 
>>> activity.
>>>       
>> Rainbow is designed to specifically disallow this.
>>     
>
>   What I'm going to write here is not really based on the current code
> (of which I don't know too much detail), but just an idea (tually
> based on an idea of my colleagues)...
>
>   If activities do not always have to run in full-screen, and each
> activity exposes some of its capabilities and properties so that they
> can be accessed via DBus or some other inter-process messaging
> mechanism, these activities don't have to be running in the same
> address space, and don't have to share files to work together.  X
> Window System can surely display many windows and doesn't care if
> these windows are created from the same process or not.  To the user,
> a window created by a process for an activity would just look like a
> fat "widget".
>
>   It would be OpenDoc on X with process separation, sort of.  In a
> sense, this would not be that big departure from current Sugar+DBus
> combination.
>
>   A security system for it could still decide which activity can see
> whose property, so it can be effective.
>
>   
>>> If a video conference is already active, and the participants wish to 
>>> PlayGo I would like to have a panel in the PlayGo application that 
>>> allows the video call to continue throughout the game. I came upon this 
>>> idea when I was trying to duplicate the Chat activity within PlayGo just 
>>> to allow the players to talk to one another. I asked my self, why 
>>> duplicate code, connections and system resources that are probably 
>>> already running in RAM?
>>>       
>> Sugar will gain a feature called overlay chat, once we've got higher
>> priority collaboration stuff completed, which will automagically add
>> chat functionality to any (sugarised, python) activity. There's no time
>> frame on this feature yet though.
>>     
>
>   But think about more general cases.  Imagine a user wants to create
> a multimedia document with movie, audio, text, painting, etc.,
> etc. laid out in one document on one screen.  (Let's say a realization
> of BulletinBoard activity.).  If you can use existing activities to
> write yours, it would be so simple.  To the user, it just looks like a
> multimedia document and each of these media objects are alive, but
> internally, they are different processes, looking at different
> directory, and doesn't know each other.
>
>   I think OLPC people heard about it and/or thought about it.  I admit
> that if each activity consumes 15MB or such, this wouldn't fly.
> Nonetheless I think this is an iteresting thought.
>
>   
Yoshi, I think full OLE would be very limited by the hardware. <sniff> I 
have no hardware,
I have experience with an older generation geode on the Jhai PC project 
without the video
sub-processor, and find in many cases, the geode is the little chip that 
could, but full
multi media documents running multiple renderers seems out of the 
resources' reach even
to this geode fan.