Talk:OLPC Python Environment: Difference between revisions
No edit summary |
m (Reverted edits by 125.18.15.99 (125.18.15.99); changed back to last version by Jcfrench) |
||
(13 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
=== Fix links to MacOS X, Windows instructions === |
|||
Will the SVG part of gecko be included? |
|||
These instructions are '''very''' out of date, and do not work. They should be fixed and updated by someone with experience. |
|||
That's part of the plan, yes. - Blizzard |
|||
Someone new trying to install [[Sugar]] will be turned away if they have to go through all those steps to end up with something that is not functional. |
|||
It might be better to point people to the QEMU instructions. |
|||
---- |
---- |
||
Line 18: | Line 21: | ||
:What is the difference between the [[OLPC Python Environment]] and [[Sugar]]? From their current descriptions, they sound identical. I don't think [[OLPC Python Environment]] should be mistaken for "application development environment" (e.g. what libraries, Python modules, etc are available) since they may not be Python-centric and will not stabilized for probably quite some time. --[[User:SamatJain|SamatJain]] 11:55, 5 July 2006 (EDT) |
:What is the difference between the [[OLPC Python Environment]] and [[Sugar]]? From their current descriptions, they sound identical. I don't think [[OLPC Python Environment]] should be mistaken for "application development environment" (e.g. what libraries, Python modules, etc are available) since they may not be Python-centric and will not stabilized for probably quite some time. --[[User:SamatJain|SamatJain]] 11:55, 5 July 2006 (EDT) |
||
::The majority of application developers will be domain specialists, not programmers. For instance they will be scientists or teachers and they need straightforward development tools like Python to work with. If an educator sits down on their Windows machine and develops an application with Python and GTK, then only a small amount of work would need to be done to adapt it to the OLPC. The intent of this page: [[OLPC Python Environment]] is to have a description of the basic Python-based environment that is available for these developers to work with. |
|||
== OLPC developers, please spend a few minutes updating these pages == |
|||
Now that some extensive system documentation is appearing on the Wiki such as the Human Interface guidelines, it is time to update and extend the instructions for setting up a development environment. Application developers should be able to do all their work on their current OS, Windows, OSX, or some *IX flavour, until they get to the final testing stages. We need instructions for how to get a workable APPLICATIONS DEVELOPMENT environment working on each of these OSes. |
|||
This is quite different from SYSTEMS development which must be done on Fedora Core Linux. |
|||
It is possible that the best way to do non-Fedora development is to use QEMU and work in the emulator, for instance it may be necessary to have a working dbus in order to develop a Python activity. If so, then this should be clearly indicated on this set of pages including the limitation that leads to using QEMU. It is possible that at some future time, that limitation will disappear so it is important to explain the reasoning. |
|||
:QEMU is a pretty decent tool which allows an alpha developer or tester to see what the OLPC Sugar environment will be. A reasonably tech savy guy can get out to a shell, and really explore the OLPC environment and inner workings. But if you are emulating OLPC via QEMU, a lot of basic tools you might need as an application developer just do not exists. I understand the footprint of the image has to be small, but the environement doesn't have git, wget, rpm, or lots of other basic tools I don't need them all, but I need one. The OLPC main image does not yet support direct application development. Building a working sugar application development environment on a non-linux laptop is nigh impossible. (sigh) |
|||
::I don't know if you've tried this, but they offer a [[OS_images#Image_variants |development image]] in addition to the standard OLPC images. These images contain ''yum'', among other things, which means you can pull standard Red Hat packages into the image. I didn't try git, etc., but I was able to install the full version of vim using yum. wget and rpm are apparently included by default as well. —[[User:Leejc|Leejc]] 17:39, 22 February 2007 (EST) |
|||
:::That was the one trick I needed. Now, I have an image which runs in emulation and I can program against. Thanks so much Lee! -[[User:Jcfrench]] 16:32, 27 Feb 2007 (EST) |
Latest revision as of 04:46, 12 April 2007
Fix links to MacOS X, Windows instructions
These instructions are very out of date, and do not work. They should be fixed and updated by someone with experience.
Someone new trying to install Sugar will be turned away if they have to go through all those steps to end up with something that is not functional.
It might be better to point people to the QEMU instructions.
When you are doing the planning for a Setting Up a Sugar Development Environment on Windows page could you possibly arrange for it to be arranged so that one can download one .exe executable from the web and then running that executable installs it all automatically please? Some of the open source projects that one sees seem to assume great proficiency with unix and/or building up software systems and choosing this module and that module and unpacking tar and z something files. I feel that it needs a straightforward way for people to get the Sugar Development Environment set up with every step explained, so that they can start to use it rather than need to start trying to figure out how to get it installed.
- Sugar is currently under heavy development. The focus is on development, not testing--once the focus shifts an easy-to-use executable will surely become available. --SamatJain 11:58, 5 July 2006 (EDT)
Don't combine with Sugar at this point
It may make sense to combine this with SUGAR after it has stabilized but for now, we need some guidance for application developers, not systems developers. These people will be using Python as their main, or only development tool. They need help in getting Sugar running purely as a test environment for their app, not the whole thing that is used for more general system testing (dbus) or usability testing.
Right now the Sugar developers are maintaining pages oriented to people who want to help build SUGAR itself and that is a good way to keep things separated at this time.
- What is the difference between the OLPC Python Environment and Sugar? From their current descriptions, they sound identical. I don't think OLPC Python Environment should be mistaken for "application development environment" (e.g. what libraries, Python modules, etc are available) since they may not be Python-centric and will not stabilized for probably quite some time. --SamatJain 11:55, 5 July 2006 (EDT)
- The majority of application developers will be domain specialists, not programmers. For instance they will be scientists or teachers and they need straightforward development tools like Python to work with. If an educator sits down on their Windows machine and develops an application with Python and GTK, then only a small amount of work would need to be done to adapt it to the OLPC. The intent of this page: OLPC Python Environment is to have a description of the basic Python-based environment that is available for these developers to work with.
OLPC developers, please spend a few minutes updating these pages
Now that some extensive system documentation is appearing on the Wiki such as the Human Interface guidelines, it is time to update and extend the instructions for setting up a development environment. Application developers should be able to do all their work on their current OS, Windows, OSX, or some *IX flavour, until they get to the final testing stages. We need instructions for how to get a workable APPLICATIONS DEVELOPMENT environment working on each of these OSes.
This is quite different from SYSTEMS development which must be done on Fedora Core Linux.
It is possible that the best way to do non-Fedora development is to use QEMU and work in the emulator, for instance it may be necessary to have a working dbus in order to develop a Python activity. If so, then this should be clearly indicated on this set of pages including the limitation that leads to using QEMU. It is possible that at some future time, that limitation will disappear so it is important to explain the reasoning.
- QEMU is a pretty decent tool which allows an alpha developer or tester to see what the OLPC Sugar environment will be. A reasonably tech savy guy can get out to a shell, and really explore the OLPC environment and inner workings. But if you are emulating OLPC via QEMU, a lot of basic tools you might need as an application developer just do not exists. I understand the footprint of the image has to be small, but the environement doesn't have git, wget, rpm, or lots of other basic tools I don't need them all, but I need one. The OLPC main image does not yet support direct application development. Building a working sugar application development environment on a non-linux laptop is nigh impossible. (sigh)
- I don't know if you've tried this, but they offer a development image in addition to the standard OLPC images. These images contain yum, among other things, which means you can pull standard Red Hat packages into the image. I didn't try git, etc., but I was able to install the full version of vim using yum. wget and rpm are apparently included by default as well. —Leejc 17:39, 22 February 2007 (EST)
- That was the one trick I needed. Now, I have an image which runs in emulation and I can program against. Thanks so much Lee! -User:Jcfrench 16:32, 27 Feb 2007 (EST)