Re: [IAEP] [Sugar-devel] Unified Objects (was Unified bundles)

[Aleksey Lim]

On Thu, Apr 09, 2009 at 03:30:00AM -0400, Michael Stone wrote:
 
 Now here's a mess of ideas from which these three basic intuitions originate:
 
 1. It would be nice to be able to generate various views of what the user can
 do with shell globs rather than by writing complicated queries over in-memory
 data-structures that have to be fully loaded and locked into RAM before you 
 can
 render anything...
 
 2. Activities need to expose their API to the shell. In particular, we /need/
 to be able to get an activity to self-test a system for deps, to run
 non-graphical tests, to run graphical tests, to run network tests, to run a
 demo or tutorial of itself, to show its source, ...
 
 3. One interesting way to think about (1) and (2), which I have previously
 discussed with Eben, is in the context of the Plan 9 plumber. Go read about 
 it.

But it means adding p9 kernel module of FUSE to SugarPlatform
dependencies - a bit overmuch for to try sugar just install it in your
favourite distro

-- 
Aleksey
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [Sugar-devel] Unified Objects (was Unified bundles)

[Gary C Martin]

On 8 Apr 2009, at 20:17, Wade Brainerd wrote:

 The idea that activities actually exist in the Journal (and only in
 the Journal) is really exciting to me.

Yes, it's a right old lucky dip mess for what you find in Journal for  
Activity bundles just now. Old bundle versions that you're not sure if  
you erase if it will also de-install the newer version of it (I've had  
this happen a few time but haven't tested behaviour lately); and many  
bundles missing altogether from Journal as an activity arrived via  
some other non-journal route to you system (pre-installed, software- 
update, manual sugar-install-bundle).

 To fully realize this, we should unpack their .xo bundles *into their
 Journal entry directory*,  not /home/user/Activities.

I like it, that would resolve the distros from what seems like using  
arbitrary directories the user has no control over.

 Also, the default Activities should be present in the Journal, which
 means the Journal would not be empty at install time.

 And finally, the Home view should actually be a special view of the
 Journal, showing all Journal entries that are activities.  As Aleksey
 says, this would open up all kinds of possibilities for alternate Home
 views which are different views of the Journal.

Yep. The current home list view could die, no need for it, and the  
default ring view content would show an icon for each unique Activity  
bundle from the Journal providing the same view we see now. We could  
use the Journal favourite star for the same purpose as currently in  
the home list view, so any Activity bundle with a Journal favourite  
star would appear in the home ring.

Home view is then just a view type of the Journal, actually you could  
finally drop the 'Journal as a separate activity object' and just have  
a home with a favourite view and (at least one but could be list and  
grid) journal view.

 Is this the direction we should be moving in?

I do like that it seems to simplify the UI and reduce code needing to  
be maintained.

Regards,
--Gary

 -Wade
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep