Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux
Bonjour,
Pour ma part je développe depuis quelques années un programme
cross-plateforme (Windows/Linux) en client lourd :
https://openpaper.work/ .
C'est du Python+GTK.
Python est un langage très plaisant à utiliser. Par contre, dès qu'on
utilise des librairies qui ne sont pas pure-Python, le packaging
devient vite très compliqué. L'utilisation des bindings
Gobject-introspection pour accéder à GTK n'améliore pas la situation.
Sous GNU/Linux, je distribue ça surtout sous forme de Flatpak[1][2].
Ça me permet notamment de faire du déploiement continu[3][4]. Ça pose
juste des problèmes d'accès aux scanners (et quelques autres
périphériques pour d'autres applis) :/.
Je le distribue aussi sous forme de paquets pip[5]. Les paquets
incluent une commande à lancer pour vérifier et installer les
dépendances qui ne peuvent pas être prises en charge par pip
(`paperwork-gtk chkdeps`). Mais c'est moins pratique pour les
utilisateurs, et ce n'est donc plus la méthode recommandée.
Avec le temps, de gentils mainteneurs de paquets ont fait des paquets
pour diverses distributions. Ça reste de loin la méthode la plus
simple pour les utilisateurs. Le défaut pour moi, c'est que je ne peux
pas faire de déploiement continu.
Sous Windows, j'avais étudié la possibilité de faire de la
cross-compilation, mais je n'ai pas retenu cette solution finalement.
J'ai buté sur les bindings GObject Introspection : Si j'ai bien
compris, le programme qui les génère (g-ir-scanner) a besoin de
tourner sur le même système que le systẽme cible.
De façon générale, dès qu'on utilise des librairies natives, la
cross-compilation risque de causer des problèmes. Il me semble que
pour cross-compiler des programmes Windows, la seule solution est
d'utiliser les librairies Wine (ne serait-ce que pour le linkage). Du
coup, c'est difficile d'être certain que le résultat fonctionnera de
façon fiable sur un vrai Windows.
Le même problème se pose pour les tests automatiques : On peut les
lancer avec Wine, mais il n'y a aucune garantie que le comportement
sera exactement le même que sur un vrai Windows.
Vu que j'utilise GTK, le plus simple que j'ai trouvé est d'utiliser
une VM Windows et MSYS2[6]. Dans MSYS2, j'utilise cx-freeze[7] pour
créer un exécutable Windows. Cx_freeze n'a pas l'air de gérer très
bien les bindings GObject-Introspection, donc j'ai dû bricoler un peu
pour que ça passe (ajout de dépendances manquées par Cx_freeze à la
main)[8].
L'exécutable est accompagné de plein de fichiers de données. J'en fait
donc un ZIP[9] et l'upload sur un object storage OVH. C'est
l'installateur NSIS[10][11] qui va le télécharger et l'extraire à
l'installation. Du coup il télécharge toujours la dernière version
construite par CI/CD (donc on est presque sur du CI/CD complet de bout
en bout).
Pour être honnête, je regrette d'avoir fait le portage à Windows de
mon application. Ça m'a pris énormément de temps (développement de
Pyinsane puis Libinsane pour accéder aux scanners sous Windows,
difficulté pour packager, bugs à la c*n, etc). Mais bon, le gros de la
difficulté est passé, et des gens s'en servent maintenant ...
En tout cas, je ne porterais pas mes prochaines applications à Windows.
Concernant Go, il ne me semble pas que Go intègre de librairie de GUI
par défaut. Ça m'étonnerait aussi fortement qu'il existe une librairie
en pure-Go cross-plateforme. Ça veut dire qu'il faut des bindings
coincoin sur Qt ou GTK. Ça sent les problèmes aussi tordus que ceux
que j'ai eu avec Python. De plus, je ne suis pas certain que
l'éco-système de librairies pour le desktop basé sur Go soit aussi
développé que celui de Python.
Pour les applications Javascript genre Électron, dans le cadre de mes
développements, je fais une allergie sévère au Javascript et aux
machins « web ». Je trouve le langage Javascript infect, et de mon
point de vue, cette approche est une rustine sur un problème qui
aurait déjà dû être réglé plus proprement il y a longtemps. De toute
façon, avec ça, je n'aurais sûrement pas pu accéder aux scanners.
Pour Flutter/Dart, je ne connais pas.
Au final, pour faire des GUI cross-plateformes, je me dis que
l'approche Java/Swing était peut-être la bonne.
Cordialement,
---
[1] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/master/doc/install.flatpak.markdown
[2] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/master/flatpak/master.json
[3] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/.gitlab-ci.yml#L71
[4] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/pipelines
[5] https://pypi.org/project/paperwork/
[6] https://www.msys2.org/
[7] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/.gitlab-ci.yml#L147
[8] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/paperwork-gtk/Makefile#L39
[9] https://download.openpaper.work/windows/x86/paperwork-master-latest.zip
[10] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/tree/master/nsis
[11] https://download.openpaper.work/windows/installer/paperwork_stable_installer.exe
Le jeu. 19 nov. 2020 à 16:12, Olivier <oza.4h07@gmail.com> a écrit :
>
> Bonjour,
>
> Je serai très curieux de recueillir ici des retours d'expérience sur le développement sous Debian (Buster) d'applications natives Windows/Linux.
>
> 1. Par application native, j'entends une application graphique avec quelques champs de saisie et quelques boutons.
> L'homogénéité du style de l'application avec les autres n'a pas d'importance pour mon cas.
> Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est pas important non plus.
> Si j'ai la possibilité, j'apprécierai de coder en Python.
>
> 2. Un point très important pour moi est, par contre, si c'est possible de pouvoir empaqueter depuis Linux/Debian l'application Windows et son installateur sans utiliser Windows.
> (Plusieurs outils comme Kivy annonce la possibilité de développer pour plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la même plateforme que la cible).
>
> A. Qu'en pensez-vous ? Avez-vous déjà expérimenté une telle chose ?
> B. En surfant, j'ai lu que le langage Go (cf [1] annonce la possibilité d'empaqueter sur Linux pour Windows. Qu'en penser ?
> C. J'ai lu des infos sur Flutter/Dart ou Qt mais rien de précis sur l'empaquetage.
>
> [1] https://golangr.com/gui/
>
> Slts
Reply to: