Priorities for Develop?

Jameson "Chema" Quinn jquinn at
Fri May 16 07:39:03 EDT 2008

OK, here's the status on your list. In general, I had taken it as a given
that most of what you said would work before I moved on.

> Develop should be really really good at creating new activities, and
> editing existing ones, without any need for using Terminal and other
> editors. That should be stable, reliable and effective.
> Features required for this, IMHO, are:
> * Integration with the View Source key for arbitrary activities

For arbitrary *python* activities, all necessary code exists. View source
would rebundle current activity and take you to the journal where you could
open it. (Minor missing UI: that bundle should default to editing instead of
running - needs new journal features.) I'm waiting for a few joyrides which
include my other patches before pushing this as a patch.


Haven't seen it in months. Datastore should be made more sturdy anyway. I
know that this answer is lame, but how do I debug what I can't now

> * No need for DoppelJournal

The two necessary patches have existed for months now, Tomeu had promised to
review them, but that is apparently going slowly.

> * Support for editing single file activities

Not on my roadmap - that is Pippy's job (unless you mean "editing n-file
activities where n=1").

> * Support for editing multiple file activities


> * Producing valid activity bundles as they now exist


*currently also very easy to lose changes by producing invalid activity
bundles by munging MANIFEST. This is the main motivation for updating bundle
format, hopefully this should be fixed soon.

> * Access to activity/

check. Text-only access, no smarts included. This is generally the plan,
except as indicated below.

> * Icon editing for activity/*.svg

No svg editor on XO, not a current plan. Mid-term plan: export and import
subfiles as separate journal entries, an easy change. Long-term plan:
journal understands subfiles natively (this is part of eben's plan for

> * Ability to easily continue editing an activity (keep version number,
> service name, other metadata) or do a new release (increment version
> number) or fork (change relevant metadata)

Currently works, just by editing To make this "smarter"
requires new bundle format. Once new bundle format exists, I intend toolbar
support for all of this; this would auto-edit among other
things. You would still have text access to

> * Ability to start a new activity, populated with relevant minimum
> boilerplate code (Hello World) that runs immediately and can be worked
> on immediately ("Look, I did a program!")

Planned, unimplemented. Pretty simple (basically means including a hello
world bundle template inside the activity).

> Some of the above require changes to Sugar or Journal. Take that as
> your responsibility to keep those patches up to date and get them
> reviewed and merged.

I don't know how much more I could bug Tomeu for the two existing patches,
or what else I should be doing. He definitely knows they exist and I bug him
once a week or so.


> As a lower priority feature, I would be interested in seeing the
> ability to view (and possibly edit) python "system" (non activity)
> code, including sugar, sugar-toolkit (sugar libs), presence service,
> journal, datastore. As someone said of having a Free Software kernel
> on the XO, it's not like the kids will start developing the platform,
> but at least they will see that it is developed by mere mortals and
> say "Oh, Python! So *I* can get from here (my simple activity) to
> there (sugar itself)!"

well, for Journal this is an easy change. The rest sounds like a good idea,
but honestly I think it should be a separate activity - trying to shoehorn
it into Develop would clutter the interface IMO. I may be wrong, ESPECIALLY
if Develop gets some dream features (class browser? I added that to the
voting list on the dream page).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list