Multiplatform Programming Guide/fr: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		Cette page est le début d'un tutoriel sur l'écriture d'applications multiplatforme sur Lazarus. Il traitera des précautions à prendre pour qu'un programme puisse être facilement portable et de la façon de porter un programme déjà existant. Je vous invite à m'aider pour améliorer cet article.
2	2
3	3		## Introduction à la programmation multi-plateformes
4	4
5	5		### De combien de machines avez-vous besoin?
6	6
7	7		Pour répondre à cette question, vous devez d'abord déterminer qui seront vos utilisateurs et comment votre programme va être utilisé. Cette question dépend de l'endroit où vous déployez votre application.
8	8
9	9		Si vous développez des logiciels de bureautique, Windows est évidement la plateforme la plus importante, mais le fait d'inclure des versions pour Mac OS X et Linux peut parfois faire que votre logiciel sera choisi à la place d'un autre limité à une seule plateforme.
10	10
11	11		Le succès des différents systèmes d'exploitation varie beaucoup selon le pays, le type de logiciel ainsi que selon les personnes à qui vous destinez votre application. On ne peut donc pas définir de règles générales. A titre d'exemple, Mac OS X est très populaire en Europe de l'ouest. Il est par contre essentiellement limité à la vidéo et à l'audio en Amérique de Sud.
12	12
13	13		Dans beaucoup de projets, une seule plate-forme est pertinente et ce n'est pas un problème. Free Pascal et Lazarus sont tout à fait adaptés à l'écriture de logiciels destinés à une plateforme spécifique. Vous pouvez, par exemple, accéder à toute l'API de Windows pour écrire un logiciel bien intégré dans Windows.
14	14
15	15		Si vous développez un logiciel qui va tourner dans un serveur web, la plateforme la plus utilisée sera une variantes d'UNIX. Dans ce cas, peut-être que seuls Linux, Solaris, *BSD et d'autres systèmes UNIX seront logiquement votre plateforme cible. Vous pourrez aussi ajouter le support de Windows NT.
16	16
17	17		Une fois vous aurez maîtrisé le développement multi plateformes, vous pourrez normalement vous concentrer sur le problème que le logiciel doit résoudre et faire votre développement sur la plateforme à votre disposition ou sur celle où vous vous sentez le plus à l'aise. Ainsi, lorsque vous aurez réglé les problèmes de multi plateforme dans votre conception, vous pourrez ignorer les autres, comme si vous développiez pour une plateforme unique. Cependant, à un certain moment vous aurez besoin de tester le déploiement et le fonctionnement de votre programme sur les autres plateformes et il sera utile d'avoir un accès illimité à des machines qui utilisent les systèmes d'exploitation ciblés. Si vous ne voulez pas vous encombrer de plusieurs machines physiques, vous pouvez configurer un double boot Windows-Linux ou faire tourner Windows et Linux sur votre Mac dans une machine virtuelle comme Virtual PC, iEmulator ou VirtualBox.
18	18
19	19		## Programmation multi-plateforme
20	20
21	21		### Travailler avec les fichiers et les dossiers
22	22
23	23		Lorsqu'on travaille avec les fichiers et les dossiers, il est important d'utiliser des séparateurs de chemin et des codes de fin de ligne indépendants de la plate-forme. Voici une liste de constantes prédéclarées dans Lazarus à utiliser lors du travail avec les fichiers et les dossiers.
24	24
25	25		- PathSep, PathSeparator : séparateur de chemin lors de l'ajout de nombreux chemins en même temps (';', ...)
26	26		- PathDelim, DirectorySeparator : séparateur de répertoire pour chaque plate-forme ('/', '\\', ...)
27	27		- LineEnding : propre fin de ligne pour séquence de caractères (#13#10 - CRLF, \#10 - LF, ...)
28	28
29	29		Autre chose importante à noter : la sensibilité à la casse des systèmes de fichiers. Dans Windows, les noms des fichiers ne sont pas sensible à la casse. Ils le sont en revanche sur les plateformes Unix. Cela peut être la cause de bugs ennuyeux. Il faut donc que toute application portable utilise des noms de fichiers cohérents.
30	30
31	31		### Fichiers de configuration
32	32
33	33		vous pouvez utiliser la fonction [[doc:rtl/sysutils/getappconfigdir.html\|GetAppConfigDir]] de l'unité SysUtils pour obtenir un bon emplacement pour stocker les fichiers de configuration dans les différents systèmes. La fonction possède un seul paramètre, nommé Global. S'il est vrai, alors le répertoire retourné est un répertoire global, c'est à dire, valide pour tous les utilisateurs dans le système. Si le paramètre global est faux, alors, alors le répertoire est spécifique à l'utilisateur qui exécute le programme. Sur les systèmes qui ne prennent pas en charge les environnements multi-utilisateurs, ces deux répertoires peuvent être le même.
34	34
35	35		IL y a aussi le [[doc:rtl/sysutils/getappconfigfile.html\|GetAppConfigFile]] qui retournera un nom approprié pour un fichier de configuration d'application. Vous pouvez l'utiliser comme ça:
36	36
37	37		ConfigFilePath := GetAppConfigFile(False) + '.conf';
38	38
39	39		Dessous sont des exemples de la sortie de chemin d'accès par défaut des fonctions sur des différents systèmes:
40	40
41	41		program project1;
42	42
43	43		{$mode objfpc}{$H+}
44	44
45	45		uses
46	46		SysUtils;
47	47
48	48		begin
49	49		WriteLn(GetAppConfigDir(True));
50	50		WriteLn(GetAppConfigDir(False));
51	51		WriteLn(GetAppConfigFile(True));
52	52		WriteLn(GetAppConfigFile(False));
53	53		end.
54	54
55	55		La sortie dans un systeme GNU/Linux:
56	56
57	57		/etc
58	58		/home/felipe/project1
59	59		/etc/project1.cfg
60	60		/home/felipe/.project1
61	61
62	62		Vous pouvez remarquer que les fichiers de configuration globale sont stockés dans le répertoire /etc et que les configuration locales sont stockés dans un dossier caché le répertoire d'accueil de l'utilisateur. Les répertoires dont le nom commence par un point (.) sont cachés dans Linux. Vous pouvez créer un répertoire dans l'emplacement retourné par GetAppConfigDir et ensuite stocker les fichiers de configuration là.
63	63
64	64		La sortie de Windows XP:
65	65
66	66		C:\Programas\teste
67	67		C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project1
68	68		C:\Programas\teste\project1.cfg
69	69		C:\Documents and Settings\felipe\Configurações Locais\Dados de aplicativos\project1\project1.cfg
70	70
71	71		Notez que la fonction a recours au répertoire où la fonction stockera la configuration global dans windows.
72	72
73	73		La sortie de wondows 98:
74	74
75	75		C:\Programas\PROJECT1
76	76		C:\Windows\Configurações Locais\Dados de aplicativos\PROJECT1
77	77		C:\Programas\teste\PROJECT1.cfg
78	78		C:\Windows\Configurações Locais\Dados de aplicativos\PROJECT1\PROJECT1.cfg
79	79
80	80		La sortie dans Mac OS X:
81	81
82	82		/etc
83	83		/Users/philhess/.config/testfelipe1
84	84		/etc/testfelipe1.cfg
85	85		/Users/philhess/.config/testfelipe1.cfg
86	86
87	87		Note: Le recours à des UPX interfère avec l'usage des fonctions GetAppConfigDir et GetAppConfigFile.
88	88
89	89		Note: Dans la plupart des cas les fichiers de configuration sont des fichiers de préférences,qui devraient être des fichiers XML avec l'extension ".plist" et être stockés dans le répertoire /Library/Preferences ou ~/Library/Preferences avec des noms tirés du champ "Bundle identifier" dans Info.plist du paquet d'application. L'utilisation de Carbon qui appele CFPreference... est probablement la façon la plus facile de faire cela. Les fichiers .config dans le répertoire User sont une violation des lignes du guide de programmation.
90	90
91	91		### Les données et les fichiers de ressources
92	92
93	93		Une question très commune est où stocker les fichiers de données que qu'une application pourrait avoir besoin, comme les images, musiques, les fichiers XML, les fichiers de base de donnée, les fichiers d'aide, ect... Malheureusement il n y a pas de fonction multi-plateforme pour avoir le meilleur emplacement afin de chercher un fichier de donnée. La solution est d'implémenter différemment dans chaque plateforme en utilisant les IFDEF. Dans Windows, tu peux supposer simplement que les fichiers sont dans le même chemin d'accès que l'exécutable, ou en position qui lui est relative.
94	94
95	95		Dans la plupart des unix (comme Linux, BSDs, solaris, etc) , les informations peut être une chose comme: /usr/share/app_name or /opt/app_name
96	96
97	97		La plupart des programmes seront exécutés sans les privilèges d'un administrateur, pour cela les programmes multi-plateformes doivent toujours sauvegarder les fichiers d'informations dans un endroit ayant l'accès en lecture, mais pas forcement un accès en écriture, et les fichiers de configuration dans un endroit avec les droits de lecture et écriture.
98	98
99	99		Mac OS X is an exception among UNIXes. There the best way to deploy applications is using an application bundle, which includes all files your software will need. Then your resource files should be located inside the bundle, so it can be moved and continue working normally. You need to use CoreFoundation API calls to find the location of the bundle.
100	100
101	101		#### Example
102	102
103	103		This section presents a particular solution where under Windows the data files are stored on the same directory as the executable (or any other directory based on it, like MyDirectory + 'data' + PathDelim + 'myfile.dat'), and on Unixes it will be on a directory read from a configuration file. If no configuration file exists or it contains no info, then a constant ('/usr/share/myapp/') is utilized as the default directory.
104	104
105	105		The configuration file path is located with the GetAppConfigFile function from the Free Pascal Runtime Library.
106	106
107	107		Below is a full unit which you can use at your applications.
108	108
109	109		unit appsettings;
110	110
111	111		interface
112	112
113	113		{$ifdef fpc}
114	114		{$mode delphi}{$H+}
115	115		{$endif}
116	116
117	117		uses
118	118		{$IFDEF Win32}
119	119		Windows,
120	120		{$ENDIF}
121	121		Classes, SysUtils, Forms, IniFiles, constants;
122	122
123	123		type
124	124
125	125		{ TConfigurations }
126	126
127	127		TConfigurations = class(TObject)
128	128		private
129	129		ConfigFilePath: string;
130	130		public
131	131		{other settings as fields here}
132	132		MyDirectory: string;
133	133		constructor Create;
134	134		destructor Destroy; override;
135	135		procedure ReadFromFile(Sender: TObject);
136	136		procedure Save(Sender: TObject);
137	137		end;
138	138
139	139		var
140	140		vConfigurations: TConfigurations;
141	141
142	142		implementation
143	143
144	144		const
145	145		DefaultDirectory = '/usr/share/myapp/';
146	146
147	147		SectionGeneral = 'General';
148	148		SectionUnix = 'UNIX';
149	149
150	150		IdentMyDirectory = 'MyDirectory';
151	151
152	152		{ TConfigurations }
153	153
154	154		constructor TConfigurations.Create;
155	155		begin
156	156		{$ifdef win32}
157	157		ConfigFilePath := ExtractFilePath(Application.EXEName) + 'myapp.ini';
158	158		{$endif}
159	159		{$ifdef Unix}
160	160		ConfigFilePath := GetAppConfigFile(False) + '.conf';
161	161		{$endif}
162	162
163	163		ReadFromFile(nil);
164	164		end;
165	165
166	166		destructor TConfigurations.Destroy;
167	167		begin
168	168		Save(nil);
169	169
170	170		inherited Destroy;
171	171		end;
172	172
173	173		procedure TConfigurations.Save(Sender: TObject);
174	174		var
175	175		MyFile: TIniFile;
176	176		begin
177	177		MyFile := TIniFile.Create(ConfigFilePath);
178	178		try
179	179		MyFile.WriteString(SectionUnix, IdentMyDirectory, MyDirectory);
180	180		finally
181	181		MyFile.Free;
182	182		end;
183	183		end;
184	184
185	185		procedure TConfigurations.ReadFromFile(Sender: TObject);
186	186		var
187	187		MyFile: TIniFile;
188	188		begin
189	189		MyFile := TIniFile.Create(ConfigFilePath);
190	190		try
191	191		// Here you can read other information from the config file
192	192
193	193		{$ifdef Win32}
194	194		MyDirectory := MyFile.ReadString(SectionUnix, IdentMyDirectory,
195	195		ExtractFilePath(Application.EXEName));
196	196		{$else}
197	197		MyDirectory := MyFile.ReadString(SectionUnix, IdentMyDirectory,
198	198		DefaultDirectory);
199	199		{$endif}
200	200		finally
201	201		MyFile.Free;
202	202		end;
203	203		end;
204	204
205	205		initialization
206	206
207	207		vConfigurations := TConfigurations.Create;
208	208
209	209		finalization
210	210
211	211		FreeAndNil(vTranslations);
212	212
213	213		end.
214	214
215	215		and here example code of how to use that unit:
216	216
217	217		bmp := TBitmap.Create
218	218		try
219	219		bmp.LoadFromFile(vConfigurations.MyDirectory + 'MyBitmap.bmp');
220	220		finally
221	221		bmp.Free;
222	222		end;
223	223
224	224		## Windows specific issues
225	225
226	226		### Windows API Functions
227	227
228	228		Many Windows programs use the Windows API extensively. On crossplatform applications those functions cannot appear, or must be enclosed by a condition compile (e.g. {\$IFDEF Win32} ).
229	229
230	230		Fortunately many Windows API functions - the most often used - are implemented in a multiplatform way in the unit LCLIntf. This can be a solution for programs which rely heavily on the Windows API, although the best solution is to substitute these calls with true crossplatform components from the LCL. You can substitute calls to GDI painting functions with the TCanvas object, for example.
231	231
232	232		### On Unix there is no "application directory"
233	233
234	234		Many programmers are used to call ExtractFilePath(ParamStr(0)) or Application.ExeName to get the location of the executable, and then search for the necessary files for the program execution (Images, XML files, database files, etc) based on the location of the executable. This is wrong on unixes. The string on ParamStr(0) may contain a directory other then the one of the executable, and it also varies between different shell programs (sh, bash, etc).
235	235
236	236		Even if Application.ExeName could in fact know the directory where the executable is, that file could be a symbolic link, so you would get the directory of the link instead.
237	237
238	238		To avoid this read the sections about [[Multiplatform Programming Guide\|configuration files]] and [[Multiplatform Programming Guide\|data files]].
239	239
240	240		## Making do without Windows COM Automation
241	241
242	242		With Windows, Automation is a powerful way not only of manipulating other programs remotely but also for allowing other programs to manipulate your program. With Delphi you can make your program both an Automation client and an Automation server, meaning it can both manipulate other programs and in turn be manipulated by other programs.
243	243
244	244		Unfortunately, Automation isn't available on OS X and Linux. However, you can simulate some of the functionality of Automation on OS X using AppleScript.
245	245
246	246		AppleScript is similar to Automation in some ways. For example, you can write scripts that manipulate other programs. Here's a very simple example of AppleScript that starts NeoOffice (the Mac version of OpenOffice.org):
247	247
248		-	~~` tell application "NeoOffice"`\~~
249		-	~~` launch`\~~
250		-	~~` end tell`~~
	248	+	``` pascal
	249	+	tell application "NeoOffice"
	250	+	launch
	251	+	end tell
	252	+	```
251	253
252	254		An app that is designed to be manipulated by AppleScript provides a "dictionary" of classes and commands that can be used with the app, similar to the classes of a Windows Automation server. However, even apps like NeoOffice that don't provide a dictionary will still respond to the commands "launch", "activate" and "quit". AppleScript can be run from the OS X Script Editor or Finder or even converted to an app that you can drop on the dock just like any app. You can also run AppleScript from your program, as in this example:
253	255
254		-	~~` Shell('myscript.applescript');`~~
	256	+	```text
	257	+	Shell('myscript.applescript');
	258	+	```
255	259
256	260		This assumes the script is in the indicated file. You can also run scripts on the fly from your app using the OS X OsaScript command:
257	261
258		-	~~` Shell('osascript -e '#39'tell application "NeoOffice"'#39 +`\~~
259		-	~~` ' -e '#39'launch'#39' -e '#39'end tell'#39);`\~~
260		-	~~` {Note use of #39 to single-quote the parameters}`~~
	262	+	``` pascal
	263	+	Shell('osascript -e '#39'tell application "NeoOffice"'#39 +
	264	+	' -e '#39'launch'#39' -e '#39'end tell'#39);
	265	+	{Note use of #39 to single-quote the parameters}
	266	+	```
261	267
262	268		However, these examples are just the equivalent of the following Open command:
263	269
264		-	~~` Shell('open -a NeoOffice');`~~
	270	+	```text
	271	+	Shell('open -a NeoOffice');
	272	+	```
265	273
266	274		The real power of AppleScript is to manipulate programs remotely to create and open documents and automate other activities. How much you can do with a program depends on how extensive its AppleScript dictionary is (if it has one). For example, Microsoft's Office X programs are not very useable with AppleScript, whereas the newer Office 2004 programs have completely rewritten AppleScript dictionaries that compare in many ways with what's available via the Windows Office Automation servers.
267	275
268	276		While Linux shells support sophisticated command line scripting, the type of scripting is limited to what can be passed to a program on the command line. There is no single, unified way to access a program's internal classes and commands with Linux the way they are via Windows Automation and OS X AppleScript. However, individual desktop environments (GNOME/KDE) and application frameworks often provide such methods of Interprocess Communication. On GNOME see Bonobo Components. KDE has the KParts framework, DCOP. OpenOffice has a platform neutral API for controlling the office remotely (google OpenOffice SDK) - though you would probably have to write glue code in another language that has bindings (such as Python) to use it. In addition, some applications have "server modes" activated by special command-line options that allow them to be controlled from another process. It is also possible (Borland did it with Kylix document browser) to "embed" one top-level X application window into another using XReparentWindow (I think).
269	277
270	278		As with Windows, many OS X and Linux programs are made up of multiple library files (.dylib and .so extensions). Sometimes these libraries are designed so you can also use them in programs you write. While this can be a way of adding some of the functionality of an external program to your program, it's not really the same as running and manipulating the external program itself. Instead, your program is just linking to and using the external program's library similar to the way it would use any programming library.
271	279
272	280		## See Also
273	281
274	282		- <http://www.midnightbeach.com/jon/pubs/Kylix.html> A guide for Windows programmers starting with Kylix. Many of concepts / code snippets apply to Lazarus.
275	283		- <http://www.stack.nl/~marcov/porting.pdf> A guide for writing portable source code, mainly between different compilers.
276	284
277	285		---
278	286		From the Free Pascal wiki, page "Multiplatform Programming Guide/fr", as it stood on 2012-04-11 after a change by Milarepa, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history