Develop: Difference between revisions
(release -23) |
|||
Line 50: | Line 50: | ||
* [http://z3p.jot.com/WikiHome/DevelopActivity/Plans Rudimentary source control] - z3p |
* [http://z3p.jot.com/WikiHome/DevelopActivity/Plans Rudimentary source control] - z3p |
||
Here are some features which may be desirable, but nobody is working on them. Some of these would be enormous projects and will probably never get done. |
Here are some features which may be desirable, but nobody is working on them. Some of these would be enormous projects and will probably never get done. Others may be more feasible than they appear, by just building a Sugar interface on top of existing tools. |
||
* Class browser, autocompletion, popup function signatures, refactoring aids, and similar code-editing sweets. |
* Class browser, autocompletion, popup function signatures, refactoring aids, and similar code-editing sweets. |
||
* Bug tracker (would have to allow users to submit bugs to a centralized repository) |
* Bug tracker (would have to allow users to submit bugs to a centralized repository) |
||
* Unit testing |
* Unit testing |
||
* Doctools |
|||
* Gui designer (with libglade available to all sugar apps?) |
|||
* Source control (ideally much of the functionality should be inherited from the journal - wait for this stuff to make it into the journal first) |
* Source control (ideally much of the functionality should be inherited from the journal - wait for this stuff to make it into the journal first) |
||
* Activity sharing / Pair Coding (that is, concurrent editing of the same source file. It has been suggested that this should be implemented by replacing the editor widget with an Abiword widget; the Abiword folks have done some work in this direction.) |
* Activity sharing / Pair Coding (that is, concurrent editing of the same source file. It has been suggested that this should be implemented by replacing the editor widget with an Abiword widget; the Abiword folks have done some work in this direction.) |
Revision as of 13:02, 7 February 2008
see more templates or propose new |
The Develop activity is the activity for making or modifying other activities. Currently, it comprises a tree view of files in an activity's directory and a python source code editor (tabbed). Other features are actively being worked on.
This is the second incarnation of such an activity. The wiki page for the previous, now broken, version is at Old Develop activity. The old page has discussion of many grandiose planned features, which are worth looking at for ideas, and in general still considered desirable. However, the new version is intended to be developed step-by-step, with small, working features valued over all-encompassing architectures.
Considerations
Currently this version only edits activities that are stored in ~olpc/Activities, but that at least means that you can use it to develop itself. It keeps on the filesystem instead of the Journal, but this may change in the future.
To work, it needs you to either disable Rainbow globally or apply the patch to activiyfactory.py because it needs access to the files in ~olpc/Activities.
Roadmap
Here are some features planned for implementation relatively soon:
- creating new activities
- running the activity from Develop (see debugger idea, below)
- viewing/editing source of existing activities (by making a local copy)
- Replace (I don't have a good idea for an interface yet -- paulswartz)
- Wrap up bundle (zip to .xo file and store in journal with correct mime type)
- exporting/importing individual (eg. svg) files from the Journal so they can be edited with other activities
* This will be more useful when there's an activity which can edit SVG files. paulswartz
Here are some features which take more work but there is somebody interested in working on them:
- A debugger based on the RPDB2 (winpdb back end) console. This would mean some significant work on providing a context for a running activity - maybe even letterboxing it inside a frame of develop. Homunq 11:26, 5 February 2008 (EST)
- Code-level l10n - see bityi Homunq 11:26, 5 February 2008 (EST)
- Rudimentary source control - z3p
Here are some features which may be desirable, but nobody is working on them. Some of these would be enormous projects and will probably never get done. Others may be more feasible than they appear, by just building a Sugar interface on top of existing tools.
- Class browser, autocompletion, popup function signatures, refactoring aids, and similar code-editing sweets.
- Bug tracker (would have to allow users to submit bugs to a centralized repository)
- Unit testing
- Doctools
- Gui designer (with libglade available to all sugar apps?)
- Source control (ideally much of the functionality should be inherited from the journal - wait for this stuff to make it into the journal first)
- Activity sharing / Pair Coding (that is, concurrent editing of the same source file. It has been suggested that this should be implemented by replacing the editor widget with an Abiword widget; the Abiword folks have done some work in this direction.)
- Dynamic reloading of a running activity
- Visual programming
Updates
* -20 has undo/redo and find * -21 has support for jhbuid (thanks to Mike Fletcher), and is refactored a bit * -22 has a tabbed editor and a file menu * -23 has a new lazily loaded sidebar, can open an external file and create new activities