Priorities for Develop?

[Eben Eliason]

2008/5/16 Jameson Chema Quinn <jquinn at cs.oberlin.edu>:
> 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.

For true view source integration your missing a different piece of UI,
right?  You need a global handler for that key which presents a dialog
with the option to dive into the bundle with Develop.  This is the
piece that's really missing.

>> * Access to activity/activity.info
>
> check. Text-only access, no smarts included. This is generally the plan,
> except as indicated below.

This is a place I /could/ see making a really nice interface with some
simple text entries and options which sugar-coat the process for those
who might otherwise be intimidated.  (This would supplement access to
the text file, of course, not eliminate it!)  Basics like a human
readable title, service name, major/minor version checkbox (with a
preview of the version number to be produced), tag field, etc could
all be neatly arranged and populated with the contents of the text
file.

This is, of course, not top priority, but I'd bet it could make the
editing/creation process much friendlier.

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

This is a highly unfortunate thing, which I've known since the
beginning.  We thought we were going to have a version of Paint
(called Draw) built on Inkscape, but that hasn't materialized.  I'm
not sure what we can do to fix this in the short/medium term.

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

I could see treating the view of any file named "activity.info"
differently, with a little bar at the top for choosing between the
"plain text" and "form" views.  If you treat it this way, you can
prevent needless refreshes to the actual file (by parsing or
outputting) which are only required when the editing mode changes.  I
feel like a nice full page form is more suitable to the info needed
than another toolbar.

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

A really good hello world would be fantastic!  Let me know when this
gets underway so we can think up icons for any hello world activities
(It might be the case that there are several levels of "hello world"
activities...some with collaboration, others without, etc.)

- Eben