tomeu -- excellent! thanks for helping make progress on this. tomeu wrote: > http://dev.laptop.org/~tomeu/viewsource.py > > This approach has a good thing that is that works everywhere, but has > a major problem: doesn't let activities override it and handle > themselves the view source key event. This is very bad for activities > like Etoys, the ones produced by Pippy or activities that would prefer > to display the source code for the _content_ loaded in that moment > (Browse).
the ultimate fallback would simply be a URL, with which Browse could take you to a (hopefully friendly) source browser on the web somewhere -- to browse CVS or git, for instance, or even just to an upstream program-specific website where more information is available. as you implied, flexibility is the key. > Alternative 1: Move it to sugar-toolkit, would be available to all > python activities, and activities would be able to override it easily. > Inconvenient: non-python activities wouldn't benefit from it. > > Alternative 2: Add a mechanism for the shell to know if an activity > wishes to provide its own view source window. It could be done by > adding one more D-Bus method or by adding one more property to > activity.info. Inconvenient: adds complexity to activity development. an addition to activity.info, with sensible defaults, would be the best bet, i think. default behaviors could include going to bundled source, as you've implemented, and/or using the "activity_source" URL that many activities provide on the download page on the wiki. paul =--------------------- paul fox, [EMAIL PROTECTED] _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
