Documentation/Maemo 5 Developer Guide/Porting Software/Introduction - Revision history

imported_>amigadave: tidy

2010-08-18T08:54:13Z

tidy

← Older revision		Revision as of 08:54, 18 August 2010
Line 5:		Line 5:
	* [https://vcs.maemo.org/svn/maemoexamples/tags/maemo_5.0/hildon-examples/ hildon-examples]		* [https://vcs.maemo.org/svn/maemoexamples/tags/maemo_5.0/hildon-examples/ hildon-examples]

			Much effort has been made in the design of Maemo platform to allow for easy porting of regular GNU/Linux desktop software to the mobile Maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.
	Much effort has been made in the design of Maemo platform to allow for easy porting of regular GNU/Linux desktop software to the mobile ~~maemo~~ environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.

	== Command Line Programs ==		== Command Line Programs ==
Line 14:		Line 13:
	== Programs with Graphical User Interface ==		== Programs with Graphical User Interface ==

	Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the ~~maemo~~ SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.		Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the Maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.

	Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5 \| Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.		Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5\|Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.

	[[Category:Development]]		[[Category:Development]]
	[[Category:Documentation]]		[[Category:Documentation]]
	[[Category:Fremantle]]		[[Category:Fremantle]]

imported_>amigadave: wikify slightly

2010-08-05T13:30:17Z

wikify slightly

← Older revision		Revision as of 13:30, 5 August 2010
Line 1:		Line 1:
	~~= Introduction =~~

	The following code examples are used in this chapter:		The following code examples are used in this chapter:

Line 10:		Line 8:
	Much effort has been made in the design of Maemo platform to allow for easy porting of regular GNU/Linux desktop software to the mobile maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.		Much effort has been made in the design of Maemo platform to allow for easy porting of regular GNU/Linux desktop software to the mobile maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.

	~~'''~~Command Line Programs~~'''~~		== Command Line Programs ==

	In most cases, porting software with no user interface is trivial and straightforward. First, the source code of a program is unpacked to the home directory of a Scratchbox user. Second, inside the ARMEL target ''configure'' and ''make'' are run. Then the compiled program can be tested on the device. Finally the software needs to be packaged so it can be distributed.		In most cases, porting software with no user interface is trivial and straightforward. First, the source code of a program is unpacked to the home directory of a Scratchbox user. Second, inside the ARMEL target <code>configure</code> and <code>make</code> are run. Then the compiled program can be tested on the device. Finally the software needs to be packaged so it can be distributed.

	~~'''~~Programs with Graphical User Interface~~'''~~		== Programs with Graphical User Interface ==

	Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.		Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.

imported_>amigadave: categorise

2010-02-12T12:47:20Z

categorise

← Older revision		Revision as of 12:47, 12 February 2010
Line 19:		Line 19:

	Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5 \| Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.		Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5 \| Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.

			[[Category:Development]]
			[[Category:Documentation]]
			[[Category:Fremantle]]

imported_>tapio at 14:55, 11 February 2010

2010-02-11T14:55:47Z

← Older revision		Revision as of 14:55, 11 February 2010
Line 3:		Line 3:
	The following code examples are used in this chapter:		The following code examples are used in this chapter:

	* [https://~~garage~~.maemo.org/svn/maemoexamples/~~trunk~~/maemo-sliders/ maemo-sliders]		* [https://vcs.maemo.org/svn/maemoexamples/tags/maemo_5.0/maemo-sliders/ maemo-sliders]
	* [https://~~garage~~.maemo.org/svn/maemoexamples/~~trunk~~/maemopad/ MaemoPad]		* [https://vcs.maemo.org/svn/maemoexamples/tags/maemo_5.0/maemopad/ MaemoPad]
	* [https://~~garage~~.maemo.org/svn/maemoexamples/~~trunk~~/hildon-examples/ hildon-examples]		* [https://vcs.maemo.org/svn/maemoexamples/tags/maemo_5.0/hildon-examples/ hildon-examples]

imported_>liox_lang_valid: /* Introduction */

2009-09-25T09:22:07Z

Introduction

← Older revision		Revision as of 09:22, 25 September 2009
Line 8:		Line 8:


	Much effort has been made in the design of ~~maemo~~ platform to allow for easy porting of regular GNU/Linux desktop software to the mobile maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.		Much effort has been made in the design of Maemo platform to allow for easy porting of regular GNU/Linux desktop software to the mobile maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.

	'''Command Line Programs'''		'''Command Line Programs'''

imported_>tatiana: Localization is not the part of Porting section anymore

2009-09-03T11:53:56Z

Localization is not the part of Porting section anymore

← Older revision		Revision as of 11:53, 3 September 2009
Line 18:		Line 18:
	Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.		Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.

	Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5 \| Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.		Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5 \| Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.

	~~'''Localization'''~~

	The localization of maemo applications is performed using the common ''gettext'' package. Translating applications to different languages is described in detail in section [localhost#sec:maemo_localization 16.4].

imported_>tatiana: /* Introduction */

2009-09-01T13:29:04Z

Introduction

← Older revision		Revision as of 13:29, 1 September 2009
Line 18:		Line 18:
	Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.		Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.

	Section [~~localhost#sec:maemo_porting 16.3~~] goes into the necessary details of porting an existing GTK+ application to maemo environment.		Section [[Documentation/Maemo 5 Developer Guide/Porting Software/Porting Existing GTK+ Application to Maemo 5 \| Porting Existing GTK+ Application to Maemo 5]] goes into the necessary details of porting an existing GTK+ application to maemo environment.

	'''Localization'''		'''Localization'''

	The localization of maemo applications is performed using the common ''gettext'' package. Translating applications to different languages is described in detail in section [localhost#sec:maemo_localization 16.4].		The localization of maemo applications is performed using the common ''gettext'' package. Translating applications to different languages is described in detail in section [localhost#sec:maemo_localization 16.4].

imported_>tatiana: added link to code examples, used in Migration section

2009-09-01T11:18:31Z

added link to code examples, used in Migration section

← Older revision		Revision as of 11:18, 1 September 2009
Line 5:		Line 5:
	* [https://garage.maemo.org/svn/maemoexamples/trunk/maemo-sliders/ maemo-sliders]		* [https://garage.maemo.org/svn/maemoexamples/trunk/maemo-sliders/ maemo-sliders]
	* [https://garage.maemo.org/svn/maemoexamples/trunk/maemopad/ MaemoPad]		* [https://garage.maemo.org/svn/maemoexamples/trunk/maemopad/ MaemoPad]
			* [https://garage.maemo.org/svn/maemoexamples/trunk/hildon-examples/ hildon-examples]

imported_>jeremiah: Minor syntax and grammar changes.

2009-08-29T16:44:44Z

Minor syntax and grammar changes.

← Older revision		Revision as of 16:44, 29 August 2009
Line 6:		Line 6:
	* [https://garage.maemo.org/svn/maemoexamples/trunk/maemopad/ MaemoPad]		* [https://garage.maemo.org/svn/maemoexamples/trunk/maemopad/ MaemoPad]

	Much effort has been made in the design of maemo platform to allow easy porting of regular GNU/Linux desktop software to the mobile maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.
			Much effort has been made in the design of maemo platform to allow for easy porting of regular GNU/Linux desktop software to the mobile maemo environment. An earlier chapter in this guide explained the basic tools that ease cross-compilation and help coping with the GNU autotools. This chapter gives pointers to the relevant guides focusing on the differences in the application programming and user interfaces.

	'''Command Line Programs'''		'''Command Line Programs'''

	In most cases, porting software with no user interface is trivial and straightforward. First, the source code of a program is unpacked to the home directory of a Scratchbox user. Second, inside ARMEL target ''configure'' and ''make'' are run. Then the compiled program can be tested on the device. Finally the software needs to be packaged.		In most cases, porting software with no user interface is trivial and straightforward. First, the source code of a program is unpacked to the home directory of a Scratchbox user. Second, inside the ARMEL target ''configure'' and ''make'' are run. Then the compiled program can be tested on the device. Finally the software needs to be packaged so it can be distributed.

	'''Programs with Graphical User Interface'''		'''Programs with Graphical User Interface'''

	~~The porting~~ of ~~an application that uses~~ GTK+ ~~for its graphical user interface begins~~ the same way as above. In addition ~~to this~~, the user interface ~~part~~ needs to be ~~refactored~~ to use Hildon instead of directly using GTK+. If the application uses any components not available in the maemo SDK, these must be also ported by the developer.		Porting of applications which use GTK+ starts the same way as described above. In addition, the user interface needs to be re-factored to use Hildon instead of directly using GTK+, this process is often called "hildonization". If the application uses any components not available in the maemo SDK, these must be also ported by the developer. In short, the developer is responsible for all library dependencies needed that are not already in the SDK.

	Section [localhost#sec:maemo_porting 16.3] goes into the necessary details of porting an existing GTK+ application to maemo environment.		Section [localhost#sec:maemo_porting 16.3] goes into the necessary details of porting an existing GTK+ application to maemo environment.

imported_>danielwilms: 1 revision

2009-08-25T15:05:20Z

1 revision

← Older revision	Revision as of 15:05, 25 August 2009
(No difference)