Conseils pour le d̓©veloppement sur Debian d'applications natives Windows/Linux

--BXVAT5kNtrzKuDFl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Bonjour Olivier,

Olivier, on 2020-11-19 16:11:32 +0100:

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).

Je ne suis absolument pas vers̓© dans le domaine de la
distribution de programmes pour Windows, mais en faisant une
petite recherche dans les paquets de Debian Sid, je suis tomb̓©
sur "gcab". L'outil est mis ̓  disposition via la collection des
"msitools" :

https://wiki.gnome.org/msitools

| msitools plans to be a solution for packaging and deployment
| of cross-compiled Windows applications.

C'est un collection de programmes pour empaqueter et d̓©ployer
des utilitaires cross-compil̓©s ̓  destination de Windows.
J'ignore ce que ̓§a vaut en pratique, mais ̓  la description, ̓§a
me semblait correspondre ̓  votre cahier des charges.

Quant ̓  tester l'installateur, je suppose que wine ferait
l'affaire dans un premier temps. Mais ̓  terme, je pense qu'il
faudrait au moins faire un test sur une machine Windows native,
juste pour s'assurer qu'une coquille n'est pas pass̓©e entre les
mailles du filet.

Bonne journ̓©e,
--
̓‰tienne Mollier <etienne.mollier@mailoo.org>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.

--BXVAT5kNtrzKuDFl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAl+3bMQACgkQeTz2fo8N
Edr8Gg/+LKQlzJnmN4+OWXlqrh3xmoY9XkRw924w4Ch/+2QkI1TEqbXXdR6yNrC7
A4X6bRcF7FUyEfH+FufpPr7+JbrbY3fV4bmlYwCeDF4qIKHrod9sAPfj4l+L5nlw
PqsRpUflaCH+8M5S3f8eWDKUH3o0Bpqx09xzv5LPjCRtIaJ/qAO0Ho+GlkwAsV4s
kvo6+vYeTzdANfAFcbQAIyXDvZnBz856yfxfIaQAxN9HUpNKbuMl+qmDI5g5nEQ2
+9wyd48hUmUR0bL133g/fxdabZtJN8XvZQvwBQbyfP2Ui3eBaz97vRxRJbx2uGDU
1N8TDvbl0+1EUOseNvsuNMEh+cVGvV5xVw2gUnUaOFXPff9g8KLlilECjfnNGRU1
ZFpZnsCsstoNM+7AQRpkebmDIcIX4oHepgxABvNgmrqE7TsW8xpeAT99WUjaRrEx
HiYgzx8L5tSlhtkEQlG2A9KTkEzg6ZRwGwZlNrCxbDconjORD7YLPd5ROFshTlAw
Cq7/aIXjFEFIVh4aSmIXD8SqUYe3luU2DHM01QONJ17yuPp+Sp4/YklfmB3nH4Lp
XjJ6b8sss5CzWfqDll9BlEoI00UvQ7Su7X60osewgB2ABRVUvvGSVJykh7blYj+/
Se1Co+O6+H6WltwK/4LecAqpkLXS38Byzd4QYbhAtvfF10jRc68=TINh
-----END PGP SIGNATURE-----

--BXVAT5kNtrzKuDFl--

--0000000000003c0b6005b484de1c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

C. Sur Flutter/Dart, dans [2], on peut lire qu'il faut
construire/empaqueter sur la m̓ªme plateforme que la plateforme cible.

D. J'ai d̓©couvert Guark (cf [3]). ̓‡a a l'air particuli̓¨rement int̓©ressant.

[2] https://flutter.dev/desktop

[3] https://github.com/guark/guark


Le jeu. 19 nov. 2020 ̓  16:11, 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

--0000000000003c0b6005b484de1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>C. Sur Flutter/Dart, dans [2], on peut lire qu&#39;il faut construire/empaqueter sur la m̓ªme plateforme que la plateforme cible.<br></div><div><br></div><div>D. J&#39;ai d̓©couvert Guark (cf [3]). ̓‡a a l&#39;air particuli̓¨rement int̓©ressant.<br></div><div><br></div><div>[2] <a href="https://flutter.dev/desktop">https://flutter.dev/desktop</a></div><div><br></div><div>[3] <a href="https://github.com/guark/guark">https://github.com/guark/guark</a></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ jeu. 19 nov. 2020 ̓ ͂ 16:11, Olivier &lt;<a href="mailto:oza.4h07@gmail.com">oza.4h07@gmail.com</a>&gt; a ̓©crit͂ :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>Je serai tr̓¨s curieux de recueillir ici des retours d&#39;exp̓©rience sur le d̓©veloppement sous Debian (Buster) d&#39;applications natives Windows/Linux.</div><div><br></div><div>1. Par application native, j&#39;entends une application graphique avec quelques champs de saisie et quelques boutons.</div><div>L&#39;homog̓©n̓©it̓© du style de l&#39;application avec les autres n&#39;a pas d&#39;importance pour mon cas.</div><div>Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n&#39;est pas important non plus.</div><div>Si j&#39;ai la possibilit̓©, j&#39;appr̓©cierai de coder en Python.<br></div><div><br></div><div>2. Un point tr̓¨s important pour moi est, par contre, si c&#39;est possible de pouvoir empaqueter depuis Linux/Debian l&#39;application Windows et son installateur sans utiliser Windows.</div><div>(Plusieurs outils comme Kivy annonce la possibilit̓© de d̓©velopper pour plusieurs plateformes, mais si j&#39;ai bien compris, il faut empaqueter sur la m̓ªme plateforme que la cible).<br></div><div><br></div><div>A. Qu&#39;en pensez-vous ? Avez-vous d̓©j̓  exp̓©riment̓© une telle chose ?</div><div>B. En surfant, j&#39;ai lu que le langage Go (cf [1] annonce la possibilit̓© d&#39;empaqueter sur Linux pour Windows. Qu&#39;en penser ?</div><div>C. J&#39;ai lu des infos sur Flutter/Dart ou Qt mais rien de pr̓©cis sur l&#39;empaquetage.<br></div><div><br></div><div>[1] <a href="https://golangr.com/gui/" target="_blank">https://golangr.com/gui/</a></div><div><br></div><div>Slts<br></div></div>
</blockquote></div>

--0000000000003c0b6005b484de1c--

--000000000000f40dc505b484ff16
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Basile:

Merci pour tes r̓©ponses.

La possibilit̓© de cross-compiler est une fonction clairement mise en avant
par le language Go (cf [4]).
Il semble m̓ªme possible de cibler MacOS sans poss̓©der la moindre licence ou
le moindre mat̓©riel Apple !
J'imagine que "le terrain a ̓©t̓© juridiquement balay̓©".


[4]
https://www.digitalocean.com/community/tutorials/how-to-build-go-executables-for-multiple-platforms-on-ubuntu-16-04

Le jeu. 19 nov. 2020 ̓  16:58, Basile Starynkevitch <basile@starynkevitch.net>
a ̓©crit :

On 11/19/20 4:11 PM, Olivier wrote:

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.


Nota Bene:* je n'ai jamais de ma vie utilis̓© Windows!* (Mais Linux depuis
1993, et Unix depuis 1985)


̓‡a doit ̓ªtre faisable, mais *̓§a peut prendre des semaines de travail*, et
il n'est pas certain que l'ex̓©cutable ainsi produit soit l̓©galement
diffusable. Je sugg̓¨re une approche WSL et la *consultation d'un avocat
sp̓©cialiste en licences logicielles*.


Des pistes possibles seraient


Lire avec attention http://www.fr.linuxfromscratch.org/

Compiler GNU binutils depuis son code source depuis
https://www.gnu.org/software/binutils/

Compiler GCC depuis son code source sur http://gcc.gnu.org/

Utiliser une biblioth̓¨que serveur HTTP telle que
https://coralbits.com/static/onion/

Il se trouve que j'ai contribu̓© aussi bien ̓  GCC qu'̓  libonion.



La question centrale, c'est combien de temps ̓ªtes vous pr̓ªt ̓  d̓©penser, et
pourquoi (et pour vous, qui vous paie ce temps de travail, qui se compte en
semaines).


Il est possible que l'acquisition d'une licence Windows soit moins
on̓©reuse que tout le travail ̓  faire pour l'̓©viter.


Cordialement


--
Basile Starynkevitch <basile@starynkevitch.net> <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

--000000000000f40dc505b484ff16
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>@Basile:</div><div><br></div><div>Merci pour tes r̓©ponses.</div><div><br></div><div>La possibilit̓© de cross-compiler est une fonction clairement mise en avant par le language Go (cf [4]).</div><div>Il semble m̓ªme possible de cibler MacOS sans poss̓©der la moindre licence ou le moindre mat̓©riel Apple !<br></div><div>J&#39;imagine que &quot;le terrain a ̓©t̓© juridiquement balay̓©&quot;.</div><div><br></div><div><br></div><div>[4] <a href="https://www.digitalocean.com/community/tutorials/how-to-build-go-executables-for-multiple-platforms-on-ubuntu-16-04">https://www.digitalocean.com/community/tutorials/how-to-build-go-executables-for-multiple-platforms-on-ubuntu-16-04</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ jeu. 19 nov. 2020 ̓ ͂ 16:58, Basile Starynkevitch &lt;<a href="mailto:basile@starynkevitch.net">basile@starynkevitch.net</a>&gt; a ̓©crit͂ :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<p><br>
</p>
<div>On 11/19/20 4:11 PM, Olivier wrote:<br>
</div>
<blockquote type="cite">

<div dir="ltr">
<div>Bonjour,</div>
<div><br>
</div>
<div>Je serai tr̓¨s curieux de recueillir ici des retours
d&#39;exp̓©rience sur le d̓©veloppement sous Debian (Buster)
d&#39;applications natives Windows/Linux.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Nota Bene:<b> je n&#39;ai jamais de ma vie utilis̓© Windows!</b> (Mais
Linux depuis 1993, et Unix depuis 1985)<br>
</p>
<p><br>
</p>
<p>̓‡a doit ̓ªtre faisable, mais <font color="red"><b>̓§a peut prendre
des semaines de travail</b></font>, et il n&#39;est pas certain
que l&#39;ex̓©cutable ainsi produit soit l̓©galement diffusable. Je
sugg̓¨re une approche WSL et la <b>consultation d&#39;un avocat
sp̓©cialiste en licences logicielles</b>.<br>
</p>
<p><br>
</p>
<p>Des pistes possibles seraient</p>
<p><br>
</p>
<p>Lire avec attention <a href="http://www.fr.linuxfromscratch.org/" target="_blank">http://www.fr.linuxfromscratch.org/</a><br>
</p>
<p>Compiler GNU binutils depuis son code source depuis <a href="https://www.gnu.org/software/binutils/" target="_blank">https://www.gnu.org/software/binutils/</a><br>
</p>
<p>Compiler GCC depuis son code source sur <a href="http://gcc.gnu.org/" target="_blank">http://gcc.gnu.org/</a></p>
<p>Utiliser une biblioth̓¨que serveur HTTP telle que <tt><a href="https://coralbits.com/static/onion/" target="_blank">https://coralbits.com/static/onion/</a>
</tt><br>
</p>
<p>Il se trouve que j&#39;ai contribu̓© aussi bien ̓  GCC qu&#39;̓  <tt>libonion</tt>.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>La question centrale, c&#39;est combien de temps ̓ªtes vous pr̓ªt ̓ 
d̓©penser, et pourquoi (et pour vous, qui vous paie ce temps de
travail, qui se compte en semaines).</p>
<p><br>
</p>
<p>Il est possible que l&#39;acquisition d&#39;une licence Windows soit
moins on̓©reuse que tout le travail ̓  faire pour l&#39;̓©viter.</p>
<p><br>
</p>
<p>Cordialement<br>
</p>
<p><br>
</p>
<pre cols="72">--
Basile Starynkevitch <a href="mailto:basile@starynkevitch.net" target="_blank">&lt;basile@starynkevitch.net&gt;</a>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: <a href="http://starynkevitch.net/Basile/" target="_blank">starynkevitch.net/Basile/</a>

</pre>
</div>

</blockquote></div>

--000000000000f40dc505b484ff16--

Olivier writes:

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.

Je pense que tu peux le faire sans trop de problemes avec Java, en
utilisant la GUI Swing (ou JavaFX), et Maven.

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

--00000000000028877305b4853e97
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Etienne:
Gcab est effectivement int̓©ressant ̓  conna̓®tre.
Merci beaucoup pour ce lien.

Le ven. 20 nov. 2020 ̓  08:14, ̓‰tienne Mollier <etienne.mollier@mailoo.org>
a ̓©crit :

Bonjour Olivier,

Olivier, on 2020-11-19 16:11:32 +0100:
> 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).

Je ne suis absolument pas vers̓© dans le domaine de la
distribution de programmes pour Windows, mais en faisant une
petite recherche dans les paquets de Debian Sid, je suis tomb̓©
sur "gcab". L'outil est mis ̓  disposition via la collection des
"msitools" :

https://wiki.gnome.org/msitools

| msitools plans to be a solution for packaging and deployment
| of cross-compiled Windows applications.

C'est un collection de programmes pour empaqueter et d̓©ployer
des utilitaires cross-compil̓©s ̓  destination de Windows.
J'ignore ce que ̓§a vaut en pratique, mais ̓  la description, ̓§a
me semblait correspondre ̓  votre cahier des charges.

Quant ̓  tester l'installateur, je suppose que wine ferait
l'affaire dans un premier temps. Mais ̓  terme, je pense qu'il
faudrait au moins faire un test sur une machine Windows native,
juste pour s'assurer qu'une coquille n'est pas pass̓©e entre les
mailles du filet.

Bonne journ̓©e,
--
̓‰tienne Mollier <etienne.mollier@mailoo.org>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.

--00000000000028877305b4853e97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>@Etienne:</div><div>Gcab est effectivement int̓©ressant ̓  conna̓®tre.</div><div>Merci beaucoup pour ce lien.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le͂ ven. 20 nov. 2020 ̓ ͂ 08:14, ̓‰tienne Mollier &lt;<a href="mailto:etienne.mollier@mailoo.org">etienne.mollier@mailoo.org</a>&gt; a ̓©crit͂ :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bonjour Olivier,<br>
<br>
Olivier, on 2020-11-19 16:11:32 +0100:<br>
&gt; 2. Un point tr̓¨s important pour moi est, par contre, si c&#39;est possible de<br>
&gt; pouvoir empaqueter depuis Linux/Debian l&#39;application Windows et son<br>
&gt; installateur sans utiliser Windows.<br>
&gt; (Plusieurs outils comme Kivy annonce la possibilit̓© de d̓©velopper pour<br>
&gt; plusieurs plateformes, mais si j&#39;ai bien compris, il faut empaqueter sur la<br>
&gt; m̓ªme plateforme que la cible).<br>
<br>
Je ne suis absolument pas vers̓© dans le domaine de la<br>
distribution de programmes pour Windows, mais en faisant une<br>
petite recherche dans les paquets de Debian Sid, je suis tomb̓©<br>
sur &quot;gcab&quot;.͂  L&#39;outil est mis ̓  disposition via la collection des<br>
&quot;msitools&quot; :<br>
<br>
͂  ͂  ͂  ͂  <a href="https://wiki.gnome.org/msitools" rel="noreferrer" target="_blank">https://wiki.gnome.org/msitools</a><br>
<br>
| msitools plans to be a solution for packaging and deployment<br>
| of cross-compiled Windows applications. <br>
<br>
C&#39;est un collection de programmes pour empaqueter et d̓©ployer<br>
des utilitaires cross-compil̓©s ̓  destination de Windows.<br>
J&#39;ignore ce que ̓§a vaut en pratique, mais ̓  la description, ̓§a<br>
me semblait correspondre ̓  votre cahier des charges.<br>
<br>
Quant ̓  tester l&#39;installateur, je suppose que wine ferait<br>
l&#39;affaire dans un premier temps.͂  Mais ̓  terme, je pense qu&#39;il<br>
faudrait au moins faire un test sur une machine Windows native,<br>
juste pour s&#39;assurer qu&#39;une coquille n&#39;est pas pass̓©e entre les<br>
mailles du filet.<br>
<br>
Bonne journ̓©e,<br>
-- <br>
̓‰tienne Mollier &lt;<a href="mailto:etienne.mollier@mailoo.org" target="_blank">etienne.mollier@mailoo.org</a>&gt;<br>
Fingerprint:͂  8f91 b227 c7d6 f2b1 948c͂  8236 793c f67e 8f0d 11da<br>
Sent from /dev/pts/3, please excuse my verbosity.<br>
</blockquote></div>

--00000000000028877305b4853e97--

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