Changes

Jump to navigation Jump to search
823 bytes removed ,  09:16, 2 July 2012
no edit summary
Line 1: Line 1: −
<noinclude>
  −
{{TOCright}}
  −
</noinclude>
  −
   
== Summary ==
 
== Summary ==
   −
Intermediate level [http://library.gnome.org/devel/gobject/stable/ GObject] based libraries group.
+
A set of C libraries to help with coding non-Python Sugar activities.
 
  −
See [[Platform Team/Scalable development model|Scalable development model]] to learn more about the initial intentions of Polyol.
      
== Concepts ==
 
== Concepts ==
Line 13: Line 7:  
[[File:polyol.png|500px]]
 
[[File:polyol.png|500px]]
   −
==== Glucose processes ====
+
* '''Glucose processes'''
 
+
*: Sugar core processes and dbus services.
Sugar core processes and dbus services.
+
* '''DBus'''
 
+
*: All communication between glucose level and activity process goes via dbus.
==== DBus ====
+
* '''Polyol'''
 
+
*: Intermediate level libraries:
All communication between glucose level and activity process goes via dbus.
+
*:* Glucose compatibility libraries (ds, shell, collab) will support several (popular among sugar deployments) glucose releases
 
+
*:* Other libraries are not tied to glucose directly
==== Polyol group ====
+
*: Key features:
 
+
*:* All libraries are written in Vala, i.e., based on pure GObjects, and could be used by non-python-based activities.
Intermediate level libraries:
+
*:* Activities (mostly not native sugar activities) could use only one library e.g. activity could use only ''ds'' library thus do not fetch additional dependencies like gtk+ (via ''gui'').
* Glucose compatibility libraries (ds, shell, collab) will support several (popular among sugar deployments) glucose releases
+
* '''Activity process'''
* Other libraries are not tied to glucose directly
+
*: Regular activities would not use glucose directly, rather they would only access glucose through the Polyol level.
 
  −
Key features of this level:
  −
* All libraries are written in Vala, i.e., based on pure GObjects, and could be used by non-python-based activities.
  −
* Each Polyol component has its own release schedule, i.e., there are no Polyol official releases (it looks like in Gentoo).
  −
* Activities could use these libraries on separate basis e.g. activity could use recent ''gui'' (to get access to last UI widgets) and old version of ''ds'' (because activity was coded against this particular version and new version has backward compatibility breakage in API).
  −
* Activities (mostly not native sugar activities) could use only one library e.g. activity could use only ''ds'' library thus do not fetch additional dependencies like gtk+ (via ''gui'').
  −
 
  −
==== Activity process ====
  −
 
  −
Regular activities would not use glucose directly, rather they would only access glucose through the Polyol level.<br>There is no need to code special activities, the sugar-toolkit API will be preserved, and activity developers will benefit because Polyol will support the recent sugar-toolkit API, e.g., they could use the new toolbars design even on Sugar 0.82.
      
== Components ==
 
== Components ==
   −
All libraries are C based and could contain bindings for various programming languages. Libraries use the same [http://git.sugarlabs.org/projects/polyol sources tree] but each component has its own 0install interface and versions (there will be a way to use entirely polyol as single package e.g. for GNU/Linux distribution needs since all benefits of separation vanishes in that case).
+
All libraries are C based and could contain bindings for various programming languages. Libraries use the same [http://git.sugarlabs.org/projects/polyol sources tree].
    
==== env ====
 
==== env ====
Line 67: Line 51:  
Bindings for this library (in contrast with bindings for other Polyol components) could contain not only wrappers for library itself, but also particular language specific code that makes process of creating sugar activities in this language more comfortable.
 
Bindings for this library (in contrast with bindings for other Polyol components) could contain not only wrappers for library itself, but also particular language specific code that makes process of creating sugar activities in this language more comfortable.
   −
== Build for non-0install usage ==
+
== Build from sources ==
    
Install required dependencies
 
Install required dependencies
Line 73: Line 57:  
* [http://live.gnome.org/Libgee gee] >= 0.5
 
* [http://live.gnome.org/Libgee gee] >= 0.5
   −
Download last [http://download.sugarlabs.org/sources/external/polyol/ tarball].
+
Download last [https://packages.sugarlabs.org/package/files?package=polyol&project=sdk tarball].
    
Build it:
 
Build it:
Line 88: Line 72:     
For each component, Polyol will install ''.pc'' file. So, after installing polyol, be sure that ''pkg-config'' will find ''.pc'' files e.g. setup ''PKG_CONFIG_PATH'' variable before using polyol.
 
For each component, Polyol will install ''.pc'' file. So, after installing polyol, be sure that ''pkg-config'' will find ''.pc'' files e.g. setup ''PKG_CONFIG_PATH'' variable before using polyol.
 +
 +
== Pitfalls ==
 +
 +
* Python binding libraries cannot be linked with C libraries from sugar-toolkit.
 +
*: Polyol names contain the {{Code|sugar}} prefix to reuse sugar-artwork as-is.
 +
 +
== Sources ==
 +
 +
* [http://git.sugarlabs.org/sdk/polyol Gitorious project].

Navigation menu