joliclic blog

Aller au contenu | Aller au menu | Aller à la recherche

mardi, mai 24 2011

Distribuer votre appli XULRunner - 2.4 - Empaqueter un rpm

This post exists also in english

Ce billet fait partie d'une série sur comment déployer une application XULRunner. Voir le préambule pour le contexte.

2 - Linux

2.4 Empaqueter un rpm

2.4.1 Préalable

Dans cette partie nous allons créer un paquet rpm, pour les distributions basée sur rpm, comme Red Hat, Fedora, Suse,... (j'ai testé uniquement sur Fedora, merci de me faire savoir si vous rencontrez des problèmes sur les autres).

Nous pouvons créer ce rpm aussi bien depuis d'autres distributions Linux, basées sur Debian par exemple (c'est ce que je fais), nous avons juste besoin de l'executable rpmbuild, et pour celà il suffit d'installer rpm :

apt-get install rpm

Quelques liens de documentation :

Je suppose que nous n'avons pas besoin de compilation pour notre appli, mais si ce n'est pas le cas, compiler simplement avant l'empaquètement (malgré le fait que ce soit déconseillé dans ce guide).

2.4.2 Fichiers RPM

pour créer un rpm, nous sommes supposé paramétrer une configuration utilisateur pour la création de tout rpm. Mais il est possible de faire celà dans un dossier local, c'est ce que nous allons faire.

Nous devons créer les dossiers suivants, et un fichier myapp.spec :

    |- samples_chapter_2/
|- myapp/
|- rpmbuild/
|- BUILD/
|- RPMS/
|- SOURCES/
|- SPECS/
|- SRPMS/
|- myapp.spec

En fait c'est la même structure que pour un environnement général de création rpm, mais local.

Le fichier .spec est le 'script' utilisé par rpmbuild pour créer le rpm. Il est supposé utiliser une archive source au format tar.gz, que nous allons créer spécialement pour lui plus tard.

Voici le contenu de notre spec :

Name:           myapp
Version: 1.0
Release: 1%{?dist}
Summary: simple Hello World powered by XULRunner.

Group: Development/Tools
License: MPLv1.1 or GPLv2+ or LGPLv2+
URL: http://example.com/myapp/
Source: myapp-1.0.tar.gz
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id} -un)

#BuildRequires:
Requires: firefox >= 3.6

%description
simple Hello World
Powered by XULRunner.

%prep
%setup

%build

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_libdir}
cp -R myapp %{buildroot}%{_libdir}/
mkdir -p %{buildroot}%{_bindir}

ln -s %{_libdir}/myapp/myapp.sh %{buildroot}%{_bindir}/myapp

mkdir -p %{buildroot}%{_datadir}/applications
cp data/myapp.desktop %{buildroot}%{_datadir}/applications/

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/16x16/apps
cp data/icons/icon16.png \
%{buildroot}%{_datadir}/icons/hicolor/16x16/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/22x22/apps
cp data/icons/icon22.png \
%{buildroot}%{_datadir}/icons/hicolor/22x22/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/32x32/apps
cp data/icons/icon32.png \
%{buildroot}%{_datadir}/icons/hicolor/32x32/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/48x48/apps
cp data/icons/icon48.png \
%{buildroot}%{_datadir}/icons/hicolor/48x48/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/scalable/apps
cp data/icons/icon48.svg \
%{buildroot}%{_datadir}/icons/hicolor/scalable/apps/myapp.svg

%post
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
if [ -x %{_bindir}/gtk-update-icon-cache ]; then
%{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor;
fi

%postun
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
if [ -x %{_bindir}/gtk-update-icon-cache ]; then
%{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor;
fi


%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)
%{_bindir}/myapp
%{_libdir}/myapp
%{_datadir}/applications/myapp.desktop
%{_datadir}/icons/hicolor/16x16/apps/myapp.png
%{_datadir}/icons/hicolor/22x22/apps/myapp.png
%{_datadir}/icons/hicolor/32x32/apps/myapp.png
%{_datadir}/icons/hicolor/48x48/apps/myapp.png
%{_datadir}/icons/hicolor/scalable/apps/myapp.svg
#%doc

%changelog
* Fri Oct 8 2010 John Doe <johndoe@example.com> 1.0-1
- first publication

Voyons en détail certaines entrées de ce fichier :

Name ne devrait contenir aucun caractère blanc.

Version doit contenir uniquement des chiffres (et des points), pas de chaîne comme "beta".

L'entrée Group doit être choisie dans la liste du fichier /usr/share/doc/rpm/GROUPS . Vous devez l'avoir sur votre ordinateur avec l'installation de rpm.

Release est la version du rpm pour cette version de l'appli, et %{?dist} sera remplacé par rpmbuild par la distribution courante. Celà ne sera pas complété sur une distribution non rpm (comme Debian), vous pouvez le supprimer si vous le désirez.

Pour l'entrée License, vous devez choisir un mot clé court (short keyword) dans cette liste.

L'entrée Source doit correspondre exactement au tar.gz que nous créerons plus tard.

La ligne BuildArch: noarch spécifie que notre appli n'est pas spécifique à l'architecture. Si votre appli contient du code compilé, vous devez supprimer cette ligne, et un rpm spécifique à l'architecture courante sera construit.

La valeur de BuildRoot est une valeur habituelle.

BuildRequires est commenté (avec un #), comme nous n'avons pas de compilation.

Enfin, l'entrée Requires contient les autres paquets qui sont nécessaires au fonctionnement de notre appli. Vous pourriez en ajouter d'autres, séparés par des virgules (,). Notez que vous ne pouvez pas déclarer de dépendances alternatives, comme pour un deb. C'est pourquoi nous déclarons Firefox et non XULRunner comme dépendance, dans le cas éventuel où le Firefox de la distribution n'est pas basée sur XULRunner.

Par la suite nous copierons notre archive tar.gz dans le dossier SOURCES.
Puis la section %prep et l'instruction %setup la décompresseront dans le dossier BUILD.
La section %build est vide, parce que nous n'avons pas de compilation à faire.

Dans la section %install, nous installons notre appli.
Ce sont des commandes shell, le dossier courant de travail est la source tar.gz non compressée. %{buildroot} est la racine de l'installation local de notre appli, ce sera la racine de l'ordinateur / lors de l'installation réelle.
%{_libdir}, %{_bindir}, et %{_datadir} correspondent respectivement à /usr/lib/, /usr/bin/, et /usr/share/. Je suppose que c'est le cas pour les principales distributions basées sur rpm, si je me trompe, merci de me corriger, car il faudrait alors redéfinir certaines variables.
Donc dans cette section, nous recréons le dossier initial buildroot. Puis nous créons le lien vers notre lanceur dans /usr/bin/, copions notre appli dans /usr/lib/, et copions notre fichier desktop et nos icônes aux bons emplacements dans /usr/share/.

les sections %post et %postun déclarent quelques actions après que notre appli sera installée ou désinstallée. Nous mettons à jour la base des icônes pour le gestionnaire de fenêtre.
Si l'appli prend en charge certains types mime, i.e. peut ouvrir certains type de fichier, celà doit être spécifier dans le fichier .desktop . Et vous devez ajouter le code suivant dans ces sections %post et %postun :

if [ -x /usr/bin/update-desktop-database ]; then
update-desktop-database &> /dev/null || :
fi

La section %files est obligatoire, et contient la liste complète des fichiers/dossiers installés par notre appli.

Enfin, le format de la section %changelog, est décrite dans cette doc.

2.4.3 Créer le rpm

Maintenant que nous avons tout ce dont nous avons besoin, nous allons créer un script pour créer une "fausse" archive source pour rpmbuild, qui contiendra notre appli, notre fichier desktop, et nos icônes. Nous placerons cette archive dans le dossiers SOURCES, puis invoquerons rpmbuild localement avec notre fichier spec. Et en fait, nous ferons tout celà dans un dossier temporaire, pour laisser nos sources propres.

Note: rmpbuild semble bugger si il y a des espaces dans le chemin du dossier de travail, donc faites attention avec le nom des (sous)dossiers où vous placez les sources.
Le script suivant s'arrêtera si c'est le cas.

Voilà ce script :

#!/bin/bash

# exit the script on errors
set -e

TMP_DIR=./tmp
SRC_VERSION=1.0

# get the absolute path of our TMP_DIR folder
TMP_DIR=$(readlink -f -- "$TMP_DIR")

# re-create the TMP_DIR folder
rm -rfv "$TMP_DIR"
mkdir -v "$TMP_DIR"

# copy the rmpbuild tree folder
cp -rv rpmbuild/* "$TMP_DIR/"

# create a source tar.gz archive for rpmbuild into SOURCES
mkdir -v "$TMP_DIR/myapp-$SRC_VERSION"
cp -rv myapp "$TMP_DIR/myapp-$SRC_VERSION/"
cp -rv data "$TMP_DIR/myapp-$SRC_VERSION/"
cd "$TMP_DIR"
# clean eventual tempory files
find . -type f -name *.*~ -exec rm {} \;
tar -zcvf "$TMP_DIR/SOURCES/myapp-$SRC_VERSION.tar.gz" \
"myapp-$SRC_VERSION"
cd -
rm -rv "$TMP_DIR/myapp-$SRC_VERSION"

# rmpbuild seems to have a bug, it can't handle a _topdir with whitespace
if [ -n "$(echo "$TMP_DIR" | grep '[ ]')" ]; then
echo "the path '$TMP_DIR' contains whitespace, rpmbuild will failed. script aborted!"
exit 1
fi

# build the rpm from our spec, specify our local build tree
rpmbuild --define="_topdir $TMP_DIR" -bb "$TMP_DIR/myapp.spec"

# and finally copy our created rpm in to into the current folder
cp -v "$TMP_DIR/RPMS/noarch/myapp-$SRC_VERSION-1.noarch.rpm" ./

Pour créer notre rpm, dans un terminal :

  • cd samples_chapter_2
  • sh ./build_rpm.sh

Et en résultat nous avons finalement le fichier myapp-1.0-1.noarch.rpm dans le dossier myapp-src :) .

Nicolas Martin

Vous pouvez télécharger tous les exemples de ce chapitre 2 (Linux) dans l'archive samples_chapter_2.tar.gz .

L'application myapp, de developer.mozilla.org, est dans le Domaine Public.

L'icône utilisée est issue du Tango Desktop Project, et est dans le Domaine Public.

Toutes les autres données ajoutées, et les fichiers en exemple, sont dans le Domain Public également.

Distribute your XULRunner app - 2.4 - Package as rpm

Ce billet existe aussi en français

This post is part of a series about how to package a XULRunner application.
See the preamble for the context case.

2.4 Package as rpm

2.4.1 Prerequisites

In this part we will create a rpm package, for rpm based distributions, like Red Hat, Fedora, Suse,... (I have tested only with Fedora, please let me know if there's any problems for others).

We can create this rpm from other Linux distributions as well, Debian based for example (that's what I do), we just need the rpmbuild executable, we have just to install rpm:

apt-get install rpm

Some documentation links:

I suppose we don't have any needed compilation, but if you have some, simply do it before packaging (despite the fact this is not recommended in this guide).

2.4.2 RPM files

To build a rpm, we're supposed to setup a user configuration for all rpm creation. But it is possible to do it in a local folder, that's what we will do.

We need to create the following folders, and a myapp.spec file:

    |- samples_chapter_2/
|- myapp/
|- rpmbuild/
|- BUILD/
|- RPMS/
|- SOURCES/
|- SPECS/
|- SRPMS/
|- myapp.spec

In fact this is the same structure than the required rpm environnement, but locally.

The .spec file is the 'script' used by rpmbuild to create the rpm. It is supposed to use a source tar.gz archive, that we will build especially later.

Here's the content of our spec:

Name:           myapp
Version: 1.0
Release: 1%{?dist}
Summary: simple Hello World powered by XULRunner.

Group: Development/Tools
License: MPLv1.1 or GPLv2+ or LGPLv2+
URL: http://example.com/myapp/
Source: myapp-1.0.tar.gz
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id} -un)

#BuildRequires:
Requires: firefox >= 3.6

%description
simple Hello World
Powered by XULRunner.

%prep
%setup

%build

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_libdir}
cp -R myapp %{buildroot}%{_libdir}/
mkdir -p %{buildroot}%{_bindir}

ln -s %{_libdir}/myapp/myapp.sh %{buildroot}%{_bindir}/myapp

mkdir -p %{buildroot}%{_datadir}/applications
cp data/myapp.desktop %{buildroot}%{_datadir}/applications/

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/16x16/apps
cp data/icons/icon16.png \
%{buildroot}%{_datadir}/icons/hicolor/16x16/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/22x22/apps
cp data/icons/icon22.png \
%{buildroot}%{_datadir}/icons/hicolor/22x22/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/32x32/apps
cp data/icons/icon32.png \
%{buildroot}%{_datadir}/icons/hicolor/32x32/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/48x48/apps
cp data/icons/icon48.png \
%{buildroot}%{_datadir}/icons/hicolor/48x48/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/scalable/apps
cp data/icons/icon48.svg \
%{buildroot}%{_datadir}/icons/hicolor/scalable/apps/myapp.svg

%post
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
if [ -x %{_bindir}/gtk-update-icon-cache ]; then
%{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor;
fi

%postun
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
if [ -x %{_bindir}/gtk-update-icon-cache ]; then
%{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor;
fi


%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)
%{_bindir}/myapp
%{_libdir}/myapp
%{_datadir}/applications/myapp.desktop
%{_datadir}/icons/hicolor/16x16/apps/myapp.png
%{_datadir}/icons/hicolor/22x22/apps/myapp.png
%{_datadir}/icons/hicolor/32x32/apps/myapp.png
%{_datadir}/icons/hicolor/48x48/apps/myapp.png
%{_datadir}/icons/hicolor/scalable/apps/myapp.svg
#%doc

%changelog
* Fri Oct 8 2010 John Doe <johndoe@example.com> 1.0-1
- first publication

Let see in detail some entries of this file:

The Name should not contain any whitespace characters.

The Version must contain only number and digit, no string like "beta".

The Group entry must be chosen in the list in the /usr/share/doc/rpm/GROUPS file. You should have it on your computer since you have installed rpm.

The Release is the version of the rpm for this version of the app, and %{?dist} will be replaced by rpmbuild by the current distribution. It will not be completed on a non rpm distribution, you can remove it if you want.

For the License entry, you must choose a short keyword from this list.

The Source entry must match exactly the tar.gz that we will create later.

The BuildArch: noarch line specify that our app is not architecture specific. If your app contains some compiled code, you must remove this line, and a rpm specific to the current architecture will be build.

The BuildRoot value is a usual one.

The BuildRequires is commented (with a #), as we have no compilations.

Finally, the Requires entry contains the other packages that are needed by our app. You could add others, separated by comma (,). Note that you can't declare alternative dependencies like with deb. That's why we declare Firefox and not XULRunner as dependencies, in the eventual case where the Firefox of the distribution is not XULRunner based.

Later we will copy the tar.gz archive of our app into the SOURCES folder.
Then the %prep section and the %setup instruction will unpack it into the BUILD folder.
The %build section is empty, because we have no compilation to do.

In the %install section, we install our app.
These are some shell commands, the current working directory is the unpacked source tar.gz. %{buildroot} is the root of the local installation of our app, this will be the computer root / in the real installation.
%{_libdir}, %{_bindir}, and %{_datadir} corresponds respectively to /usr/lib/, /usr/bin/, and /usr/share/. I guess that's the case for main rpm based distros, If I'm wrong, please correct me, it means that some these variables should be redefined.
So in this section, we re-create the initial buildroot folder. Then we create the link to our launcher in /usr/bin/, copy our app in /usr/lib/, and copy the desktop file and our icons into the right location in /usr/share/.

The %post and %postun sections declare some actions after that our app will be installed and uninstalled. We update the icons database for the windows manager.
If the app handle some mime types, i.e. can open some type of files, this should be specified in the .desktop file. And you must add the following code in these %post and %postun sections:

if [ -x /usr/bin/update-desktop-database ]; then
update-desktop-database &> /dev/null || :
fi

The %files section is required, and contains the complete list of files/folders installed by our app.

Finally, the format of the %changelog section, is described in this doc.

2.4.3 Create the rpm

So now that we have all that we need, we will create a script to create a fake source archive for rpmbuild, which contains our app, our desktop file, and our icons. We will place this archive in the SOURCES folder, then invoke rpmbuild locally with our spec file. And in fact, we will doing all of this in a temporary folder, to let our sources clean.

Note: rmpbuild seems to bug if there's some whitespace in the path of the working folder, so be careful with the name of the (sub)directories where you place your sources.
The following script will abort if this is the case.

Here this script:

#!/bin/bash

# exit the script on errors
set -e

TMP_DIR=./tmp
SRC_VERSION=1.0

# get the absolute path of our TMP_DIR folder
TMP_DIR=$(readlink -f -- "$TMP_DIR")

# re-create the TMP_DIR folder
rm -rfv "$TMP_DIR"
mkdir -v "$TMP_DIR"

# copy the rmpbuild tree folder
cp -rv rpmbuild/* "$TMP_DIR/"

# create a source tar.gz archive for rpmbuild into SOURCES
mkdir -v "$TMP_DIR/myapp-$SRC_VERSION"
cp -rv myapp "$TMP_DIR/myapp-$SRC_VERSION/"
cp -rv data "$TMP_DIR/myapp-$SRC_VERSION/"
cd "$TMP_DIR"
# clean eventual tempory files
find . -type f -name *.*~ -exec rm {} \;
tar -zcvf "$TMP_DIR/SOURCES/myapp-$SRC_VERSION.tar.gz" \
"myapp-$SRC_VERSION"
cd -
rm -rv "$TMP_DIR/myapp-$SRC_VERSION"

# rmpbuild seems to have a bug, it can't handle a _topdir with whitespace
if [ -n "$(echo "$TMP_DIR" | grep '[ ]')" ]; then
echo "the path '$TMP_DIR' contains whitespace, rpmbuild will failed. script aborted!"
exit 1
fi

# build the rpm from our spec, specify our local build tree
rpmbuild --define="_topdir $TMP_DIR" -bb "$TMP_DIR/myapp.spec"

# and finally copy our created rpm in to into the current folder
cp -v "$TMP_DIR/RPMS/noarch/myapp-$SRC_VERSION-1.noarch.rpm" ./

To create our rpm, in a terminal:

  • cd samples_chapter_2
  • sh ./build_rpm.sh

And as result we have finally the file myapp-1.0-1.noarch.rpm in the myapp-src folder :) .

Nicolas Martin

You can download all the samples of this chapter 2 (Linux) in the samples_chapter_2.tar.gz archive.

The myapp application, from developer.mozilla.org is in the Public Domain.

The icon used is from the Tango Desktop Project, and is in the Public Domain.

All added data, and sample files, of this chapter 2, are in the Public Domain too.

lundi, mai 23 2011

Distribute your XULRunner app - 2.3 - Special case, deb for Maemo

Ce billet existe aussi en français

This post is part of a series about how to package a XULRunner application.
See the preamble for the context case.

2.3 Special case : deb for Maemo

2.3.1 Maemo generalities

Maemo is a Linux, Debian based, distribution, for Mobile. And Firefox Mobile, aka Fennec, is available on this platform.
Fennec, like the desktop version of Firefox, is able to launch a XULRunner application via the -app argument.

So, a priori, we can launch any XULRunner applications. Of course, we should care of the specificities of mobile devices, small screen (but with high resolution), and touch screen. That's not the purpose of this howto. But as is, our app should work.

Because this platform is Debian based, we will distribute our app with a deb. We have just to adapt some parts of the previous chapter to the specificities of Maemo.

We can find some information in the Maemo Wiki.

2.3.2 Adapt the launcher

The change is that we invoke Fennec rather than Firefox.
The new launcher, myapp.sh:

#!/bin/sh

CUR_DIR=$(dirname $(readlink -f "$0"))

if [ -x /usr/bin/fennec ]; then
/usr/bin/fennec -app "$CUR_DIR/application.ini" $@
elif [ -x /usr/bin/xulrunner ]; then
/usr/bin/xulrunner "$CUR_DIR/application.ini" $@
else
echo "Error: unable to find Fennec or XULRunner!"
fi

2.3.3 A new file system organization - Where place our app

On Maemo, due to the memory space on mobile devices, the applications should reside in the folder /opt/ rather than in /usr/lib/ or /usr/share/.

So, we will copy our app in /opt/myapp/.
A sub-directory would possible too, /opt/myorganization/myapp/ for example.

For the icons, we will use different dimensions than for the desktop, like Fennec does itself: a 26x26px png, a 40x40px png, and a 48x48 svg.
Their final locations change a little too, they must be placed in:

  • /usr/share/icons/hicolor/26x26/hildon/myapp.png
  • /usr/share/icons/hicolor/40x40/hildon/myapp.png
  • /usr/share/icons/hicolor/scalable/hildon/myapp.svg

The location of the .desktop file change too, it must be placed into /usr/share/applications/hildon/ .

The .desktop file and the images are not so heavy, we can put them as is, but it should be possible to place them in our main app folder and use symbolic links too.

2.3.4 Additions to the .desktop file

Some information can be found in this page of the Maemo Wiki.

Some additional keys can be used in the desktop file. Not all that I add are documentated, but they seems to be used by a lot of programs, perhaps for some older version of Maemo.
Here's some lines added to our desktop file:

X-Icon-Path=/usr/share/icons
X-Window-Icon=myapp
X-Window-Icon-dimmed=myapp
X-Osso-Type=application/x-executable

2.3.5 Changes to the Debian files

To avoid to overwrite the generic deb created in the previous chapter, we will rename this new deb package for Maemo. We will use 'myapp-mobile'. To be consistent with the debhelper process, here the list of all this concerned changes:

  • In the changelog file, the line myapp (1.0-1) unstable; urgency=low becomes myapp-mobile (1.0-1) unstable; urgency=low

  • In the control file, the value for the Source and Package fields is changed to myapp-mobile

  • The file myapp.links is renamed as myapp-mobile.links

Other changes to the control file:

According to this documentation, we must choose a Section in this list:

  • user/desktop
  • user/development
  • user/education
  • user/games
  • user/graphics
  • user/multimedia
  • user/navigation
  • user/network
  • user/office
  • user/science
  • user/system
  • user/utilities

We can add extra data to the control file, used to build the deb.
The first is XB-Maemo-Display-Name: MyApp .

The second is a base64 icon, used by the application manager of Maemo, XB-Maemo-Icon-26.

We will use a bash script to create this base64 value from the 48px png icon.

First we need the uuencode program, on debian/ubuntu:

apt-get install sharutils

then, we create a Bash script named build_base64.sh to convert a 48x48px png into the desired text value:

#!/bin/bash

set -e

# base64 conversion
uuencode -m icon48.png icon48.png > icon48.txt

# remove the first line (begin-base64 ...)
sed -i '1d' icon48.txt

# and the last line (====)
sed -i '$d' icon48.txt

# add 4 spaces at the beginning of each lines
sed -i "s/^/ /" icon48.txt

# and add a blank line at the end of the file
echo '' >> icon48.txt

You can find this script into the data/icons folder of the samples_chapter_2.tar.gz archive. To launch it (into the icons folder):

sh build_base64.sh

We can now use the content of icon48.txt as the value of XB-Maemo-Icon-26 in our control file.

2.3.6 Build the deb

And, that's all, we can create our deb like in the previous chapter.

I don't write here the build_maemodeb.sh script, it's almost the same as the one to build the generic debian package. You'll find it in the joined archive.

  • cd samples_chapter_2
  • sh ./build_maemodeb.sh

Note: I suppose in this howto that we don't have compiled code in our app.
If this is not the case, we must use scratchbox to compile, and we must use scratchbox to build the deb too!
And, like in the previous chapter, don't use the line Architecture: all in the control file.

Nicolas Martin

You can download all the samples of this chapter 2 (Linux) in the samples_chapter_2.tar.gz archive.

The myapp application, from developer.mozilla.org is in the Public Domain.

The icon used is from the Tango Desktop Project, and is in the Public Domain.

All added data, and sample files, of this chapter 2, are in the Public Domain too.

dimanche, mai 22 2011

Distribuer votre appli XULRunner - 2.2 - Empaqueter un deb

This post exists also in english

Ce billet fait partie d'une série sur comment déployer une application XULRunner. Voir le préambule pour le contexte.

2 - Linux

2.2 Empaqueter un deb

2.2.1 Synopsis

Ok, nous avons notre lanceur, et tous les fichiers nécessaires à l'intégration au bureau (voir le chapitre 2.1). Nous allons maintenant créer un paquet deb, pour les distributions basées sur Debian, comme Ubuntu.

La principale documentation pour la création de deb est Debian Policy Manual. et vous pouvez trouver également utile cette autre doc de Debian et celle ci d'Ubuntu.

Je suppose que notre appli ne contient pas de code compilé, mais si c'est le cas, compilez le simplement avant de créer le paquet. Nous créerons ce deb manuellement.

Nous allons utiliser debhelper et fakeroot. Nous devons créer quelques fichiers utilisés par les scripts debian, copier nos sources et fichiers de bureau aux bons emplacements, et exécuter quelques scripts.

Pour celà, nous devons installer debhelper et fakeroot.

sur Debian/Ubuntu:

  • apt-get install debhelper fakeroot

Sur Fedora, malheureusement debhelper n'est pas encore disponible dans les dépôts, mais devrait l'être un jour, voir les bugs #591190, #591389, #642160, et #591332.

Sur OpenSuse il y a un paquet nommé 'deb' qui l'installe.

sur les autres distributions... faites le moi savoir ;)

Le deb créé installera myapp dans le dossier /usr/lib/ , c'est l'emplacement standard sur Linux.

2.2.2 Fichiers Debian

pour construire notre deb, nous devons créer un dossier debian à coté de notre application, contenant plusieurs fichiers utilisés par les programmes de debhelper
Vous pouvez utiliser dh_make pour créer un tel squelette, mais ici nous allons créer ces fichiers nous-même :

    |- samples_chapter_2/
|- myapp/
|- debian/
|- changelog
|- compat
|- control
|- copyright
|- menu
|- postinst
|- myapp.links

Le fichier changelog est décrit en détail ici dans la doc, il contient :

myapp (1.0-1) unstable; urgency=low

* Initial release

-- John Doe <johndoe@example.com> Fri, 26 Nov 2010 10:10:35 +0100

Note : soyez précis dans le format de ce fichier, il doit réellement être précis, voir la doc.

Note : la date doit être au format RFC822, vous pouvez l'obtenir avec date -R dans un terminal.

Le fichier compat contient simplement la compatibilité de debhelper, soit juste 7 .

Le fichier control est le plus important. Voici un exemple :

Source: myapp
Section: Utilities
Priority: extra
Maintainer: John Doe <johndoe@example.com>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.2
Homepage: <http://example.com/myapp/>

Package: myapp
Architecture: all
Depends: xulrunner (>= 1.9.2) | firefox (>= 3.6)
Description: simple Hello World.
Powered by XULRunner.

Choisissez une Section dans cette liste.

Si votre application contient du code compilé, vous devez supprimer la ligne Architecture: all, car son but est précisement de créer un paquet indépendant de la plateforme. Sans cette entrée, le deb sera spécifique à l'architecture actuelle.

Si votre appli nécessite d'autres dépendances, ajoutez les séparés par une virgule. Si l'appli contient du code compilé, vous pouvez vouloir utiliser la valeur ${shlibs:Depends}, ainsi à la construction du paquet certaines dépendances seront calculées. Par exemple :

Depends: xulrunner (>= 1.9.2) | firefox (>= 3.6), ${shlibs:Depends}

Le format du champ Description est décrit en détail dans cette doc.

Le fichier copyright peut contenir par exemple :

This package was debianized by John Doe <johndoe@example.com> on
Sat, 16 Oct 2010 17:55:17 +0200

It was downloaded from <http://example.com/myapp/>

Upstream Author(s):
John Doe <johndoe@example.com>

Copyright:
<Copyright (C) 2010 John Doe>

License:
***** BEGIN LICENSE BLOCK *****
Version: MPL 1.1/GPL 2.0/LGPL 2.1

The contents of this file are subject to the Mozilla Public License Version
1.1 (the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.mozilla.org/MPL/

Software distributed under the License is distributed on an "AS IS" basis,
WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
for the specific language governing rights and limitations under the
License.

The Original Code is MyApp.

The Initial Developer of the Original Code is John Doe.
Portions created by the Initial Developer are Copyright (C) 2010
the Initial Developer. All Rights Reserved.

Contributor(s):
John Doe (johndoe@example.com)

Alternatively, the contents of this file may be used under the terms of
either the GNU General Public License Version 2 or later (the "GPL"), or
the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
in which case the provisions of the GPL or the LGPL are applicable instead
of those above. If you wish to allow use of your version of this file only
under the terms of either the GPL or the LGPL, and not to allow others to
use your version of this file under the terms of the MPL, indicate your
decision by deleting the provisions above and replace them with the notice
and other provisions required by the GPL or the LGPL. If you do not delete
the provisions above, a recipient may use your version of this file under
the terms of any one of the MPL, the GPL or the LGPL.

***** END LICENSE BLOCK *****

Le fichier menu contient :

?package(myapp):needs="X11" section="Applications/Programming"\
title="MyApp" command="/usr/bin/myapp"

Choisissez une section dans cette liste.

Le fichier postinst est un script lancé à la fin de l'installation du deb. Il permet de reconstruire le cache des icônes système par exemple.

#!/bin/sh
# postinst script for myapp
#
# see: dh_installdeb(1)

set -e

# summary of how this script can be called:
# * <postinst> `configure' <most-recently-configured-version>
# * <old-postinst> `abort-upgrade' <new version>
# * <conflictor's-postinst> `abort-remove' `in-favour' <package>
# <new-version>
# * <postinst> `abort-remove'
# * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
# <failed-install-package> <version> `removing'
# <conflicting-package> <version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package

case "$1" in
configure)
# for icons of the app
if [ -x /usr/bin/gtk-update-icon-cache ]; then
gtk-update-icon-cache -f /usr/share/icons/hicolor
fi

# uncomment only if the installed app handle some mime-type
#if [ "$2" == "" ]; then
# if [ -x /usr/bin/update-desktop-database ]; then
# update-desktop-database /usr/share/applications
# fi
#fi
;;

abort-upgrade|abort-remove|abort-deconfigure)
;;

*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#

exit 0

Enfin, le fichier myapp.links contient les liens à créer après l'installation du deb.

/usr/lib/myapp/myapp.sh /usr/bin/myapp
2.2.3 Créer le deb

Ok, nous avons maintenant tous les fichiers nécessaires, nous pouvons créer notre deb. Nous devons créer un dossier portant le même nom que notre application dans le dossier debian, et y copier les fichiers de la même manière que sur le système final.

    |- debian/
|- myapp/
|- usr
|- lib
|- myapp/
|- share
|- applications/
|- myapp.desktop
|- icons/
|- hicolor/
|- 16x16/
|- apps
|- myapp.png
|- 22x22/
|- apps
|- myapp.png
|- 32x32/
|- apps
|- myapp.png
|- 48x48/
|- apps
|- myapp.png
|- scalable/
|- apps
|- myapp.svg

Et nous allons appliquer quelques script debhelper.

Voici un script shell complet, nommé build_deb.sh, il crée un dossier temporaire 'tmp', et y copie nos fichiers debian, notre application, et nos fichiers desktop, puis crée le deb :

#!/bin/bash

# exit the script on errors
set -e

TMP_DIR=./tmp

# get the absolute path of our TMP_DIR folder
TMP_DIR=$(readlink -f -- "$TMP_DIR")

# re-create the TMP_DIR folder
rm -rfv "$TMP_DIR"
mkdir -v "$TMP_DIR"

#copy the debian folder into TMP_DIR
cp -rv "./debian" "$TMP_DIR/"

# create into TMP_DIR the folder where copy our app
mkdir -pv "$TMP_DIR/debian/myapp/usr/lib"

# and copy the app
cp -rv "./myapp" "$TMP_DIR/debian/myapp/usr/lib/"

# create the folder for the .desktop file and copy it
mkdir -pv "$TMP_DIR/debian/myapp/usr/share/applications"
cp -v "./data/myapp.desktop" \
"$TMP_DIR/debian/myapp/usr/share/applications/"

# create the folder and copy our icons
mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/16x16/apps"
cp -v "./data/icons/icon16.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/16x16/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/22x22/apps"
cp -v "./data/icons/icon22.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/22x22/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/32x32/apps"
cp -v "./data/icons/icon32.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/32x32/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/48x48/apps"
cp -v "./data/icons/icon48.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/48x48/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/scalable/apps"
cp -v "./data/icons/icon48.svg" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/scalable/apps/myapp.svg"

cd "$TMP_DIR"

# clean eventual tempory files
find . -type f -name *.*~ -exec rm {} \;

# deb creation
fakeroot dh_link
fakeroot dh_fixperms
fakeroot dh_installdeb
# uncomment the following line if you have some compiled code and use ${shlibs:Depends} in control file
#dh_shlibdeps
fakeroot dh_gencontrol
fakeroot dh_md5sums
fakeroot dh_builddeb

echo "deb created for myapp :)"

Pour créer notre deb, dans un terminal :

  • cd samples_chapter_2
  • sh ./build_deb.sh

En résultat nous avons finalement le fichier myapp_1.0-1_all.deb dans le dossier samples_chapter_2 :) .

Nicolas Martin

Vous pouvez télécharger tous les exemples de ce chapitre 2 (Linux) dans l'archive samples_chapter_2.tar.gz .

L'application myapp, de developer.mozilla.org, est dans le Domaine Public.

L'icône utilisée est issue du Tango Desktop Project, et est dans le Domaine Public.

Toutes les autres données ajoutées, et les fichiers en exemple, sont dans le Domain Public également.

Distribute your XULRunner app - 2.2 - Package as deb

Ce billet existe aussi en français

This post is part of a series about how to package a XULRunner application.
See the preamble for the context case.

2.2 Package as deb

2.2.1 Synopsis

Ok, so we have our launcher, and all the files needed for the desktop integration (see chapter 2.1). We will now create a deb package, for Debian based distributions, like Ubuntu.

The main documentation for deb creation is the Debian Policy Manual. And you can find useful too this other doc from Debian and this one from Ubuntu.

I suppose that our app doesn't contain any compiled code, but if you have some, simply compile it before packaging. We will create this deb manually.

We will use debhelper and fakeroot. We have to create some files used by the debian scripts, copy our sources and our desktop files in the right location, then run some scripts.

For that, we need to install debhelper and fakeroot.

on Debian/Ubuntu:

  • apt-get install debhelper fakeroot

On Fedora, unfortunatly debhelper is not yet available in the default repository, but it should be one day, see the bugs #591190, #591389, #642160, and #591332.

On OpenSuse there's a package named 'deb' from openSuse which install it.

On others... let me know ;)

The created deb will install myapp in the /usr/lib/ folder, this is the standard location on Linux.

2.2.2 Debian files

To build our deb, we need to create a debian folder alongside our application, with several files into it used by the debhelper programs.
You can use dh_make to create a such skeleton, but here we will create these files by hand:

    |- samples_chapter_2/
|- myapp/
|- debian/
|- changelog
|- compat
|- control
|- copyright
|- menu
|- postinst
|- myapp.links

The changelog file is described in detail here in the doc, it will contain:

myapp (1.0-1) unstable; urgency=low

* Initial release

-- John Doe <johndoe@example.com> Fri, 26 Nov 2010 10:10:35 +0100

Note: be precise on the formatting of this file, it must be really precise, see the doc.

Note: the date must be in RFC822 format, you can obtain it with date -R in a terminal.

The compat file contains simply the debhelper compatibility, so just 7 .

The control file is the more important one. Here's a sample:

Source: myapp
Section: Utilities
Priority: extra
Maintainer: John Doe <johndoe@example.com>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.2
Homepage: <http://example.com/myapp/>

Package: myapp
Architecture: all
Depends: xulrunner (>= 1.9.2) | firefox (>= 3.6)
Description: simple Hello World.
Powered by XULRunner.

Choose a Section from this list.

If your application contains some compiled code, you must remove the line Architecture: all , because its goal is precisely to create a platform independent package. Without this entry, the deb will be specified for the current platform.

If your app requires some other dependencies, add them separated by a comma. If your app contains some compiled code, you can want to use the ${shlibs:Depends} value, when the package will be built, some dependencies will be determined. Example

Depends: xulrunner (>= 1.9.2) | firefox (>= 3.6), ${shlibs:Depends}

The format of the field Description is described in detail in this doc.

The copyright file can contain by example:

This package was debianized by John Doe <johndoe@example.com> on
Sat, 16 Oct 2010 17:55:17 +0200

It was downloaded from <http://example.com/myapp/>

Upstream Author(s):
John Doe <johndoe@example.com>

Copyright:
<Copyright (C) 2010 John Doe>

License:
***** BEGIN LICENSE BLOCK *****
Version: MPL 1.1/GPL 2.0/LGPL 2.1

The contents of this file are subject to the Mozilla Public License Version
1.1 (the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.mozilla.org/MPL/

Software distributed under the License is distributed on an "AS IS" basis,
WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
for the specific language governing rights and limitations under the
License.

The Original Code is MyApp.

The Initial Developer of the Original Code is John Doe.
Portions created by the Initial Developer are Copyright (C) 2010
the Initial Developer. All Rights Reserved.

Contributor(s):
John Doe (johndoe@example.com)

Alternatively, the contents of this file may be used under the terms of
either the GNU General Public License Version 2 or later (the "GPL"), or
the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
in which case the provisions of the GPL or the LGPL are applicable instead
of those above. If you wish to allow use of your version of this file only
under the terms of either the GPL or the LGPL, and not to allow others to
use your version of this file under the terms of the MPL, indicate your
decision by deleting the provisions above and replace them with the notice
and other provisions required by the GPL or the LGPL. If you do not delete
the provisions above, a recipient may use your version of this file under
the terms of any one of the MPL, the GPL or the LGPL.

***** END LICENSE BLOCK *****

The menu file contains:

?package(myapp):needs="X11" section="Applications/Programming"\
title="MyApp" command="/usr/bin/myapp"

Choose a section in this list.

The postinst file is a script launched after the deb installation.  It allows to rebuild the cache of the system icons for example:

#!/bin/sh
# postinst script for myapp
#
# see: dh_installdeb(1)

set -e

# summary of how this script can be called:
# * <postinst> `configure' <most-recently-configured-version>
# * <old-postinst> `abort-upgrade' <new version>
# * <conflictor's-postinst> `abort-remove' `in-favour' <package>
# <new-version>
# * <postinst> `abort-remove'
# * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
# <failed-install-package> <version> `removing'
# <conflicting-package> <version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package

case "$1" in
configure)
# for icons of the app
if [ -x /usr/bin/gtk-update-icon-cache ]; then
gtk-update-icon-cache -f /usr/share/icons/hicolor
fi

# uncomment only if the installed app handle some mime-type
#if [ "$2" == "" ]; then
# if [ -x /usr/bin/update-desktop-database ]; then
# update-desktop-database /usr/share/applications
# fi
#fi
;;

abort-upgrade|abort-remove|abort-deconfigure)
;;

*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#

exit 0

Finally, the myapp.links file contains the links to create when the deb will be installed:

/usr/lib/myapp/myapp.sh /usr/bin/myapp

2.2.3 Create the deb

Ok, we have now all the necessary files, we can generate our deb. We have to create a folder named like our app name into the debian folder, and under it copy the files like in the final root system:

    |- debian/
|- myapp/
|- usr
|- lib
|- myapp/
|- share
|- applications/
|- myapp.desktop
|- icons/
|- hicolor/
|- 16x16/
|- apps
|- myapp.png
|- 22x22/
|- apps
|- myapp.png
|- 32x32/
|- apps
|- myapp.png
|- 48x48/
|- apps
|- myapp.png
|- scalable/
|- apps
|- myapp.svg

And we will apply some debhelper scripts.

Here a complete shell script, named build_deb.sh, which create a temporary 'tmp' folder, we copy into it our debian files, our application, and our desktop files, then create the deb:

#!/bin/bash

# exit the script on errors
set -e

TMP_DIR=./tmp

# get the absolute path of our TMP_DIR folder
TMP_DIR=$(readlink -f -- "$TMP_DIR")

# re-create the TMP_DIR folder
rm -rfv "$TMP_DIR"
mkdir -v "$TMP_DIR"

#copy the debian folder into TMP_DIR
cp -rv "./debian" "$TMP_DIR/"

# create into TMP_DIR the folder where copy our app
mkdir -pv "$TMP_DIR/debian/myapp/usr/lib"

# and copy the app
cp -rv "./myapp" "$TMP_DIR/debian/myapp/usr/lib/"

# create the folder for the .desktop file and copy it
mkdir -pv "$TMP_DIR/debian/myapp/usr/share/applications"
cp -v "./data/myapp.desktop" \
"$TMP_DIR/debian/myapp/usr/share/applications/"

# create the folder and copy our icons
mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/16x16/apps"
cp -v "./data/icons/icon16.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/16x16/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/22x22/apps"
cp -v "./data/icons/icon22.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/22x22/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/32x32/apps"
cp -v "./data/icons/icon32.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/32x32/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/48x48/apps"
cp -v "./data/icons/icon48.png" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/48x48/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/scalable/apps"
cp -v "./data/icons/icon48.svg" \
"$TMP_DIR/debian/myapp/usr/share/icons/hicolor/scalable/apps/myapp.svg"

cd "$TMP_DIR"

# clean eventual tempory files
find . -type f -name *.*~ -exec rm {} \;

# deb creation
fakeroot dh_link
fakeroot dh_fixperms
fakeroot dh_installdeb
# uncomment the following line if you have some compiled code and use ${shlibs:Depends} in control file
#dh_shlibdeps
fakeroot dh_gencontrol
fakeroot dh_md5sums
fakeroot dh_builddeb

echo "deb created for myapp :)"

To create our deb, in a terminal:

  • cd samples_chapter_2
  • sh ./build_deb.sh

And as result we have finally the file myapp_1.0-1_all.deb in the samples_chapter_2 folder :) .

Nicolas Martin

You can download all the samples of this chapter 2 (Linux) in the samples_chapter_2.tar.gz archive.

The myapp application, from developer.mozilla.org is in the Public Domain.

The icon used is from the Tango Desktop Project, and is in the Public Domain.

All added data, and sample files, of this chapter 2, are in the Public Domain too.

samedi, mai 21 2011

Distribuer votre appli XULRunner - 2.1 - Linux commun

This post exists also in english

Ce billet fait partie d'une série sur comment déployer une application XULRunner. Voir le préambule pour le contexte.

2 - Linux

2.1 Linux commun

2.1.1 Généralités

Nous ciblons la plateforme Linux dans cette partie. Et c'est le cas le plus simple.

Pour toutes les distributions que j'ai essayées, XULRunner est disponible depuis le gestionnaire de paquets, et Firefox est basé sur lui. Donc XULRunner peut facilement être une dépendance de notre application.

2.1.2 Créer un lanceur

Il est facile de créer un lanceur, créons simplement un script shell nommé myapp.sh, dans le dossier principal de notre application (celui qui contient application.ini), avec le contenu suivant :

#!/bin/sh

CUR_DIR=$(dirname $(readlink -f "$0"))

if [ -x /usr/bin/xulrunner ]; then
/usr/bin/xulrunner "$CUR_DIR/application.ini" $@
elif [ -x /usr/bin/firefox ]; then
/usr/bin/firefox -app "$CUR_DIR/application.ini" $@
else
echo "Error: unable to find XULRunner or Firefox!"
fi

et rendons le exécutable :

chmod +x myapp.sh

Le script trouve dans quel dossier il se trouve, puis lance le fichier application.ini via xulrunner s'il le trouve, sinon via firefox avec l'argument -app. Le script passe aussi les éventuels arguments supplémentaires (comme -jsconsole par exemple).

Plus tard dans ce tutoriel, quand nous créerons les paquets deb et rpm, nous ajouterons un lien symbolique vers ce fichier dans /usr/bin .

Note: l'argument -f de readlink utilisé dans ce script est disponible uniquement dans la version GNU, donc dans toutes les distributions Linux, mais pas forcément sur d'autres systèmes de type Unix, comme Mac OSX par exemple.

2.1.3 Des icônes pour nos fenêtres

Pour l'instant, notre application est lancée, mais l'icône affichée dans la barre de tâches est celle générique de XULRunner, ou celle de Firefox. Il est facile d'afficher notre propre icône. Créons simplement un dossier nommé 'icons' à l'intérieur du dossier chrome principal de notre appli, puis créons dans celui-ci un autre nommé 'default'. Copions 3 fichiers png, nommés default16.png, default32.png, et default48.png. Et c'est tout, maintenant c'est notre icône qui est affichée.

    |- samples_chapter_2/
|- myapp/
|- chrome
|- icons/
|- default/
|- default16.png
|- default32.png
|- default48.png
 2.1.4 Intégration au bureau

Pour une intégration complète au bureau, nous devons maintenant créer quelques fichiers supplémentaires, un fichier .desktop, et quelques icône associées. Ainsi notre appli apparaitra dans le menu Applications du gestionnaire de fenêtres.

En exemple, voici le contenu d'un fichier myapp.desktop :

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=MyApp
Comment=a Hello World XULRunner app
Comment[fr]=un Bonjour Monde pour XULRunner.
Exec=/usr/bin/myapp
Terminal=false
Type=Application
Categories=Utility;
Icon=myapp

Voir cette documentation pour les détails, et celle ci pour choisir les Catégories.

L'entrée Exec est décrite en détail ici, nous utilisons un lien symbolique vers notre lanceur, depuis /usr/bin/ (le standard pour les exécutables sur Linux). Son emplacement réel sera dans /usr/lib/myapp/.

L'entrée Icon contient le nom de notre icône, que nous créerons par la suite.

L'entrée Comment est optionnelle, et peut être localisée (comme quelques autres entrées, voyez la spécification), ici nous définissons sune valeur par défaut, et une française (fr).

Si l'appli gère certains types mime, i.e. peut ouvrir certains types de fichiers, vous devez ajouter une ligne avec l'entrée MimeType, par exemple :

MimeType=text/html;text/xml;application/xhtml+xml;

Ce fichier myapp.desktop est sensé être placé à l'étape finale dans le dossier /usr/share/applications/ folder.
(Voir http://www.freedesktop.org/wiki/Specifications/menu-spec et http://www.freedesktop.org/wiki/Specifications/basedir-spec pour plus de détail)

Maintenant nous avons besoin de quelques icônes. Nous utiliserons des png et svg (xpm est également possible, mais semble déprécié, nous n'utiliserons pas ce format). Nous pouvons avoir différentes tailles, personnellement je me restreint à 4 png (16x16, 22x22, 32x32, 48x48), comme suggéré par les Tango Guidelines, plus un svg de 48x48.

Ces images doivent être nommées myapp.png, et myapp.svg .

Et elles doivent finalement être placées dans les dossiers suivants :

  • /usr/share/icons/hicolor/16x16/apps/myapp.png
  • /usr/share/icons/hicolor/22x22/apps/myapp.png
  • /usr/share/icons/hicolor/32x32/apps/myapp.png
  • /usr/share/icons/hicolor/48x48/apps/myapp.png
  • /usr/share/icons/hicolor/scalable/apps/myapp.svg
 2.1.5 Distribuer un tar.gz

Notre application est utilisable telle quelle avec son lanceur, vous pouvez donc la distribuer avec un simple tar.gz. Pour le créer :

tar -zcvf myapp.tar.gz myapp

Un utilisateur peut le télécharger, le décompresser n'importe où, et lancer l'appli via myapp.sh.

Mais pour être plus convivial, un paquet utilisable avec le gestionnaire de paquet de sa distribution, avec l'intégration au bureau complète, est préférable. C'est ce que nous verrons dans les prochaines sections.

Nicolas Martin

Vous pouvez télécharger tous les exemples de ce chapitre 2 (Linux) dans l'archive samples_chapter_2.tar.gz .

L'application myapp, de developer.mozilla.org, est dans le Domaine Public.

L'icône utilisée est issue du Tango Desktop Project, et est dans le Domaine Public.

Toutes les autres données ajoutées, et les fichiers en exemple, sont dans le Domain Public également.

- page 2 de 5 -