Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[ANN] guie un GUI simpliste pour Python

31 réponses
Avatar
Méta-MCI
Bonjour !


J'ai le plaisir de vous annoncer GUIE.

GUIE est un GUI, simple, pour Python, sous Windows, en HTML.
Il est piloté par Python + PyWin32 + Internet-Explorer, via COM
(Ole-automation).

Pour l'instant, il est en alpha-version (0.2).

Un site est en cours d'élaboration : http://ponx.org/ponx/guie.htm
Un forum a été créé : http://ponx.org/forum/viewforum.php?id=2

GUIE est très loin d'être terminé, mais il commence à être utilisable.


@-salutations

Michel Claveau

10 réponses

1 2 3 4
Avatar
Jean
Mais l'avantage est moins marqué dans le contexte de PowerShell qui est
plutôt destiné à des utilisateurs avancés voire des administrateurs de parc,


C'est une des raisons pour lesquelles je n'ai pas encore exposé
"l'idée" sur le groupe US : l'orientation actuelle de PowerShell.
Je me dis que celle-ci devrait "évoluer" une fois PowerShell intégré à
Windows.
J'entends d'ailleurs parler de Windows Vienna ou Windows Seven pour le
nom du futur Windows ... je parierais bien pour un Windows Power :-)

pour lesquels écrire "prendre-élément" à la place de "get-item" n'apportera
pas suffisamment par rapport à la perte de portabilité.


Sur ce point je ne suis pas vraiment d'accord.

La perte de portabilité est selon moi propre au système des alias.
Combien de fois ne voyons nous pas un code distribué récupéré par un
utilisateur qui se plaint que celui-ci ne fonctionne pas et l'auteur du
code répondre : "désolé sdsfdfgf est un alias chez moi qui correspond à
...".
La documentation indique d'ailleurs quelque part qu'il est conseillé
d'utiliser les noms complets dans les codes distribués.

"L'idée" est plus de donner la possibilité d'écrire un code "dans sa
langue maternelle" et de pouvoir produire, sur base de ce code, un code
distribuable (et donc exécutable par tous) qui sera donc, selon les us
et coutumes actuelles, "en anglais".

Ceci conduit a une plus grande démocratisation de l'accès à la
programmation (de part le bilinguisme -on aime ce mot là ici :-) -
devenu inutile) et par voie de conséquence à un plus grand nombre
d'utilisateur du language.

Accessoirement ça permet aussi de dire à sa secrétaire trilingue Bantou
- Japonais - Français qui ne connait que Word que si elle veux envoyer
un message téléphonique à 20 h (heure à laquelle elle regarde Docteur
House) elle peut faire clic clic sur PowerShell et taper :
téléphoner 6532165468 -aujourd'hui -à 20h -dire "Je suis en train de
regarder Dr House" -raccrocher à la fn du message ... :-)

Amicalement,

--
Jean - JMST
Belgium

Avatar
Jean
La contrainte de traduction des paramètres est un obstacle difficile. Il
existe peut-être une solution permettant d'ajouter une sorte de "Script
Parameter", de la même façon qu'on peut ajouter des Script Properties ou des
Script Methods à un objet.


Pour ça je crois que j'avais trouvé quelque chose sur base d'un message
de Jeffrey Snover (évidemment :-) ) ... mais je ne remets plus la main
sur mon projet dans l'immédiat.
Sinon j'avais eu quelques espoirs durant la beta parcequ'il y avait eu
sur l'espace beta une proposition d'évolution de set-alias pour
permettre de faire des alias sur les paramètres aussi.
Si ils le font dans le futur, ça devient un jeu d'enfant :-)

Amicalement,

--
Jean - JMST
Belgium

Avatar
Jean
Re !


un language informatique "parlant" sa langue maternelle


Dans les années 1800 et des poussières, certains avaient poussé un projet de
la même veine : le "BASICOIS".



J' irai voir ce que c'est et ce que VBA fait sur les infos de Jacques.

A l'époque, ça n'avais pas été viable. Alors, que dire, lorsque, comme
actuellement, on se fait incendier, sur la moitié des newsgroups américains,
pour un banal message en français ?

Néanmoins, le principe me semble louable.

Toutefois, je serais curieux de voir ce que ça peut donner dans une langue en
boustrophédon... mdr


J'ai été voir sur Wikipedia ... un mot de plus à mon vocabulaire :-)

--
Jean - JMST
Belgium


Avatar
Jean
Suite de la réponse :

x) le sulfite est une cause importante de migraine. Ma femme est très
sensible aux migraines. Alors, dans le but de maintenir un bon compromis
paix_du_ménage/informatique, je n'utilise que des boissons dans sulfites.


Nous sommes arrivés aux mêmes conlusions :-)

Amicalement,

--
Jean - JMST
Belgium

Avatar
Jacques Barathon [MS]
"Jean" wrote in message
news:
<...>
C'est une des raisons pour lesquelles je n'ai pas encore exposé "l'idée"
sur le groupe US : l'orientation actuelle de PowerShell.
Je me dis que celle-ci devrait "évoluer" une fois PowerShell intégré à
Windows.


Possible. A suivre dans les années à venir.

J'entends d'ailleurs parler de Windows Vienna ou Windows Seven pour le nom
du futur Windows ... je parierais bien pour un Windows Power :-)


Je n'ai pas d'infos sur le sujet, désolé :-)

<...>
"L'idée" est plus de donner la possibilité d'écrire un code "dans sa
langue maternelle" et de pouvoir produire, sur base de ce code, un code
distribuable (et donc exécutable par tous) qui sera donc, selon les us et
coutumes actuelles, "en anglais".


Eventuellement possible en mode de distribution binaire, mais combien de
scripts sont distribués sous la simple forme de fichiers texte? J'écris un
script qui me paraît top cool (pardon, en français: trop d'la bombe). Je
veux que le monde entier le sache, je fais un copier/coller depuis mon
éditeur favori vers le logiciel qui me sert à écrire des billets pour mon
blog. Rien de plus. Dans ce cas, seul la version française a été copiée,
inutilisable sur le poste d'un lecteur dont le système n'est pas français.
Ou alors, cela reviendrait à faire en sorte que chaque poste ait déjà le
code permettant la traduction de "prendre-élément" en "get-item", même si le
poste est en anglais, en japonais ou en bantou. Ca me paraît franchement
difficile à concevoir.

<...>
Accessoirement ça permet aussi de dire à sa secrétaire trilingue Bantou -
Japonais - Français qui ne connait que Word que si elle veux envoyer un
message téléphonique à 20 h (heure à laquelle elle regarde Docteur House)
elle peut faire clic clic sur PowerShell et taper :
téléphoner 6532165468 -aujourd'hui -à 20h -dire "Je suis en train de
regarder Dr House" -raccrocher à la fn du message ... :-)


Ca passe à 20h chez vous? Fichtre, chez nous c'est plutôt en fin de soirée,
autour de 23h. ;-)
Si l'on respecte les normes de PowerShell, la secrétaire devra plutôt taper
"démarrer-appel 6532165468" et non pas "téléphoner ...". :-)

Jacques

Avatar
Jacques Barathon [MS]
"Jean" wrote in message
news:
La contrainte de traduction des paramètres est un obstacle difficile. Il
existe peut-être une solution permettant d'ajouter une sorte de "Script
Parameter", de la même façon qu'on peut ajouter des Script Properties ou
des Script Methods à un objet.


Pour ça je crois que j'avais trouvé quelque chose sur base d'un message de
Jeffrey Snover (évidemment :-) ) ... mais je ne remets plus la main sur
mon projet dans l'immédiat.


Ah bon? Je chercherai.

Jacques


Avatar
Jean
Eventuellement possible en mode de distribution binaire, mais combien de
scripts sont distribués sous la simple forme de fichiers texte? J'écris un
script qui me paraît top cool (pardon, en français: trop d'la bombe). Je veux
que le monde entier le sache, je fais un copier/coller depuis mon éditeur
favori vers le logiciel qui me sert à écrire des billets pour mon blog. Rien
de plus. Dans ce cas, seul la version française a été copiée, inutilisable
sur le poste d'un lecteur dont le système n'est pas français. Ou alors, cela
reviendrait à faire en sorte que chaque poste ait déjà le code permettant la
traduction de "prendre-élément" en "get-item", même si le poste est en
anglais, en japonais ou en bantou. Ca me paraît franchement difficile à
concevoir.

<...>


Si la doc conseille d'être le plus verbeux possible dans des codes
distribués c'est justement pour permettre une "traduction" facile.
Le dictionnaire de "traduction" se trouve dans Get-Alias ... il suffit
de faire les remplacements dans le script distibué pour avoir une
version "traduite" personnalisée ... non ?

Accessoirement ça permet aussi de dire à sa secrétaire trilingue Bantou -
Japonais - Français qui ne connait que Word que si elle veux envoyer un
message téléphonique à 20 h (heure à laquelle elle regarde Docteur House)
elle peut faire clic clic sur PowerShell et taper :
téléphoner 6532165468 -aujourd'hui -à 20h -dire "Je suis en train de
regarder Dr House" -raccrocher à la fn du message ... :-)


Ca passe à 20h chez vous? Fichtre, chez nous c'est plutôt en fin de soirée,
autour de 23h. ;-)
Si l'on respecte les normes de PowerShell, la secrétaire devra plutôt taper
"démarrer-appel 6532165468" et non pas "téléphoner ...".


Pinailleur :P (mais je reconnais la pertinence).
Justement PowerShell est très souple pour se créer un "language" ...

Amicalement,

--
Jean - JMST
Belgium


Avatar
Jacques Barathon [MS]
"Jean" wrote in message
news:
<...>
Si la doc conseille d'être le plus verbeux possible dans des codes

distribués c'est justement pour permettre une "traduction" facile.
Le dictionnaire de "traduction" se trouve dans Get-Alias ... il suffit de
faire les remplacements dans le script distibué pour avoir une version
"traduite" personnalisée ... non ?


Je ne suis pas sûr de bien comprendre. Il faut bien qu'il y ait un
"dictionnaire bilingue" à un moment ou à un autre. Soit du côté de
l'émetteur qui a écrit un script en français et qui devra le traduire avant
de le diffuser, soit du côté du récepteur qui devra traduire le script
français avant de pouvoir le comprendre et éventuellement l'utiliser.

Evidemment, si les personnalisations du langage sont propres à l'utilisateur
(comme dans le cas de la création d'alias non standards) il faudra bien que
ce soit cet utilisateur qui traduise son script avant de le diffuser. Déjà,
là on arrive à un exercice délicat, car à moins d'arriver à automatiser
parfaitement le processus (ce qui est possible mais très délicat), il n'est
pas forcément facile de se plonger dans son propre script pour y déceler
toutes les utilisations d'alias non standards. Sans compter la contrainte
que représente l'obligation de passer par cet exercice à chaque fois qu'on
veut diffuser un script.

Mais bon, dans l'absolu on devrait trouver un moyen de traduire des scripts
d'un langage à l'autre. Reste à valider l'intérêt concret d'une traduction
du langage. L'ensemble des documentations disponibles, que ce soit en ligne
ou sur papier, deviennent inutilisables pour l'ensemble de la planète qui
utilise le produit dans une langue différente. Cela veut dire un intérêt
très limité pour la "communauté" technique, qui préfèrera garder l'usage du
produit anglais plutôt que d'avoir à se référer à des documentations
traduites et donc souvent moins voire pas du tout disponibles et d'avoir à
constamment faire des traductions des exemples trouvés à droite à gauche sur
Internet. Hormis VBA (avec justement un succès très relatif) je n'ai pas
connaissance d'un seul langage qui ait réussi ce pari.

Le seul usage qui pourra prendre, c'est bien celui d'une utilisation très
démocratisée où la secrétaire dictera à son ordinateur des commandes
directement traduites en commandelettes PowerShell. On n'y est pas encore
(pas tout à fait en tout cas), mais il n'est pas interdit de rêver. :-)

Jacques


Avatar
Jean
Je ne suis pas sûr de bien comprendre. Il faut bien qu'il y ait un
"dictionnaire bilingue" à un moment ou à un autre. Soit du côté de
l'émetteur qui a écrit un script en français et qui devra le traduire avant
de le diffuser, soit du côté du récepteur qui devra traduire le script
français avant de pouvoir le comprendre et éventuellement l'utiliser.


Grossièrement, en pré-requis :

-les fichiers "langues" sont standardisés (tout le monde a accès au
même jeu d'alias-traduction)
-ces fichiers "langues" n'autorisent qu'un seul alias par élément (on
ne va pas se compliquer la vie non plus ...)
-nous appellerons ces scripts "traduits" : "localized script"
-les scripts transmis sont des scripts écrit sans alias dans une
langue de base (par respect et courtoisie nous choisissons l'anglais)
que nous appellerons "master script"

A partir de là, un auteur qui reçoit un "master script" peut le
transformer en "localized script" FR.
Un auteur qui conçoit un "localized script" FR peut le transformer en
"master script" et le transmettre à sa copine Népalaise qui peut le
transformer en script SP (oui, elle parle Espagnol :-) ).

Le code suivant (très très grossier lui) *illustre* la chose.
Il faut y comprendre Anglais comme "master language".
Il nécessite une exécution globale ... d'ailleurs question subsidiaire
, comment traduiriez vous de façon succinte en français : "dot source
the script" ?
On suppose que l'on a reçu un "master script" de haute valeur :

#---8<---Script-Anglais.ps1---Jean-JMST-Belgium---
Get-Item c:
#---8<---Script-Anglais---Jean-JMST-Belgium---

...

#---8<------Jean-JMST-Belgium---
#Exportation des alias en cours
Export-Alias -path default-alias.txt

#Suppression des alias en cours
Remove-Item alias:* -force

#Définition des alias "Français"
Set-Alias prendre-élément Get-Item
#Set-Alias ... bla bla bla ...

#Affichage des alias
Get-Alias
''

#Fonction de traduction
function traduire-script($path ,$outpath,$langue){
Get-Content $path|
ForEach-Object{
$L=$_;
Get-Alias|
ForEach-Object `
{
if($langue -eq "FR"){$L=$L -Replace $_.Definition,$_.Name}
else{$L=$L -Replace $_.Name,$_.Definition}
};
Add-Content $outpath -value $L
}
}

#traduction d'un script "Anglais" en "Français"
traduire-script script-anglais.ps1 `
anglais-francais.ps1 `
"FR"

#Affichage du contenu du script traduit
Get-Content anglais-francais.ps1

#Exécution du script traduit
.anglais-francais.ps1

#traduction du script "Français" en "Anglais"
traduire-script anglais-francais.ps1 `
francais-anglais.ps1 `
"EN"

#Affichage du contenu du script traduit
Get-Content francais-anglais.ps1

#Exécution du script traduit
.anglais-francais.ps1

#Suppression des alias "Français"
Remove-Item alias:* -force

#Restauration des alias d'origine
Import-Alias -path default-alias.txt

#Suppression des fichiers créés par le script
Remove-Item anglais-francais.ps1
Remove-Item francais-anglais.ps1
Remove-Item default-alias.txt
#---8<------Jean-JMST-Belgium---

Voilà pour le principe.
Pour le reste ... comme vous dites ... on peut toujours rêver :-)

Pour ce qui est de l'intérêt de la "communauté technique", pensons aux
générations futures ... c'est un peu comme l'évolution des moeurs ou le
passage à l'Euro ... on s'y fait :-)
L'intérêt étant de donner l'occasion à plus de gens de mettre le pied à
l'étrier de la programmation, ce n'est sûrement pas la communauté
technique actuelle qu'il faut cibler dans l'immédiat mais l'utilisateur
de base, qui voudrait bien mais pour l'anglais c'est du Chinois :-).
Evidemment, c'est un investissement sur le long terme et très coûteux.
Une question de volonté aussi ... *presque* politique :-)

Je serais curieux aussi de voir le gain de productivité engendré par le
fait d'écrire du code dans sa langue maternelle (ce que seul les
anglophones de souche peuvent réellement pratiquer à l'heure actuelle).

Enfin ... bon ... on n'y est pas, et nous sommes lundi :-)


Amicalement,

--
Jean - JMST
Belgium

Avatar
Jacques Barathon [MS]
"Jean" wrote in message
news:
<...>
Grossièrement, en pré-requis :

-les fichiers "langues" sont standardisés (tout le monde a accès au même
jeu d'alias-traduction)
-ces fichiers "langues" n'autorisent qu'un seul alias par élément (on ne
va pas se compliquer la vie non plus ...)
-nous appellerons ces scripts "traduits" : "localized script"
-les scripts transmis sont des scripts écrit sans alias dans une langue de
base (par respect et courtoisie nous choisissons l'anglais) que nous
appellerons "master script"


C'est bien ce que j'avais compris. En tant qu'utilisateur potentiel, je
serais freiné par la nécessité de passer mon script par un traducteur pour
passer de la version traduite à la version "master". J'irai même jusqu'à
dire qu'en tant qu'utilisateur "de base", il y a une forte chance pour que
je ne sois même pas au courant de cette contrainte.

On retrouve là le même problème qui agite l'échange des documents Word.
Doit-on enregistrer son document au format RTF, ou au format Word 97 en
tablant sur le fait que plus personne n'aura un traitement de texte
antérieur? A ma connaissance, pratiquement personne ne fait cet effort. On
met en ligne son document tel quel, et à charge de l'utilisateur intéressé
de se débrouiller pour pouvoir le lire. Je schématise un peu, mais c'est
bien le principe qui domine.

<...>
Il nécessite une exécution globale ... d'ailleurs question subsidiaire ,
comment traduiriez vous de façon succinte en français : "dot source the
script" ?


Bonne question... "exécuter en global" peut-être, pour reprendre votre
propre terminologie. Ou on pourrait inventer l'expression "pointer le
script", pas très heureux...

<...>
Pour ce qui est de l'intérêt de la "communauté technique", pensons aux
générations futures ... c'est un peu comme l'évolution des moeurs ou le
passage à l'Euro ... on s'y fait :-)


On se fait aussi bien à l'utilisation de termes anglais, dans la mesure où
ils sont standardisés et communs à toute la population concernée. Voyez
Michel, il est totalement réfractaire à la lecture d'un simple mail en
anglais, mais ça ne l'empêche pas d'avoir acquis une forte expertise dans
des langages de programmation exclusivement anglophones (Python, Paradox,
batch pour ne citer que les plus célèbres dont il se soit vantés ;-)).

L'intérêt étant de donner l'occasion à plus de gens de mettre le pied à
l'étrier de la programmation, ce n'est sûrement pas la communauté
technique actuelle qu'il faut cibler dans l'immédiat mais l'utilisateur de
base, qui voudrait bien mais pour l'anglais c'est du Chinois :-).


A mon avis, l'utilisateur de base ne s'amusera jamais à taper des commandes
dans une console. Ca n'a jamais été le cas, et je ne crois pas que ça le
devienne dans un avenir proche (je veux dire de notre vivant). Je crois plus
à la fusion des interfaces graphique et vocale, avec un moteur comme
PowerShell pour convertir les interactions en commandes adressées au système
et/ou aux applications. C'est d'ailleurs pour cela que PowerShell a été
conçu pour être plus qu'une simple console, mais également un moteur
utilisable par n'importe quelle application (voir les nouveaux produits
serveur de MS, ou les différents IDE fournis par des éditeurs tiers).

Jacques

1 2 3 4