273
edits
Changes
Jump to navigation
Jump to search
Line 99:
Line 99: − One advantage of Sugar providing the content viewers versus packaging them as individual activities is that they can be extended by developers to create new activities.+ − Or, a Flash developer can develop a game in Flash but use Python to manage the toolbars. They would package their Python code and SWF file in a Unified bundle, and reference the sugar-swf-activity classes from their Python code.+ + +
→Content Viewer based Activities
==Content Viewer based Activities==
==Content Viewer based Activities==
Making Sugar provide the content viewers instead of releasing them as individual activities is that they can be extended by developers to create new activities.
For example, the WikiBrowse activity is based on the Browse classes. If Browse, is not installed, WikiBrowse cannot launch. With the source code to Browse part of Sugar, web-based activities can be built on top of the Content Viewer classes and extended with additional Python code such as a custom server or PyXPCom code.
For example, the WikiBrowse activity is based on the Browse classes. If Browse, is not installed, WikiBrowse cannot launch. With the source code to Browse part of Sugar, web-based activities can be built on top of the Content Viewer classes and extended with additional Python code such as a custom server or PyXPCom code.
As another example, the Gmail activity is a customized copy of an older (now broken) version of the Browse source code. With the content viewer source available, this would no longer be needed.
With the SWF content viewer to base on, a Flash developer can develop a game in Flash but use Python to add toolbars and GTK widgets. They would package their Python code and SWF file in a Unified bundle, and subclass the sugar-swf-activity classes in their Python code.
==Sugar changes==
==Sugar changes==