5,705
edits
Changes
Jump to navigation
Jump to search
Line 24:
Line 24: − + + + + + − ==== UI modes ====+ − − Unified Browser supports plugins for different UI modes: − * Journal objects-centric plugin − * Books plugin, Calibre-like(or so) for browsing books − * Audio plugin for browsing audio files − * Video plugin for browsing video files − * Plugin to browse .xol collections(instead of using sidebar in Browse) − * .. − − So, we could have plugins for different purposes i.e. Journal plugin could be very common/simple but something like plugin for Books/Video/etc can have some special UI features (that look redundant in Journal plugin). − − For sugar-0.88+, Journal will load all installed plugins and provide possibility to switch between them, for <0.88 plugins will be formed in separated activities. − − For sugar-0.88+, Journal plugin will be packaged with sugar, other plugins could be packaged into activities and have separate code base. In 0.88+ environment, these activities will use plugins engine from current sugar, for <0.88 environments (and for 0.88+ glucose releases when plugin uses newer engine), plugins engine will be packaged into activity bundles. − − '''NOTE''' Separate plugins/activities is not a task for this feature proposal. − − ==== Plugins engine ==== − − Browser provides backwards compatible and versioned plugins engine API: − * ''v0'' engine for glucose-0.84/0.86 − * ''v1'' engine for glucose-0.88(+) − − Engine provides all necessary functionality for plugins: − ** for local objects (rich client for <0.88 and thin client for >=0.88) − ** for remote p2p objects − ** for remote server objects − ** aggregated sources (combine several sources)
User:Alsroot/trash/Frame Panels (view source)
Revision as of 13:21, 26 November 2009
, 13:21, 26 November 2009→Detailed Description
== Detailed Description ==
== Detailed Description ==
Purposes to have special Journal plugins API instead of regular activities:
The reason to this feature is having Journal views for different purposes i.e. Journal plugin could be very common/simple but views for Books/Video/etc could have some special UI features. Another benefit of Journal plugins is that we can have non-core plugins and distribute them from ASLO.
Purposes to have special Journal plugins API in addition to activities API:
* security reasons, browsing Journal entries and launch/remove/change objects could be denied for regular activities in next sugar releases
* security reasons, browsing Journal entries and launch/remove/change objects could be denied for regular activities in next sugar releases
* Journal integration
* Journal integration
** fast access to plugin views
** ObjectChooser integration
Plugins API will provide necessary functionality:
* TreeViewModel as a source of objects; so, all pulugins should use TreeViewModel for list widgets
* TreeViewModel as a source of objects; so, all pulugins should use TreeViewModel for list widgets
* UI widgets, like TreeView, TableView, tag clouds etc.
* UI widgets, like TreeView, TableView, tag clouds etc.
* shell related procedures(like activate objects)
* shell related procedures(like activate objects)