I am in the process of writing a patch to make the view source key extension able to open source in an appropriate activity. The basic scheme is: <ol><li>user presses view source</li><li>extension asks activity (over dbus) if it wants to handle this one by itself</li> <li>if not, it asks activity if there is a local document it wants to give as a source option. activity replies with mime type, path, title, and human readable flag (whether to try to show it in the window) </li><li>extension brings up a window, which has buttons at top for activity and document</li> <li>those buttons show the thing in the window (if possible). If path is a file, the file; if it is a dir, a list view/ file viewer combo. </li><li>Dropdowns from these buttons allow you to open the {activity, document} in external editor which handles the mime type</li> <li>If path is a dir and external editor is launched, extension asks current activity to bundle it up for the external activity, and gets back a jobject id.</li></ol>My one question is whether there will ever be a case where an activity will want to give the option to see two or more different kinds of "source" besides the activity source. I think not; I think one "document" at a time is plenty. As an example: if you're in basicbrowse activity, you press view source, you have option of seeing python source of basicbrowse, or html of current page. If you're in superbrowse, you get options of seeing superbrowse source or (a bundle with html, css, svg, gif, jpg, subframe html, etc.). I think making each of those things available separately as independent entities just leads to a more complicated API for activity programmers with nearly no real gain. Do others agree? Jameson