Changes

== Detailed Description ==

== Detailed Description ==

==== UI modes ====

==== UI modes ====

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).

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.86+, Journal will load all installed plugins and provide possibility to switch between them, for <0.86 plugins will be formed in separated activities.

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.86+, Journal plugin will be packaged with sugar, other plugins could be packaged into activities and have separate code base. In 0.86+ environment, these activities will use plugins engine from current sugar, for <0.86 environments(and for 0.86+ glucose releases when plugin uses newer engine), plugins engine will be packaged into activity bundles.

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 activities is not a task for this feature proposal.

'''NOTE''' Separate activities is not a task for this feature proposal.

Browser provides backwards compatible and versioned plugins engine API:

Browser provides backwards compatible and versioned plugins engine API:

* ''v0'' engine for glucose-0.82/0.84

* ''v0'' engine for glucose-0.82/0.84/0.86

* ''v1'' engine for glucose-0.86(+)

* ''v1'' engine for glucose-0.88(+)

Engine provides all necessary functionality for plugins:

Engine provides all necessary functionality for plugins:

* 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

** for local objects(rich client for <0.86 and thin client for >=0.86)

** for local objects(rich client for <0.88 and thin client for >=0.88)

** for remote p2p objects

** for remote p2p objects

** for remote server objects

** for remote server objects