Sugar (Italiano)

From ArchWiki
Revision as of 13:29, 12 April 2010 by Veleno77 (talk | contribs) (Created page with ' {{i18n|Sugar}} {{translateme}} {{note|La pagina è attualmente in traduzione. Temporaneamente, fare riferimento a quella inglese}} Category:Desktop environments (Italiano) […')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Sugar (Italiano)#)
Note: La pagina è attualmente in traduzione. Temporaneamente, fare riferimento a quella inglese

A product of the OLPC initiative, Sugar is a Desktop Environment akin to KDE and GNOME, but geared towards children and education. If you have a young son, daughter, brother, sister, puppy or alien, the best way to introduce them to the world of Arch Linux is by deploying an Arch/Sugar platform and then forgetting about it. That's the beauty of Arch Linux (TM) - Deploy and Forget (But Know How to Deploy).

But wait..where art thou, O Sugar?

That's right. To lead such a good life, you need at least some Sugar-related packages in at least AUR.

Getting Started

Building from AUR

The esiest way is to use yaourt or a similar aur helper.

yaourt -S sugar

Building a Bundle

This is a cool build system provided by the developers that allows one to download and build Sugar almost in its entirety. You will be told what you need, and of course, it will not help if what you need has not yet been packaged for us mighty Archers.

The resulting project can then be offered as a bundle. This method of building should not be encouraged, since it is not "modular". A likely analogy is the easy-e17 script, except that we are in the opposite situation whereby there are no modular packages and thus no group - yet. Adding the provision is a safety measure, .eg:

pkgdesc="The Sugar environment and applications built with jhbuild"
provides=('sugar-desktop') # as in provides=('e')

But as soon as someone uploads a component of the build/Sugar as a separate package, it must be part of the group (and the bundle package will automatically conflict), eg.:

pkgdesc="The Sugar environment toolkit"
groups=('sugar-desktop' 'sugar-desktop-base')

Note: It might be possible to use the new split functions of makepkg here, in which case it will end up as a modular build :)

Building a Modular Group

This is the more appropriate route to take. Here is the current list of noted dependencies, acquired by inspecting the build trees of distributions supported by Sugar (Gentoo in particular):

# Syntax: pkgname .. :-> location + comment1 + comment2 ..

espeak			 :-> [community]
squeak			 :-> [unsupported] + outdated + needs patching for sugar
evince			 :-> [extra] + needs patching for sugar
pyabiword		 :-> [unsupported]
python-cjson		 :-> [community]
python-telepathy	 :-> [community]
gstreamer0.10-espeak	 :-> [unsupported]
olpcsound		 :-> [unsupported]
telepathy-glib		 :-> [community]
xulrunner		 :-> [extra]
telepathy-gabble	 :-> [community]
telepathy-salut		 :-> [community]
hippo-canvas		 :-> [unsupported]

And the bash-fu to install all existing packages (if you have saved the above in a file called sugar.todo):

~# pacman -S $(grep ":->" sugar.todo | grep -v unsupported | awk '{print $1}')

The above basically filters the output, first matching a string with grep, then leaving out matches with grep -v, and finally showing only the first coloumn of stdout with awk.

The following are "Level 2" dependencies:

abiword-devel		 :-> [unsupported] + required by pyabiword

The Applications

Depedency tree

Below is the dependency tree of sugar 0.86

   |  |--libxklavier
   |  |--pygobject
   |  |--gtk2
      |  |--librsvg
      |     |--gtk2
      |     |--libcroco
      |  |--dbus-python
      |  |--xapian-python-bindings
      |  |--python-cjson
      |  |--sugar-base
      |     |--pygobject
      |     |--python-decorator
         |  |--pygobject
         |  |--python-decorator


Now you have a working Sugar environment, it is time to populate it with activities such as a browser, a calculator, an image viewer or games and toys. They almost all have the same building procedure, a Template:Filename that calls functions shipped with sugar. Below is a typical Template:Filename: Template:File You may need squeak to run some activities (like etoys).


  • Activity building procedure is not made for packaging and using --prefix can be dangerous if the application uses this path internally. I think the correct way to do this would be to patch the installation procedure in sugar so it accept an argument such as --destdir=.
  • I suggest that we prefix sugar activities packages in AUR with sugar-activity-.
  • About groups according to the official site, the desktop itself consitute the glucose group. Main activities are part of fructose. And sucrose is constituted by both glucose and fructose and represents what should be distributed as a basic sugar desktop environment.
  • Below is a list of basic activities we should probably provide in AUR: