User:Alsroot/trash/Frame Panels: Difference between revisions

Line 20:

== Detailed Description ==

~~This code follows [[Design Team/Proposals/Journal]] mockups.~~

==== UI modes ====

Line 35:

Line 33:

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.

Line 44:

Line 42:

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:

* 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 server objects

@@ Line 20: / Line 20: @@
 == Detailed Description ==
-This code follows [[Design Team/Proposals/Journal]] mockups.
 ==== UI modes ====
@@ Line 35: / Line 33: @@
 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.
@@ Line 44: / Line 42: @@
 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:
 * 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 server objects