View Source question

[Paul Fox]

morgan wrote:
 > I think one of the difficulties is maintaining some sort of context
 > for progressive View Source operations. For example, View Source on a
 > web page shows the page source in Write. View Source again should
 > ideally dive into the Browse source, not the Write source...

thinking out loud:

instead of trying to tightly integrate "view source" into every
activity, could "view source" perhaps act more akin to a system
help browser?  i.e., it could be a separate browser-based
activity in its own right, used for generally learning how the
system works internally.  it would be accessible from the
activity ring, as usual, but also via the hotkey at any time. 
(maybe it wouldn't be a separate activity, but simply a topic in
the Browse library.)

hitting the View Source hotkey would start or switch to the "view
source" activity, taking you to a local web-tree of code-browsing
pages.  the initial location within that tree would ideally be
related to specifically what you were doing at the time you hit
the hotkey (it would be the responsibility of viewsource-aware
activities to provide enough context to allow this), but in the
minimal case it could simply point to the activity's main python
entry point.  obviously links directly into the interpreter
would be valuable, but in the interest of uniformity across
activities, i'd think a language-independent layer (i.e., the
browser) would have value.  (the looser coupling would also allow
more flexibility over time.)

since not all activities have on-board browseable source, some
parts of the "view source" activity's web tree would consist of
README-like material or block diagrams (akin to what you might
find on howstuffworks.com), links to external sites for more
information (e.g., wikipedia, the activity's project homepage),
or just about anything that can be delivered via a browser.

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 52.7 degrees)