Handling TamTam Resources...

Olivier Bélanger olivier.belanger at umontreal.ca
Tue Apr 15 23:49:59 EDT 2008


Thanks for quick answers!

Le 08-04-15 à 20:43, Eben Eliason a écrit :
>>  Olivier Bélanger wrote:
>>  | Is there a way to let all TamTam activities have access to a  
>> common
>>  | directory?
>>
>>  No.  Activities are untrusted code.  The security design assumes  
>> that
>>  every Activity is a trojan horse, unless the user specifically  
>> requests
>>  otherwise.

OK, it's clear!

>>
>>
>>  | How do think this stuff should be implemented?
>>
>>  The easiest solution, and the one I recommend, is to make the TamTam
>>  activities into a single activity.  There is no need to have 4  
>> distinct
>>  activities.  Switching between screens within one activity seems  
>> much more
>>  reasonable than running multiple distinct TamTam activities.  I  
>> cannot
>>  keep track of which one is which.
>
> Actually, I specifically recommend against this model, myself.  The
> activities each focus on very different overall tasks.  One is for
> composing, another is for performing, yet another is for
> constructing/editing sounds.  I wholeheartedly agree that we need to
> make them work together as seamlessly as possible, but the "do one
> thing and do it well" mantra is one that applies here, I believe.
> Each interface should be as clean and intuitive as possible, without
> the need to shuffle around a bunch of different toolbars and views.
> That's the reason the activity model exists as it does, fullscreen and
> with identifying icons for each activity.

At some point in the past, TamTam was only one activity, with a  
welcome screen to choose which activity to play with.
We were asked to split our activities and I think it was a good call.  
Most of our activities are now very complex and are design for  
different purposes.
I think the split facilitates learning what each of them does...

>
> Moreover, keeping them all together emphasizes their interoperability
> at the expense of generating objects that are available for use in all
> of sugar.  I should be able to make a sound in SynthLab and import
> that into my Slideshow.  I shoul dbe able to record a sound in the
> Record activity and import that into my TamTamJam session.  etc.
> Finding the correct way to let these activities share objects is
> crucial to creating the environment we *need* to reach with Sugar as a
> whole.
>

I am agree with the example of SynthLab's sound imported into  
SlideShow, that makes sense... but I don't think it's a good idea to  
share all our resources. Some sounds will be relevent only inside  
TamTam environment, musical context, very stripped sound with fine  
tuned loop points, etc...

Can we use the datastore without creating an entry in the Journal  
(kind of private resources)?

Actually, TamTam saves tunes in ogg format in the Journal, this is  
the files that we really want to import in others activities!

>>  If the activities must be separate, I recommend using the  
>> P_DOCUMENT_RO
>>  model.  Whenever SynthLab creates a new sound, it should be added  
>> to the
>>  datastore as a new entry.  TamTamEdit can then run with  
>> P_DOCUMENT_RO
>>  permission, scan the datastore for all sounds created so far, and  
>> load
>>  them all.
>
> This is the method I strongly recommend as well, as it has the
> advantages I spoke of above.  If these objects are created an placed
> into the Journal, then they can be shared, copied, edited, etc, with
> any activity that supports their type.
>

OK, I will look at the P_DOCUMENT_RO model.
Is there a template or an activity that does this kind of stuff where  
I can study the code?

Olivier





More information about the Devel mailing list