Priorities for Develop?

[Jameson "Chema" Quinn]

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.


>
> * NO TOTAL LOSS OF JOURNAL CONTENTS.


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
reproduce?


>
> * 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


check.


>
> * Producing valid activity bundles as they now exist


check*

*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/activity.info


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
journal).


>
> * 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 activity.info. 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 activity.info among other
things. You would still have text access to activity.info.


>
> * 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).

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080516/addda2b8/attachment.html>