[Sugar-devel] View source redesign

Jameson Quinn jameson.quinn at gmail.com
Wed Dec 3 13:54:27 EST 2008

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:

   1. user presses view source
   2. extension asks activity (over dbus) if it wants to handle this one by
   3. 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)
   4. extension brings up a window, which has buttons at top for activity
   and document
   5. 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.
   6. Dropdowns from these buttons allow you to open the {activity,
   document} in external editor which handles the mime type
   7. 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.

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20081203/91e59db6/attachment.htm 

More information about the Sugar-devel mailing list