Re: [IAEP] [Sugar-devel] Unified Objects (was Unified bundles)
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
Re: [IAEP] [Sugar-devel] Unified Objects (was Unified bundles)
Wow, you're right- the entire Activity List View is no longer needed! Activities can be erased, starred and tagged from the Journal just like any other entry. The Journal icon can move over into the upper right hand corner of the Home view, taking the List View icon's place. That reinforces the notion that the Activity circle view is just an alternate Journal view. The Journal interface thus moves into the "F3" level, making it even more accessible. I love it when improvements result in less code and fewer screens. Eben, would you be onboard with this Home view + Journal list view merging in the UI? Best, Wade On Wed, Apr 8, 2009 at 7:25 PM, Gary C Martin wrote: > 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
Re: [IAEP] [Sugar-devel] Unified Objects (was Unified bundles)
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
