Getting started programming/lang-ja

This is an on-going translation

One Laptop per Childプロジェクトのために作業をすることをご検討くださりありがとうございます。このページは既存のプロジェクトに貢献したり、あるいはあなた自身の新しいプロジェクトをはじめるのに必要な答えを提供することを目的としています。Game Development Newbiesもあわせてご覧下さい。

Thank you for considering working on the One Laptop Per Child project. This page tries to provide you with the answers you need to get started either by contributing to existing projects or starting your own. See also Game Development Newbies

開発環境をセットアップする

OLPCのソフトウェア環境はGUI shell (Sugar)の走る相当に変更の施されたFedora Core Linuxシステムです。このプラットフォーム向けの開発には、結果的にOLPC環境と殆ど同じような動作環境のプラットフォームを操作する必要がでてくるでしょう。幸いにも多くの利用可能な選択肢があります。

The OLPC's software environment is a heavily modified Fedora Core Linux system running a custom GUI shell (Sugar). To develop for the platform you will eventually need access to a platform which runs in a manner substantially similar to the OLPC environment. Luckily there are many available options.

オプション 1 - sugar-jhbuild

エミュレーションされたXO環境を使うことに比べ、sugarのインストールには多くの時間とハードディスクの空きがセットアップに必要ですが、結果的により優れた環境を手に入れることができます。これがコア開発チームが使っている方法です。

Compared with using an Emulated XO, installing sugar takes more time and space to set up, but results in a better environment. This is what the core development team uses.

32-bit Linuxでの作業

sugar-jhbuildはOLPCソフトウェア群を走らせるのに必要なライブラリをセットアップできるもう一つの方法です。このやり方では、殆どの最近のLinuxディストリビューションで実用的な範囲で概してうまく動きます。いくつかのLinux(32-bit Ubuntu, 32-bit Fedora(?))では、"問題なく動きます"。ビルドシステム(jhbuild)自身は不安定ですが。その他のLinuxについては、再ビルドとエラーの訂正にかなりの時間を費やす必要があるかもしれません。ですので、エミュレーションには"問題なく動作する"linuxの利用を検討ください。

sugar-jhbuild builds a parallel set of the libraries required to run the OLPC software. This approach generally works reasonably well on most modern Linux distributions. On some linuxes (32-bit Ubuntu, 32-bit Fedora(?)), it "just works". Though the build system (jhbuild) can be fragile. On others, you may spend quite some time rebuilding and fixing errors to get a final working system, so consider running a "just works" linux in emulation.

仮想化Linuxを使うWindows/Mac/Linuxでの作業

エミュレータ(例えばParallels, qemu, vmwareなど）に構築された仮想化環境の32-bit Ubuntuでのsugar-jhbuild。

sugar-jhbuild, on a virtual 32-bit Ubuntu, inside of an emulator (eg, Parallels, qemu, vmware).

オプション 2 - エミュレートされたXO上で動かす

Unixを使い慣れた開発者（sshを通してコマンドラインでの操作を好む）にとって、XOのOSイメージをエミュレーションで動かすことはOLPCシステム向けソフトの開発をはじめる最もシンプルな方法です。それらはQemu, VMWareあるいはParallelsといった人気の有るエミュレーション/仮想化システムで走らせることができます。これらのイメージはあなたが普段使っている開発用ワークステーションでOLPC用に設定された仮想化マシンを走らせることができます。

これらの公式イメージはGUI IDEsやSVGグラフィックエディタを含んでいません。これらのイメージはあなたが実際に作業を行うワークステーション上で通常コマンドラインツール（VIMとか）やNFS（あるいはsshとか同種のもの）を使うことで利用可能です。

Running an XO OS image in emulation is, for Unix-friendly developers (those who like using command-line tools via ssh), the simplest way to start developing for the OLPC system. They can be run in one of the popular emulation/virtualisation systems, such as Qemu, VMWare or Parallels. These images allow you to run a virtual OLPC-configured machine on your regular development workstation.

These official images do not provide GUI IDEs or SVG graphics editors. They normally would be used either with command-line tools (e.g. VIM) or using NFS (or ssh, or similar) to a workstation on which you will do your actual coding.

オプション 3 - イメージあるいはLiveCDを使うLinux上でのSugar

開発者イメージは仮想化デスクトップマシンとしての利用を意図したものです。このイメージにはOLPCのラップトップよりもはるかに多くのソフトウェアが含まれています。これはSugar環境をサポートするよう更新されてきた開発者用のデスクトップマシンに似ています。例えばGUIのIDE群を含み、またGnomeの完全なデスクトップインすとレーションを含む、と一体具合にです。これらはエミュレートされた環境の中で開発者は全ての作業をこなすことを簡単にしています。

開発者イメージで作業をしている開発者は、実際のラップトップでは利用が不可能なソフトウェアに依存していないことをはっきりさせるために本物のLPCラップトップか公式イメージにおいて彼らの開発した成果物を必ずテストするようにせねばなりません。

2007年5月23日の段階では、4月上旬より開発者イメージは更新されていません。上記のやり方は意義を失いつつあるように思いますが？MitchellNCharity 18:13, 23 May 2007 (EDT)

いえ、いまでも十分意味があります。Linuxを使った開発者ではない人たちのために、開発者ビルドはまさに最初の1日から開発を始められるようにするという意味でますます重要とさえなってきているといえるでしょう。これらのイメージは作業にあたってGUI環境を好む開発者のための「ダウンロードして即コーディング開始するツール」となることを意図されています。Mcfletch 24 May 2007

それなら仮想のUbuntuの上でsugar-jhbuildを走らせるやり方に切り替えたほうが良いように感じますが。MitchellNCharity 09:02, 23 June 2007 (EDT)

このアドバイスをひっくり返したほうがよさそうですね。私たちが新しい開発者ビルドを入手できるようになるまでは、あなたは恐らくどこかほかを当たったほうがいいでしょう。結果として新しい開発者ビルドを作り準備することは優先順位が低くなりつつあります。Mcfletch 12 Aug 2007

Developer Images are intended to be used as virtual desktop machines. The images have far more software than is installed on the OLPC laptops. They resemble a developer's desktop machine which has been upgraded to support the Sugar environment. They tend to have GUI IDEs, full Gnome desktop installations and the like, which make it easy for developers to work entirely within the emulated environment.

Developers working on Developer Images should be sure to test their creations on real OLPC Laptops or official images in order to be sure that they do not have dependencies on software not available on the actual laptops.

As of 2007-May-23, the developer images have not been updated since early April. Is this approach depreciated? MitchellNCharity 18:13, 23 May 2007 (EDT)

No, it is *not* deprecated. For those who are not Linux developers the developer builds are much more likely to allow for starting to develop on day one. These images are intended to be download-and-start-coding tools for developers who prefer GUI environments for working. Mcfletch 24 May 2007

Might such developers be better off with running sugar-jhbuild on a virtual Ubuntu? MitchellNCharity 09:02, 23 June 2007 (EDT)

May as well reverse this advice. Until such time as we get new developer builds, yes, you probably need to go elsewhere. Getting new developer builds created is becoming a bit of a priority as a result. Mcfletch 12 Aug 2007

オプション 4 - 更新済みライブラリを使うLinux上のSugar

OLPCの環境に近くなるようにあなたのLinuxオペレーティングシステムを更新して下さい。そうすれば、必要とされるパッケージのほんのわずかな変更部分のためにより軽いビルドシステムを使うだけで済むでしょう。ただしこの場合しばしばあなたのLinuxディストリビューションを"安定版"のコンフィグレーションよりも新しい状態へ更新する必要がでてくる可能性があることを気に留めて置いてください。そのことによりあなたのシステムが不安定になるかもしれません。

2007年4月8日の段階（ただしFedora Core 6/7について）、GentooとUbuntu Feisty Fawnは可能な限り更新せねばならなことが分かっています。

2007年5月23日の段階では、Fedora Coreにおいてはこのやり方はあまり意味を成さなくなっています。またx86_64ではうまくいきません。MitchellNCharity 16:54, 23 May 2007 (EDT)

Update your Linux operating system to such a point that it resembles the OLPC environment. You then need only use the more fragile build system for a tiny fraction of the packages required. You should be aware that such upgrades often will require you to update well beyond the "stable" configurations for your Linux distribution, and as such may make your system unstable.

As of 2007-04-08 only Fedora Core 6/7, Gentoo and Ubuntu Feisty Fawn are known to upgrade reasonably well.

As of 2007-05-23 it appears this approach is deprecated on Fedora Core, and doesn't work with x86_64. MitchellNCharity 16:54, 23 May 2007 (EDT)

オプション 5 - 実物のXOラップトップを使う

ハードウェア開発者プログラム - 製造されているテスト用ユニットはまだほんのわずかしかありませんが、開発者は提案書を提出することが可能で、これによりテストと開発のためにこれらのうちの1台を受け取ることができます。

Hardware Developer's Program - while there are only a small number of test units being produced, developers can submit proposals to receive one of those units for testing and development.

動作環境

開発言語:

• 技術的には、任意の開発言語が使えます。
• Pythonを強く推奨します。好奇心旺盛な子供が中を見たときに"一つ傘の下の"単一の言語にするために
• Pythonの処理能力が十分でないときはC/C++を利用すべきです。しかし必要最小限にするようにしてください。できればうまくカプセル化されドキュメントの準備されたコンポーネントとするようにしてください。
• Smalltalkが使える開発者はeToys環境で作業をしたいと思うかもしれません。
• Javascriptがウェブベースのアプリケーションでは利用可能です。(GeckoかOperaエンジンのJavascriptを実装）

GUI環境:

• PyGTKかPyGTK派生の Sugarシステムを殆どの"ウィンドウ、アイコン、マウス、ポインタ"スタイルのGUIに利用してください。しかしながら、2007年4月21日の段階ではSugar"グラフィック"パッケージはFluxに含まれる点にご注意ください。
• Pygame SDLベースの2Dゲーム環境が"Sprites"を使った"Canvas"グラフィックスのために利用可能です。
• (Mozilla) XULRunnerがGeckoベースのアクティビティのために利用可能です。

オペレーティングスタック:

• ハードウェア
• Fedora Coreベースのオペレーティングシステム
• Bitfrost Security System
• Sugar GUIシェル

ライブラリ/モジュール:

• 開発を始める前に、どんなライブラリがインクルードされているかを確認するようにしてください。OpenGLのような"ごく一般的に利用可能な"いくつかのライブラリでさえ、（XOでは）利用可能で無い場合があります！
• 内部ストレージでの占有領域を最小にするためにサポートモジュールの選択は慎重に行ってください。例えばデータベースが必要な場合、MySQLではなくSqliteを利用してください。あるいは更にいいものとしてはdbmを使いましょう。
• もしどんなライブラリやモジュールが利用可能かどうか分からないときはお問い合わせください。

テスト/作業:

• 広く配布する前に公式イメージ（あるいは実物のXOラップトップ）であなたのアプリケーションをテストしてください。
• メモリ消費を抑え、パフォーマンスを改善するために、問題を引き起こしそうなPythonコードをCに置き換えることを検討ください。例えばCで記述されたrewrite of the hardware manager serviceはアプリケーション固有の散在するメモリを1.8Mbytesも節約します。256MbytesのRAMとスワップスペースもないXOラップトップでは、メモリの効率的利用が「使えるシステム」と「out-of-memory failuresによる信頼性の低いシステム」との間に大きな違いを生みます。
• GPL, LGPL, あるいはMITライセンスの元、あなたのソースコードを配布ください。

Languages:

• Technically any language is usable
• Python is strongly encouraged, to have a single language "under the hood" when the curious child looks inside
• C/C++ should be used where Python performance is unacceptable, but try to keep it to a minimum, preferably as standard well-encapsulated and documented components
• Smalltalk-speaking developers may wish to work within the eToys environment
• Javascript can be used in web-based applications (Gecko or Opera engine Javascript implementation)

GUI Environments:

• PyGTK or the PyGTK-derived Sugar system should be used for most "Window, Icon, Mouse, Pointer" type GUIs. Note, however, as of 2007-04-21 that the Sugar "graphics" package is in Flux.
• Pygame SDL-based 2D game environment can be used for "Canvas" graphics using "Sprites".
• (Mozilla) XULRunner can be used to develop Gecko-based activities

Operating Stack:

• Hardware
• Fedora Core based Operating System
• Bitfrost Security System
• Sugar GUI Shell

Libraries/modules:

• Check to see what libraries are included before you begin development. Even some "universally available" libraries, such as OpenGL, are not available!
• Carefully choose support modules to minimize your storage footprint, for instance if you need a database, choose Sqlite rather than MySQL. Or better yet, use dbm.
• If you are unsure what is supported, ask.

Testing/working:

• Test your application in an official image (or a physical laptop) before publishing broadly
• To conserve memory or improve performance, consider replacing problematic areas in your Python code with C. For example, a rewrite of the hardware manager service in C saved 1.8 megabytes of private dirty memory. On a machine with only 256 megabytes of RAM and no swap space, efficient use of memory can make the difference between a usable system and a system made unreliable by out-of-memory failures.
• Distribute your source code under the GPL, LGPL or MIT license.

動作環境

殆どの開発者はおそらくOLPCでの利用のためにアクティビティで作業をされていることと思います。この種の開発は、コアSugar開発者を除き、通常他の開発グループとさほど交流しなくても可能です。（コアSugar開発者の作業はアクティビティ開発者に直接影響を及ぼします。）

Most developers will probably be working on an Activity for use on the OLPC. This kind of development can normally be done with little interaction with other development groups, save for the core Sugar developers (whose work directly affects activity developers).

情報交換の場所

殆どのコアな開発者はIRCをインスタントメッセージングスタイルのコミュニケーションのために利用しています：

 irc.freenode.net #sugar

Sugarメーリングリストもまた広範囲なコメントとコラボレーションに利用されています。

 メーリングリスト情報

もしあなたが活動中の領域で多くの開発者を抱え、各地域レベルのディスカッションリストをセットアップしたいときはSugarメーリングリストに新しいディスカッションリストのリクエストをポストしてください。

現在活動中のディスカッションリストは下記のとおりです：

• アルゼンチン
• ブラジル
• インド
• トロント（カナダ）
• OLPCネパール
• OLPCネパール開発者向け

Most of the core developers use IRC for instant-messaging-style communications:

 irc.freenode.net #sugar

the Sugar mailing list is also used for broader comment and collaboration:

 List Information

If you have a large number of developers in a given area and would like to set up a local discussion list, post to the Sugar mailing list with a request for a new discussion list.

Current Active Local Discussion Lists:

• Argentina
• Brasil
• India
• Toronto (Canada)
• OLPC Nepal
• Developers OLPC Nepal

プロジェクトに対するリクエストとアイデア

ソフトウェアに関するアイデアは活動の状況と現在必要とされているツールの種類について述べています。もし活動についてあなたがアイデアをお持ちならば該当するカテゴリのリスト（もし必要なら新しいカテゴリを作成ください）にそれを追加してください。さらに詳細について説明するために新しいwikiページを作ることもできます。

Software ideas describes activity and tool types that are currently needed. If you have an idea for an activity, add it to the list in the appropriate category (create a new category if necessary). You can create a new wiki page to describe your idea in more detail.

既存プロジェクト

ソフトウェアプロジェクトは支援を必要とする現在活動中のプロジェクトについて述べています。プロジェクトの支援を決意されたならば、貴方のコンタクト情報、ホームページ（OLPC wikiのwikiページでもいいです）等などの情報と共にあなた自身をリストに追加してください。特に、XOで利用可能な様々なActivitiesはビルドの期限が近づくと支援を必要とします；もしあなたが既存のプロジェクトで手伝えるものを探しているならば、ここをチェックしてみてください。

Software projects describes the currently active projects that may need help. Once you have decided on a project, add yourself to the list along with your contact information, homepage (which may be a wiki page on the OLPC wiki), etceteras. In particular, the various Activities available on the XO may need help as build time draws near; if you're looking for an existing project to get your feet wet with, check there.

利用可能なリソース

開発者プログラムはOLPCプロジェクトのための一般的なプロジェクトマネージメント機能を提供しています。

The Developers Program provides general project management facilities for OLPC projects.

ドキュメント

チュートリアル

• 通常のGTKを使ったオリジナルのHelloWorldチュートリアル
• 手で書いたGTKではなくGTK+Gladeを使ったTuquitoのHello World!
• Red Hat マガジン
  • 記事「Introducing Sugar」は開発環境を構築するためのsugar-jhbuildの使い方について解説しています。
  • 記事「Anatomy of an Activity」は新しいアクティビティを作成するための基本的なHello Worldスタイルのイントロダクションについて解説しています。
  • PyGTKのゲームをXOに移植する はXOと一緒に配布されているBlock Partyゲームについて解説した非常に手の込んだチュートリアルです。

• Original HelloWorld Tutorial using regular GTK
• Tuquito's Hello World! using GTK+Glade rather than hand-coded GTK
• Red Hat Magazine
  • Introducing Sugar Article describing how to use sugar-jhbuild to set up a development environment
  • Anatomy of an Activity Basic Hello World style introduction to creating a new activity
  • Porting a PyGTK Game to the XO Very involved tutorial describing the Block Party game distributed with the XO.

リファレンス

以下の文書は開発プロセスの中で頻繁に参照する類のものです。

• Sugarアーキテクチャ はSugarのAPI群と仕様をカバーしています。
• ヒューマンインタラクションガイドライン(HIG) はSugarアクティビティのためのものです。
• Bitfrost summary (full spec) システムとユーザ間のアクティビティとそのインタラクションを制御するセキュリティシステムです。
• Sugar PyDoc は低レベルAPIについてのみ解説した文書ですが、著しく説明文が抜けています。(Good familiarisation projectがこの状況を改善するためにMarcoと作業をしているはずです。）
• Hippo PyDoc これも低レベルAPIについての解説文書ですが、もっと説明文を入れる作業が必要です。
• Software components システムに関係した様々なソフトウェアやライブラリ群について説明したいささか古いドキュメントです。
• Instructions はSugarユーザインタフェースを使う方法について述べてあります。
• Understanding sugar code はSugarの起動と停止、およびどのようにSugarがアクティビティと通信しているかについての概要が述べてあります。あなたのアクティビティが走る環境について理解するために役立ちます。
• Activity Bundles はパッケージングの構造について説明してあります。

These documents are frequently referenced during the development process.

• Sugar Architecture covers Sugar APIs and specifications
• Human interaction guidelines (HIG) for Sugar activities
• Bitfrost summary (full spec) the security system which will control activities and their interaction with the system and other users
• Sugar PyDoc just provides the raw API documentation, which is severely lacking in documentation strings (Good familiarisation project might be working with Marco to improve that situation)
• Hippo PyDoc again, just raw API documentation, needs lots of documentation effort
• Software components is a somewhat old document describing the various pieces of software and libraries involved in the system.
• Instructions on using the Sugar user interface
• Understanding sugar code provides an overview of how Sugar interacts with activities, including startup and shutdown, useful to understand the environment in which your activity will run
• Activity Bundles describes the packaging structure

関連情報

• デベロッパーのカテゴリ分類 は開発者に関係していることを示すタグが付けられているwikiのページを全て集めてあります。(見て回るのはちょっとやっかいです)
• 開発者プログラム コアシステムに関する開発に焦点をあててますが、アクティビティの開発者にとっても非常に有用な情報です。* Sugarコードスニペット
• OLPCに参加する - しばらく前に、直接開発が特に容易であった以前に記述されたものですが、支援を必要としているプロジェクトについての一般的解説です。(なので上流プロジェクトAFAICSで作業するよう強調されています）
• ゲーム開発の方法

Codeを書くのに役立つ資料：

• BlockParty アクティビティ全般にわたる構造について
• HelloMesh, ConnectあるはWriteはチューブについて。

{{{1}}}

よくある質問と答

Sugarでネットワークを使うにはどうすればいいですか?

• 内部での接続(その他のラップトップと) (Tubesを使います）
• 外部との接続（より広いインターネットへ）
• Activity Sharing｜アクティビティの共有（セッションの確立）
• その他一般的なPythonのネットワーキングについて
  • Twisted (イメージで入手可能？）
  • Asyncore
  • PyRO (Python remote objects)
  • XMLRPC/SOAP

• Internal (to other laptops) (use Tubes)
• External (to the wider internet)
• Activity Sharing (session establishment)
• Otherwise general Python networking
  • Twisted (will this be available on the images?)
  • Asyncore
  • PyRO (Python remote objects)
  • XMLRPC/SOAP

永続的なサーバやサービスを作るにはどうすればいいですか?

• 開始時にロードするよう登録するにはどうすればいいですか？
• メッセージにのみ対応してロードを実行するなんらかのdbusイベントはありますか？つまり、例えば生存イベントのような用意されているタイプのイベントが発生するまでロードしない、ということですが。
  • はい、まがりなりにも、サービス群は.serviceファイルに定義されています。これらのサービス群は名前付けされたサービスとそれを提供する実行イメージと一致しています。従って用意されている名前付けされたサービスに対するリクエストを取り扱うハンドラを登録できます。しかし依然としてそのサービスが何かから呼ばれるようにお膳立てする必要があります。

• How do I register for start-time loading?
• Is there any dbus event service for loading only on response to messages? That is, not loading until there is an event of a given type, such as a presence event?
  • Yes, of a sort, services are defined in .service files, these match a named service to an executable which is to provide that service. Thus one can register to handle requests for a given named service, but you still need to arrange to have that service called by something.

特殊なハードウェアにアクセスするにはどうすればいいですか?

カメラ

• カメラからシングルフレームをgstreamer経由でキャプチャするようv412のスクリプトを書く必要があります。サンプルコードについてはsugar/shell/intro/glive.pyをご覧下さい。
• コマンドラインから以下を実行してみてください：gst-launch-0.10 v4l2src ! ffmpegcolorspace ! pngenc ! filesink location=foo.png
• 右も参照ください：カメラをプログラムする
• Have to script v4l2 via gstreamer to capture a single frame from the camera. See sugar/shell/intro/glive.py for sample code
• Try this from the command line: gst-launch-0.10 v4l2src ! ffmpegcolorspace ! pngenc ! filesink location=foo.png
• See also: Programming the camera

{{{1}}}

ビデオカメラとしてのカメラ(v4l2?)

• gstreamer(gstモジュール)経由で利用可能な一般的なv412デバイスです。
  • もしハードウェアを持たない場合、一般的なv412ソースを使ってインタラクティブにカメラをシミュレートすることができます。（多くの安いウェブカムがこのタイプのソースを提供してます）
  • テスト駆動開発のためには、（例えば普通のファイルとかを使って）ファイルソースを使うようあなたのコードをフックしてやれば、任意のgstreamerソースを利用可能です。
• 開発コンソールから次のコマンドを試してみてください：gst-launch-0.10 v4l2src ! ximagesink　（そうすると画像が開発コンソールウィンドウのうしろに現れるはずです。
• 右も参照ください：Programming the camera

• Is a regular v4l2 device available via gstreamer (gst module)
  • If you do not have hardware, you can simulate the camera interactively with an regular v4l2 source (many cheap web-cams provide this type of source)
  • For test-driven development, you can use any gstreamer source (such as a regular file), hooking up your code to use a file source instead of a v4l2src
• Try this from a terminal in the developer console: gst-launch-0.10 v4l2src ! ximagesink (The image will appear behind the developer console window so you'll need to move the window aside.)
• See also: Programming the camera

指向性パッド/ボタン類

• これらはそれら固有のX key namesを持っています。
• 現在4ボタンセットは矢印（カーソル）キーにマップされています。
• ２つの別々のボタンが???（ページアップ／ページダウン）キーにマップされています。

• Have their own X key names
• Currently 4-button set mapped to arrow (cursor) keys
• Two separate buttons mapped to ??? (pageup/pagedown)

ドローイングパッド(スタイラスパッド）

• スタイラスモードに入る・出るを切り替えるにはどうすればいいですか？
• インタプリテーションパラメータをセットするには？

• How to switch in/out of stylus mode?
• How to set interpretation parameters?

オーディオポートプローブ

• どのようにアクセスすればいいですか？
  • アクセスしたときに何が出力されるのでしょう？（覚えておいていただきたいのですが、私（開発者）は往々にして実際のハードウェアデバイスを持ち合わせないことが多いのです）

• How to get access?
  • What's going to come out when I get access (keeping in mind I (the developer) likely won't have the actual hardware available)

スクリーンのモード切替コード

• バックライトのon/off
• バックライトの輝度
• MODE_MONO_LUMA, MODE_CSWIZZLE, MODE_COL_AAの8種類（大きくは4種類）全ての設定をセットすること
• 問い合わせ、変更、そしてスクリーン表示方向の制限
• 処理能力、あるいは移植の容易性のために低解像度に落とす。例えば600x450あるいは400x300など。

Displayも合わせてご覧下さい。

• backlight on/off
• backlight brightness
• set all 8 (4 distinct) settings for MODE_MONO_LUMA, MODE_CSWIZZLE, MODE_COL_AA
• query, change, and restrict screen orientation
• drop to a lower resolution for performance or ease of porting, such as 600x450 or 400x300

See also Display.

自分のアクティビティGUIを作るにはどうすればいいですか?

• Cairo, Pygame や GTK を直接そのまま使えますか？
  • Sugar自身のGUIインタフェースは"sugar.graphics"内部パッケージを使ってGTKから派生したライブラリ(Hippo)を使って記述されています。このパッケージは現在Fluxの内部にあり、APIが安定するまではこれを使って新しくプロジェクトを始めるべきではありません。とりあえずのところはあなたのプロジェクトのGUIにはGTKかPyGame(SDL)をお使いください。
• どうやれば非GTK（あるいは非Qt）アプリケーションはSugarと完全に通信できるでしょうか？
  • 今のところ簡単にはできません。
  • Sugarは全てのアクティビティに対し存在する必要の有るサーバとコミュニケーションするのにカスタマイズされたdbusメッセージを使っています。将来的にはこれによる制限は緩和されるかもしれません。
    • Pythonでラッパーを作ることで簡単に"修正"することはできます。（例えばClassicGnomeアクティビティとか）
    • 必要とされる内部サービスを提供するためにGTKイベントループを使って様々なDBUSサービスを書くことができます。（つまり要不要に関わらず、全てのプロセスにGTKがロードされねばならない、ということを意味します）
    • 埋め込まれたGObjectイベントループと協調するあなたのコアなイベントループに変更できます。（例えばPyGameがこれを可能にします）あなたのプロセスのメモリスペースにGObjectをロードする必要があるということをちょっとだけ注意して。
• GUIはどれくらい柔軟である必要があるでしょうか？
  • Xサーバからのリサイズと回転イベントをハンドリングできる必要があります。
  • 右から左への記述文字への対応を含む国際化／ローカライゼーションをハンドリングできる必要があります。
• ベストな開発手法は何でしょうか？：
  • Sugarの外で書き、完成させてデバッグし、そして移植することでしょうか？
    • PowerPCベースの古いMacでは往々にしてこのアプローチがベストです。
  • Sugarで書き、システムの中でテストとデバッグをするには？
    • 実用レベルの処理能力を発揮できるエミュレーションシステムをセットアップするか、Sugarをサポートするようあなたのシステムをアップグレードすれば可能です。
• HippoCanvasはどう動いているのでしょう？

• Can I just use Cairo, Pygame or GTK directly?
  • Sugar's own GUI interface is coded in a GTK derived library (Hippo), using an internal "sugar.graphics" package. This package is currently in flux and you should not likely start new projects using it until the API stabilises. In the meantime please use GTK or PyGame (SDL) for you project's GUI.
• How can a non-GTK (or Qt) app fully interact with Sugar?
  • At the moment it cannot do this easily.
  • Sugar is using custom dbus messages to communicate with a server that must be present for every activity. That restriction may be relaxed in the future.
    • Can be easily "fixed" by creating a wrapper in Python (e.g. the ClassicGnome activity)
    • Can write various DBUS services using a GTK event loop to provide the required introspection services (implies that GTK must be loaded by every process, regardless of whether it is needed)
    • Can alter your core event loop to cooperate with an embedded GObject event loop (PyGame allows this, for instance), with the small concern that this requires loading GObject into your process' memory space
• How flexible does the GUI need to be?
  • Should be able to handle a resize-and-rotate event from the X server
  • Should be able to handle internationalisation/localisation, including to right-to-left-written scripts
• What's the best development approach:
  • Write outside Sugar, finish and debug, then port?
    • For older PowerPC-based Macs, this is likely the best approach
  • Write to Sugar, test and debug within the system?
    • Usable if you can set up a reasonably-performing emulated system or upgrade your system to support Sugar directly
• How does HippoCanvas work?

自分のアクティビティをパッケージするにはどうすればいいですか?

• in-processアクティビティから作業をするにはどうすればいいですか？（develop registration)
  • setup.py develop
  • アクティビティをスタートするためにsugar-activityを利用することができます。しかし手動でそれを閉じねばなりません。（Sugar GUIを使います：フレームを表示して、そしてアクティビティアイコンをトップバーに持って行きます。1秒ほどその上で待ち、そしてクローズをクリックします（えぇ、実際そんな感じで不恰好ではあります）
• バイナリエクステンションを作るにはどうすればいいですか？
• ユーザがダイナミックにダウンロードできるようなパッケージをどう作ればいいですか？
• パッケージのアップデートをどうユーザに知らせればいいですか？
  • largeあるいはcommonのPythonパッケージをどう使えばいいですか？
    • Numpy
    • Matplotlib
    • MySQL or PostgreSQL client code
    • Twisted
    • Zope Interfaces
    • Pygsear or other PyGame extensions
  • 私が書いた多くのアプリケーションの一番上にベースパッケージを提供するにはどうすればいいですか？

• How do I work from an in-process activity (develop registration)?
  • setup.py develop
  • You can use sugar-activity to start the activity, but you have to manually close it (using the Sugar GUI: show the frame, then move to the activity icon on the top bar, hover for a second, then click close (yes, it's really that awkward))
• How do I produce a binary extension?
• How do I make my package available for users to download dynamically?
• How do I tell users about updates to the packages?
• How do I share code between activities?
  • How do I use (large, common) Python packages?
    • Numpy
    • Matplotlib
    • MySQL or PostgreSQL client code
    • Twisted
    • Zope Interfaces
    • Pygsear or other PyGame extensions
  • How do I provide my own base packages on top of which I have written dozens of applications?

アプリケーション間でファイルを共有するにはどうすればいいですか?

現段階での計画は、基礎となっているシステムによりファイル共有を可能とする手段を提供することです。すなわち、同じプロパティとハッシュを持つファイルをコピーしたことを単純にシステムは検知し、そしてそれらを２つのアクティビティ間で共有するというものです。

Plan at the moment is to have file-sharing handled by the underlying system. That is, the system will simply notice that you have duplicate files with the same properties and hash and will share them between the two activities.

Sugarのアクティビティをテストするにはどうすればいいですか?

• Sugarをスタートさせてください。そしてbashシェルを起動します。次にsugar環境変数を設定するために"sugar-jhbuild shell"を走らせます。最後にアクティビティを走らせるために"sugar-activity YourActivityName"を使います。この出力はあなたのローカルシェルに吐き出されます。

• Start sugar, start a bash shell, run "sugar-jhbuild shell" to set up the sugar environment variables, then use "sugar-activity YourActivityName" to run the activity with output going to your local shell

Sugarのアクティビティをデバッグするにはどうすればいいですか?

あなたがSugarのアクティビティをコマンドラインからスタートさせているなら、標準的なPythonのコマンド：

 import pdb
 pdb.set_trace() 

をアクティビティにインサートできます。そしてアクティビティの実行状況を1行ずつ実行するPythonのデバッガを使えます。これを実施すると作業をしている間あなたのアプリケーションが"フリーズ"したような状態になることに注意ください。これによって画面表示上の問題が発生するかもしれません。

If you start your Sugar activity from the command line, you can insert a standard Python:

 import pdb
 pdb.set_trace() 

command into your activity and then use the Python debugger to step through your activity's behaviour. Note that this will "freeze" your application while you are working, so you may have display issues.

ラップトップのemacsで編集するにはどうすればいいですか?

• このファイルをラップトップにコピーしてMicroEMACSをインストールしてください。
• Emacsの使用感を期待しているとすれば、Zileの方が近いかもしれません。このrpmファイルを入手ください。

• Install MicroEMACS by copying this file to the laptop.
• Zile may be closer to what you expect from Emacs install this RPM this rpm file to get it.

USBドライブをマウントするにはどうすればいいですか?

通常USBドライブを使う場合は、ラップトップにUSBキー（スティック型メモリ）を差し込めばHALが自動的に処理してくれます。しかしながら、もしマシーンを起動したときにすでにUSBキーがささってたりあるいはHALがキーを認識しない場合はマウントが完了しない可能性があります。このような場合、キーを手動でマウントするのに以下の手順をお試しください：

• Linuxシェルモードに入る
• 右のコマンドでrootになる：$ su
• その後、マウントする場所を作成：　$ mkdir /mnt/usb
• そしてドライブをマウントする：　$ mount /dev/sda1 /mnt/usb
• はずす前にアンマウントするのを忘れないで：　$ umount /mnt/usb
• もし何かうまくいかないときは、USBキーがデバイスとしてマウントされるように、/etc/fstabにマウントポイント、デバイス、そしてファイルシステムが含まれるように編集しなければなりません。

Normally this is done automatically by the HAL when you plug the USB key into the laptop. It will show up as a directory in the /media folder. If, however, you had the USB key in when you started the machine, or the HAL doesn't recognize the key, you may not get the mount completed. In that case you can try manually mounting the key:

• Enter the linux shell mode
• First become root: $ su
• Then make a place to mount it: $ mkdir /mnt/usb
• Then mount the drive: $ mount /dev/sda1 /mnt/usb
• Don't forget to unmount it before removal: $ umount /mnt/usb
• If anything fails you should edit your /etc/fstab file to include the mount point, device, and filesystem for the device to mount.