Claude SIMON a écrit 539 commentaires

Ça ne serait pas la version 10 S de Windows qui est installée ? Comme c'est une version soit-disant sécurisée de Windows 10, il n'est, en théorie, possible d'installer une application qu'à partir du store.
Je n'ai jamais eu ce comportement en installant Python sur un Windows 10, que ce soit la version Pro ou Famille, d'où ma question…

Pour nous émanciper des géants du numérique : Zelbinium !

Le toolkit Atlas a d'abord été développé pour Java, Node.js et PHP (cette dernière version n'est plus disponible à cause de problèmes concernant le multithreading), et s'appuyait sur du code natif développé en C++. Mais la présence de code natif complexifie énormément l'installation, ce qui peut décourager ceux qui étaient tentés de l'essayer.

Du coup, j'ai développé dans chacun des langages pour lequel le toolkit était disponible, puis ensuite en Perl, Python et Ruby, des fonctionnalités permettant de déporter tout le code natif sur un serveur. En fait, le toolkit Atlas, en l'état, est une version de démonstration d'une technologie que j'ai baptisée XDHTML et qui permettra, à terme, de coder avec des technos web, mais sans JavaScript (sauf pour la version Node.js), une interface graphique web, desktop et/ou mobile.

Ce qui a été implémenté dans chacun des langages pour lequel le toolkit est disponible, c'est juste le protocole permettant de communiquer avec le proxy. À terme, le proxy existera également sous forme de bibliothèque dynamique directement chargée par l'application utilisant le toolkit Atlas, et cette dernière communiquera alors avec le proxy, non plus via une connexion réseau, mais en appelant directement les fonctions natives du proxy. De ce fait, il n'y aura plus de problèmes de latence.

Pour nous émanciper des géants du numérique : Zelbinium !

Je ne sais pas si c'est ce à quoi tu pensais, mais j'ai réalisé un petit schéma que je présente dans ce commentaire…

Pour nous émanciper des géants du numérique : Zelbinium !

J'ai relu mon commentaire, et il y a effectivement quelques raccourcis, involontaires, qui ne facilitent pas la compréhension. Cependant, je crains de ne pouvoir te répondre précisément, car il y a des aspects du fonctionnement de JustPy et des composants sur lesquels il s'appuie qui m'échappent encore. Néanmoins, je vais donner quelques précisions sur le fonctionnement du toolkit Atlas, en espérant que cela apporte tout de même quelques éléments de réponse…

Concernant le poids des paquets respectifs, j'ai récupéré les données suivantes sur Pypi.org :

• taille du paquet :
  • JustPy : ~4 Mo,
  • toolkit Atlas : ~20 Ko ;
• paquets installés en sus :
  • JustPy : starlette, uvicorn, itsdangerous, websockets…,
  • toolkit Atlas : aucun.

Les différences entre JustPy et le toolkit Atlas proviennent du fait que, avec JustPy, tout ce qui est nécessaire à son fonctionnement est rapatrié sur et exécuté par la machine du développeur, alors que, dans le cas du toolkit Atlas, le gros du traitement est déporté sur un serveur, auquel se connecte le toolkit.

Voici un petit schéma qui, j'espère, clarifie cela :

xdhqxdh est une bibliothèque dynamique chargée par xdhwebq. xdhqxdh relaie les évènements associés aux actions de l'utilisateur vers le toolkit Atlas, et, en retour, traduit les primitives envoyées par ce dernier en opérations sur le DOM à destination du navigateur web. xdhwebq permet d'exécuter xdhqxdh dans un environnement web, sachant qu'il existe un équivalent permettant de l'exécuter dans un environnement bureau (interface desktop).

Il y a donc deux serveurs, l'un est un serveur web classique (Apache, NGINX…), et l'autre est constitué par le couple xdhwebq/xdhqxdh, mais le développeur n'a à installer aucun des deux, le toolkit Atlas se connectant automatiquement par défaut à un serveur public que je mets gratuitement à disposition. C'est pour cela qu'une application développée avec le toolkit Atlas est automatiquement et instantanément accessible de tout l'internet via l'URL affichée dans la console à son lancement…

Si tu as d'autres question concernant le toolkit Atlas, que ce soit sur son fonctionnement ou des problèmes que tu aurais rencontrés dans sa mise en œuvre, n'hésite pas. Ça me donnera matière à enrichir la documentation, qui en a bien besoin…

Pour nous émanciper des géants du numérique : Zelbinium !

Un peu basé sur le même concept, on retrouve JustPy.
Il integer les composants Quasar et Highchart.

J'ai un peu regardé JustPy, que je ne connaissais pas du tout. Je ne connais pas non plus Quasar et Highchart mais, vu les similitudes entre JustPy et le toolkit Atlas, il doit y avoir moyen de les intégrer également, ou du moins de les gérer de la même façon que Matplotlib dans cet exemple : https://repl.it/@AtlasTK/atlas-python, clic sur bouton vert Run, taper o puis entrée, et clic sur l'URL affichée dans la console (code source : https://repl.it/@AtlasTK/atlas-python#examples/MatPlotLib/main.py)…

L'idée consiste à déporter la moindre action qu'on effectuerait sur le client en JS, coté serveur, en ne transférant que les données par Websocket.

C'est effectivement la même idée qu'il y a derrière le toolkit Atlas.

Pour ce dernier, c'est sympa pour prototyper rapidement mais j'ai quelques doutes sur le passage à l'échelle.

Je ne sais pas pour JustPy, mais, pour le toolkit Atlas, la facilité de mise en œuvre et d'utilisation a été privilégiée à la performance, sachant qu'il y a déjà une multitude de frameworks, surtout web, qui offrent d'excellentes performances.
J'utilise la technologie qu'il y a derrière le toolkit Atlas pour l'interface web de certains logiciels métiers que j'ai développés pour mes clients et, dans ce contexte, les performances sont largement suffisantes.

Hormis le fait que l'interface est en mode déclaratif, en quoi Atlas est-il différent, notamment en terme d'architecture ?

Le toolkit Atlas s'appuie sur un serveur. Il reçoit de ce dernier les actions réalisées par l'utilisateur, et lui retourne des primitives (inspirées de l'API DOM) correspondants aux modifications à apporter à l'interface. C'est ce qui fait que le toolkit Atlas est très léger et n'a pas de dépendances, puisqu'il n'embarque que de quoi communiquer avec le serveur, les primitives étant traitées par ce dernier. En outre, grâce à cette architecture, contrairement à JustPy et autres frameworks web, l'application n'a pas à être déployée pour être accessible d'Internet. On peut bien sûr également utiliser son propre serveur, le code source de ce dernier étant publié sous licence libre.

Belle initiative cependant.

Merci !

Pour nous émanciper des géants du numérique : Zelbinium !

Merci d'y avoir pensé ; j'avais oublié de le mentionner dans l’espace de rédaction…

Pour nous émanciper des géants du numérique : Zelbinium !

Voilà le code d'une application un peu plus évoluée. Il s'agit d'un chatroom basique.

import atlastk, threading

BODY="""
<input data-xdh-onevent="Submit"/>
<fieldset>
  <legend>messages</legend>
  <ul id="Messages"/>
</fieldset>
"""

messages = []
lock = threading.Lock()


class Chat:
  def __init__(self):
    self.next = 0  #index du prochain message.


def add_message(message):
  global messages, lock

  lock.acquire()
  messages.append(message)
  lock.release()


def get_messages(index):
  global lock

  html = ""

  lock.acquire()

  for i in range(len(messages)-1,index-1,-1):
    html += f"<li>{messages[i]}</li>"

  lock.release()

  return html, len(messages)


def display_messages(index,dom):
  html, new_index = get_messages(index)

  if html:
    dom.begin("Messages",html)

  return new_index


def ac_connect(chat,dom):
  dom.inner("", BODY) # "" désigne l'élément racine.
  chat.next = display_messages(chat.next, dom)
  dom.focus(dom.first_child(""))  # voir commentaire précédent.


def ac_submit(chat,dom,id):
  add_message(dom.get_content(id))
  atlastk.broadcast_action("Display")
  dom.set_content(id,"")


def ac_display(chat,dom):
  chat.next = display_messages(chat.next, dom)


CALLBACKS = {
  "": ac_connect,
  "Submit": ac_submit,
  "Display": ac_display
}

atlastk.launch(CALLBACKS, Chat)

Pour une démonstration en ligne :
- suivre ce lien ;
- cliquer sur le bouton vert Run ;
- cliquer sur l'URL qui s'affiche dans la console.

En cliquant sur le code QR, on ouvre une autre session. On peut également ouvrir une session sur un smartphone ou une tablette en scannant ce QR code.
Tout message saisit dans une session va s'afficher dans toutes les autres sessions, conformément à ce que l'on attend d'un chatroom.

Je t'invite à nous montrer le code source de cette même application codée avec une technologie que tu estimes équivalente au toolkit Atlas, comme cela on disposera d'éléments factuels. Si cette techno. est vraiment équivalente, coder cette application ne devrait pas prendre plus d'une demi-heure, vu que c'est le temps que cela m'a pris, sachant, en outre, que Python n'est pas mon langage de programmation usuel.

Pour nous émanciper des géants du numérique : Zelbinium !

• ça s'exécute via un serveur http://faas1.q37.info ça me dérange. Je n'ai pas trouvé dans la doc comme faire tourner le truc en local (pour remplacer un toolkit local, je m'attends à qqchose qui tourne en local)

A l'origine, le toolkit Atlas était un binding vers une bibliothèque C++ qui constitue le cœur du projet, et il était disponible pour Java, Node.js et PHP (la version PHP est actuellement suspendue à cause de certaines considérations relatives au multithreading).
Sous cette forme, le toolkit Atlas était assez complexe à installer, du fait qu'il fallait également installer la bibliothèque C++, et j'étais d'avis que cela constituait un obstacle quasi insurmontable à son adoption.
J'ai donc développé un protocole qui permettait au toolkit d'échanger avec la bibliothèque C++ via une communication réseau, ce qui me permettait de déporter cette bibliothèque sur un serveur, et ainsi ne pas avoir à la fournir avec le toolkit.
Cette version du toolkit était en fait pensée comme une version de démonstration du toolkit version binding. Et c'est la forme sous laquelle le toolkit est actuellement disponible. Dans la foulée, j'ai également développées les versions Perl, Python et Ruby.
Bref, tout ça pour signaler qu'une version binding du toolkit pour Python, que j'ai de toute manière l'intention de développer, est parfaitement envisageable à relativement court terme si tu penses qu'elle convient mieux.

Sinon, il y aurait également l'option desktop, basée sur Electron ; c'est un mode d'utilisation de ma bibliothèque C++ que je mets à disposition de mes clients. L'adapter au toolkit Atlas est également dans mes projets.

Dans l'intervalle, il y cela…

• ça me paraît nettement plus difficile à debugger que du pur python

Euh…, le toolkit est en pur Python ; par contre, il est multithreadé. C'est peut-être cela qui pose problème…
Je n'ai jamais fait de développement Python avant ce toolkit ; à part Pypi, je ne connais pas grand chose des outils utilisés pour les développements Python.

• pour quelqu'un qui connait basiquement le HTML, ça me semble très simple d'accès, notamment avec le mécanisme de callback associés à des widgets "HTML"

C'est typiquement pour ce genre profil que le toolkit a été développé, vu que c'est le mien :-)…

• ça a l'air très lent

J'ai quelques pistes pour l'accélérer, mais vu le principe de fonctionnement du toolkit, ça ne sera jamais un foudre de guerre, mais ça dépend aussi beaucoup de la qualité du réseau. Néanmoins, la version binding devrait être nettement plus rapide…

• je suis obligé d'afficher les outils de développement dans Firefox pour que l'écran ne reste pas blanc

Peut-être y a-t-il un lien avec https://github.com/epeios-q37/atlas-python/issues/1… Si jamais tu as un quelconque renseignement qui pourrait faire avancer le schmilblick, je suis preneur :-)…

Conclusions :
je suis intéressé par une version documentée du toolkit

Vu que tu as utilisé le toolkit, pourrais-tu m'indiquer ce qui, en terme de documentation, t'aurais été utile pour mettre en œuvre plus rapidement et/ou efficacement le toolkit, que je puisse améliorer la documentation sur ce(s) point(s) ?

je suis intéressé par "pouvoir faire tourner le code en interne" (sans passer par un serveur extérieur)

Comme dit plus haut, il y a cela, en attendant la version binding ou desktop…

je confirme que ce toolkit a un intérêt ; par contre de ce que j'en comprends je le présenterais comme un "toolkit de développement rapide d'outils internes". Le fait que ce soit du web, que ce soit SPA, ce sont des enjeux techniques mais ce n'est pas ça qui va me convaincre d'utiliser le toolkit.

J'ai changé plusieurs fois d'angle d'attaque concernant la communication, notamment en mettant en avant le coté développement de GUI rapide et facile ; c'est d'ailleurs toujours ainsi que le toolkit est présenté dans les dépôts GitHub. Mais, d’après certaines discussions que j'ai pu avoir, l'angle SPA directement accessible sans configuration ni déploiement suscite également de l'intérêt.

Et merci d'avoir testé le toolkit et d'en avoir fait ce retour…

Pour nous émanciper des géants du numérique : Zelbinium !

Tu as développé la techno dans le cadre de ton activité ?

Pour mes clients, j'utilise une bibliothèque C++ maison pour développer les interfaces graphiques. Je la trouvais pratique, et la rendre disponible pour des langages populaires que je n'avais jamais eu l'occasion de pratiquer me semblait une façon comme une autre de faire de la veille technologique…

Question : étant donné que l'exécution du code nécessite un serveur "externe", comment traites-tu (si tu sais le faire) des formulaires HTML proposant de sélectionner un fichier ?

Le sélecteur de fichier HTML (<input type="file"/>) ne permet hélas pas (ou je n'ai pas trouver comment faire) de récupérer le chemin du fichier sélectionné par l'utilisateur pour des raisons de sécurité. La seule solution, c'est d'en coder l'équivalent. C'est d'ailleurs un de mes projets que de proposer ce genre de widgets sous forme d'extension…

Lorsque je teste, le code s'exécute bien sur ma machine, on est d'accord ? le serveur est uniquement un "proxy" d'accès ?

Tout à fait. Le proxy ne fait que relayer les actions de l'utilisateur dans un sens, et les modifications opérées sur le DOM dans l'autre.

Tu aurais un schéma technique de fonctionnement ?

Un tel schéma n'existe pas actuellement, mais je vais en réaliser un ; ça permettra d'enrichir la documentation…

Pour nous émanciper des géants du numérique : Zelbinium !

Salut !

Salut !

Bon, je vois que tu tiens toujours à ton toolkit :)

Ben je ne vais pas l'abandonner alors qu'il connaît un succès croissant :-) …

Tu as gagné en clarté dans tes explications, mais en fait on ne voit toujours pas en quoi tu simplifies le développement web.

Le toolkit Atlas n'est pas conçu pour le développement web. Il est conçu pour le développement d'interfaces graphiques. Simplement, au lieu de s'appuyer sur GTK, Qt ou encore wxWidget, il s'appuie sur des technos web (HTML(/CSS) et DOM). Ce qui fait que des applications utilisant le toolkit Atlas sont de facto des applications web, mais ce n'est pas le but premier.

Selon moi, toutes tes nouvelles notions complexifient le truc !

Justement, il n'y a pas de nouvelles notions. Le toolkit Atlas s'appuie uniquement sur des technologies qui ont fait leurs preuves et qui sont ultra-documentées, à savoir HTML(/CSS) et DOM. La particularité du toolkit Atlas est que les manipulations sur le DOM ne se font plus en JavaScript (ou assimilé) dans le frontend, mais directement dans le backend, avec le langage de son choix. De ce fait, il n'y a plus à proprement parlé de backend et de frontend.
De la même manière, le toolkit Atlas ne s'appuie par sur une architecture MVC. Note que je n'ai rien contre le principe derrière MVC, — j'en utilise moi-même un équivalent dans toutes mes applications — mais il y a des situations où elle est inopportune, par exemple dans le cadre d'une initiation à la programmation…

Peux-tu par exemple comparer Atlas à d'autres façons de faire et mettre côte à côte deux exemples pour démontrer que tu simplifies les choses par rapport à du classique Node/Vue ou autre ? Ou même un simple développement web en Python avec un Bottle par exemple ?

Je n'ai jamais entendu parler de Bottle, mais, après quelques recherches, je suppose que tu parles du framework Python…

Si tel est le cas, à l'instar de Django cité dans un précédent commentaire, il me semble que Bottle ne suffise pas à lui seul pour développer une SPA, donc la comparaison avec le toolkit Atlas est délicate.

J'ai néanmoins tenté d'extrapoler le "Hello World", écrit avec Bottle, que j'ai trouvé ici et qui ressemble à ça :

from bottle import route, run

@route('/hello')
def hello():
    return "Hello World!"

run(host='localhost', port=8080, debug=True)

Voilà un exemple de quelque chose, écrit avec le toolkit Atlas, qui s'en rapproche :

import atlastk

atlastk.launch({"": lambda dom: dom.inner("", "<h1>Hello World!</h1>")})

Ce programme va ouvrir un navigateur web et lui passer une page contenant, entre autres, le code HTML <h1>Hello World!</h1>.

Bon, comme dit, Bottle et le toolkit Atlas n'ayant pas vraiment la même finalité, la comparaison me semble d'un intérêt assez limité.

Ceci dit, si tu as des exemples de SPA, pas trop gros évidemment, réalisées avec Bottle, ou un autre outil, je veux bien écrire son équivalent avec le toolkit Atlas…

Tu le dis toi même, tu ne connais pas trop le développement Web et c'est là où est ta faiblesse je pense. Tu penses que tu simplifies les choses, mais en fait non.

Je ne suis pas développeur d'applications web, mais il m'arrive tout de même assez souvent de développer des interfaces web pour mes clients. Et tu penses bien que je me suis renseigné sur ce qui existait en terme d'outils dans ce domaine avant de me lancer dans le développement de mon propre outil, faute de solution qui me convienne… (je sais que certains seront tentés, mais si vous relisez attentivement ce que j'ai écrit, vous vous apercevrez que dégainer le syndrome NIH n'est pas de circonstance…)

Pour nous émanciper des géants du numérique : Zelbinium !

Je trouve cette clarification très importante et intéressante. Je vois du coup le framework comme un outil de programmation rapide d'interface utilisateur.

C'est très exactement l'idée derrière ce toolkit.

Dans le cas du développement d'un outil de gestion, du coup, j'aurais tendance à le comparer dans une certaine mesure à Django que j'utilise personnellement pour dév des outils perso via quasi-exclusivement Django Admin (l'interface d'admin de Django).

Je ne connais pas Django, mais, pour ce que j'en ai vu, il ne peut, à lui seul, suffire à développer une SPA. Du coup, ce n'est pas vraiment comparable, à moins qu'il n'y ai quelque chose qui m'échappe…

Concrètement, dans quel cas conseilles-tu d'utiliser le framework ? Pour développer un nouvel outil ? Proposer une interface utilisateur à un outil ou du code existant sous forme de CLI ou de lib ?

Il existe beaucoup de toolkits ou de frameworks avec lesquels on peut développer des interfaces graphiques. Ces outils sont, pour la plupart, très performants, au prix d'une certaine complexité qui à tendance à rebuter ceux qui aimerait faire de la programmation mais n'ont pas le temps d'apprendre à maîtriser ces outils.
Les bibliothèques logicielles qui, à l'instar du toolkit Atlas, font le choix d'offrir moins de performances au profit de plus de facilité d'utilisation ont généralement pour inconvénient d'être volumineuses par eux-mêmes et/ou de par les bibliothèques qu'elles nécessitent, ce qui peut également constituer un frein à leurs utilisations.
Le toolkit Atlas est très léger (quelques dizaines de Ko tout compris pour la version Python) et sa mise en œuvre est facilitée par son utilisation de technologies ultra-documentées (HTML(/CSS) et DOM). De ce fait, cela incitera peut-être plus de gens à l'utiliser pour développer, pour leurs propres logiciels, en plus d'une CLI, une GUI…

En tout cas, je pense Le toolkit Atlas peut être utilisé dans de nombreuses circonstances, dont quelques-une sont détaillées ici (en anglais). Je répondrais volontiers à toute question concernant ces utilisations…

Pour nous émanciper des géants du numérique : Zelbinium !

En plus des logiciels dédiés, il faut disposer d'un serveur web qu'il faut configurer pour une utilisation des WebSocket.

Il y a une documentation dédiée, en anglais. Je l'ai déjà remaniée pour clarifier certains points ayant fait l'objet de questions de la part d'utilisateurs, mais je suis toujours preneur de suggestions d'améliorations…

Pour nous émanciper des géants du numérique : Zelbinium !

[…]

Déjà, le côté sécurité ne semble pas être pris en compte :

   html += f'<tr id="{contactId}" data-xdh-onevent="Select" style="cursor: pointer;">'
   for key in contact:
     html += f'<td>{contact[key]}</td>'
   html += '</td>'

Soit je rate quelque chose, soit il n'y a aucun échappement des caractères <, > et &.

Ils sont échappés lors du traitement de la saisie, avant stockage.

L'élaboration de HTML destiné à être injecté dans le DOM peut se faire de plusieurs manières. La méthode présentée ici est la plus simple et la plus aisément compréhensible, mais nécessite effectivement de prendre quelques précautions.
Sinon, peut utiliser un des nombreux moteurs de template existants, qui prennent normalement en compte ce genre de problématiques.
Concernant le toolkit Atlas, il existe un objet permettant de construire un arbre HTML, ou XML qui est ensuite transformé en HTML à l'aide de XSL, et qui procède aux échappement nécessaires…

Et on perd aussi les retours à la ligne pour la note (il y a 2 lignes dans le textarea, mais une seule dans le tableau).

Là, c'est un effet de bord qui m'arrangeait, vu que ça fait gagner de la place ; du coup, je l'ai laissé :-).

Et sur la partie visibilité des boutons, je suis perdu : pourquoi ajouter/retirer des balises <style> du DOM plutôt que d'ajouter/retirer directement les boutons ?

Les balises style ne sont pas ajoutées/retirées, mais activées/désactivées. Activer/désactiver un bouton aurait visuellement comme effet de le griser, et non pas de le faire disparaître, comme c'est le cas ici.

Ici, l’évènement est un clic sur une ligne du tableau contenant la liste des contacts, évènement auquel a été associée l’action Select via l’attribut data-xdh-onevent.

Je suppose que ça veut dire que l'on ne peut faire cette action qu'à la souris, pas au clavier. Bonjour l'accessibilité !

C'est exact, je n'y ai pas pensé. Il faudrait probablement revoir le code HTML.

Et, franchement pour donner envie, ça aurait été bien de faire quelque chose d'un plus joli. Ce n'est quand même pas très compliqué de prendre un framework CSS comme bootstrap et l'utiliser ici.

Je n'ai jamais utilisé bootstrap, ou un quelconque framework similaire, mais je pense que son utilisation aurait probablement alourdit le programme. Mais je suis d'accord que l'apparence de ce programme est plutôt rustique, on va dire, mais, n'étant pas développeur web, mes connaissances sont plutôt limitées en la matière. Les contributions sont bienvenues…

Je ne suis probablement pas le public visé, mais je trouve que c'est assez difficile de comprendre comment ça fonctionne à la lecture de cet article (probablement, faute de repères par rapport à ce que j'ai l'habitude). Et j'ai l'impression que c'est vite limitant (comme faire des transitions CSS ? de l'infinite scroll ? gérer du routage avec différentes URL ?).

Comme je l'ai indiqué plus haut, je ne suis pas développeur web, ce qui explique sans doute que je n'ai jamais eu de demande de la part de mes clients qui ai nécessité des transitions CSS ou de l'infinite scroll (enfin, je ne crois pas, vu que je n'ai qu'une très vague idée de ce en quoi cela consiste). Maintenant, à supposer que ce ne soit pas possible facilement avec le toolkit Atlas en l'état, il est tout à fait envisageable de le modifier pour remédier à cela.
Concernant le routage d'URL, cela me semble être typiquement une fonctionnalité d'application web. Or, il existe quantité de frameworks qui offrent ce genre de fonctionnalités, et bien plus. L'objectif du toolkit Atlas n'est pas d'être un n^ième framework web, mais d'offrir un moyen simple et rapide de programmer une interface graphique, d'où l'absence de certaines (de la plupart ?) des fonctionnalités que l'on trouvent typiquement avec ce genre de frameworks. Que l'utilisation du toolkit Atlas transforme un programme en application web n'est qu'un effet secondaire…

Pour nous émanciper des géants du numérique : Zelbinium !

Tout d'abord merci beaucoup pour tout le travail accompli sur le toolkit comme sur ces dépêches !

Merci de prendre le temps de s'y intéresser :-) !

J'ai quelques scripts python qui mériteraient bien une GUI et j'ai eu quelques soucis avec le TK de base fourni avec Python. J'étais sur le point de me lancer dans l'apprentissage de PyQT (et de QT par la même occasion) mais Atlas pourrait être une alternative moins coûteuse en temps d'apprentissage, avec la possibilité en plus de partager les applis plus facilement via les portails.

C'est précisément pour cela que ce toolkit a été conçu.

La question que je me pose est celle de la sécurité des applications mises à disposition sur ces portails, en particulier dans l'hypothèse où l'on utilise le portail public. L'applicatif est sensé gérer tout le côté authentification et gestion des accès, c'est bien ça ?

À l'image de la philosophie derrière UNIX, le toolkit Atlas ne fait qu'une seule chose, et tente de le faire le mieux possible, à savoir faciliter le développement d'une interface graphique. De ce fait, il n'offre aucune fonctionnalité en terme d'authentification, de gestion d'accès, voire relatifs aux bases de données, comme peuvent le proposer certains frameworks. D'où son appellation de toolkit, et non de framework.

Et comme il n'y a pas de serveur web, l'application a potentiellement accès à tout le disque dur sur lequel le programme tourne, ou en tout cas à toutes les données auxquelles a accès l'utilisateur actif ?

Ce n'est probablement pas évident au premier abord, mais l'ambition du toolkit Atlas n'est absolument pas d'être une alternative aux traditionnels frameworks de développement d"applications web, mais d'offrir un moyen simple et rapide d'ajouter une interface graphique à n'importe quel programme Python (dans le cas de la version Python du toolkit). Par conséquent, l'utilisation du toolkit Atlas dans un programme Python n'a pas plus d'influence sur ce à quoi ce programme Python a accès que s'il utilisait un toolkit comme PyQT. Le fait que l'utilisation du toolkit Atlas transforme de facto le programme en application web n'est, en quelque sorte, qu'un effet secondaire…

Dans ma compréhension, ce serait pour ça entre autre que l'accent est mis sur le prototypage d'applications plutôt que sur le développement d'applis web destinées à être mises en production (outre les limitations fonctionnelles potentielles par rapport à un client écrit entièrement en js) ? En gros il faut éviter de mettre des données de production dans de telles applis ?

Entre le programme et le serveur auquel il se connecte, la connexion n'est, à ce jour, pas chiffrée. Ce qui n'empêche pas le toolkit Atlas d'être utilisé en production, mais c'est clairement dans le cas où les données transitant entre l'application et le serveur ne sont pas sensibles, ou alors c'est avec mise en œuvre de la solution de contournement décrite plus bas.
Actuellement, le toolkit, quelque soit sa version, est très léger et autonome, sans dépendances. Toutes les version du toolkit, même les versions qui peuvent être installées avec un gestionnaire de paquets, peuvent être fournies sous forme d'archive auto-suffisante, ce qui facilite son utilisation notamment dans un cadre éducatif. Ajouter le chiffrement rendrait l'installation du toolkit beaucoup plus compliquée, sans compter le travail que cela représente en matière de développement, tant au niveau du toolkit proprement dit, vu sa disponibilité pour plusieurs langages, que du serveur auquel il se connecte.
Cela ne signifie pas que ce chiffrement ne sera jamais disponible, mais ce sera probablement sous forme d'extension, ou d'une version distincte, peut-être spécialement destinée à un usage professionnel, avec connexion à serveur dédié…
On peut actuellement contourner ce problème en installant le logiciel serveur (qui est diffusé sous licence libre) sur une machine sur laquelle on installerait également le programme Python. De ce fait, les échanges programme/serveur ne sortiraient pas de la machine et ne pourraient donc être que très difficilement interceptés.

Merci d'avance pour ces éclaircissements !

S'il y a d'autres points à éclaircir, ne pas hésiter à m'en faire part…

Pour nous émanciper des géants du numérique : Zelbinium !

Le délai de 30 jours est écoulé. Pas de notification, mais plus aucune trace d'une quelconque revendication de droits d'auteur. Aucun historique des échanges n'est présent sur mon compte Youtube, que ce soit concernant les revendications ou mes contestations.

Tout ça m'a l'air d'être automatisé au maximum. À la moindre correspondance détectée par Content ID, on est présumé coupable, c'est-à-dire privé de ses droits d'auteurs au profit du présumé détenteur de ces droits déterminé par Content ID. Si l'on conteste, c'est ce même présumé détenteur qui traite cette contestation. J'ignore ce qui se passe si ce dernier rejette la contestation…

Vu que je suis, du moins à ce jour, reconnu comme étant l'auteur du contenu que j'ai posté, j'ai regardé, par simple curiosité, si je pouvais déclarer ce contenu auprès de Content ID pour qu'il protège mes droits. Pour le coup, la procédure¹ est loin d'être automatisée, et, me concernant, n'a probablement aucune chance d'aboutir…

---

1. Si vous utilisez un navigateur avec lequel vous vous êtes déjà connecté avec un compte Google, ce lien peut ne pas être accessible sans avoir à vous connecter avec un compte Google …

Pour nous émanciper des géants du numérique : Zelbinium !

[…] j'aimerais qu'il fasse des choses compliquées avec du Python […] Probablement qu'il fait partit de ces personnes qui ont besoin de voir très rapidement un résultat sans être envahit de concepts

Je me permet de m'immiscer dans ce fil pour parler du toolkit Atlas, qui peut peut-être répondre à cette problématique.

Ainsi, il peut commencer par « dessiner », en HTML, l'interface d'une application, ou d'un jeux, en utilisant l'un des nombreux éditeurs disponibles en ligne, ou en éditant directement sur son ordinateur un fichier texte qu'il ouvrira dans un navigateur pour voir le résultat. Une fois cette interface « dessinée », il peut, pour rendre les choses plus concrètes, l'ouvrir sur son smartphone (s'il en possède un), ou éventuellement une tablette. Ça se fait très facilement, en quelques lignes de Python, grâce au toolkit Atlas. Ensuite, il peut progressivement aborder les différents concepts de programmation au travers du codage, toujours en Python, des différents gestionnaires d'évènements nécessités par son application, avec la possibilité, toujours histoire de rendre les choses plus concrètes, de voir le résultat sur son smartphone.

Mais c'est peut-être déjà trop compliqué ; en tant que développeur professionnel, j'ai du mal à apprécier le niveau de difficulté que cela représente pour un novice. D'autant que la documentation existante n'est pas vraiment adaptée, même si des efforts sont fait pour améliorer la situation. Cependant, avec l'assistance de quelqu'un qui s'y connaît en programmation, c'est peut-être jouable.

Il y a une sorte de tutoriel en gestation dans l'espace de redaction ; ça peut aussi aider.

Pour nous émanciper des géants du numérique : Zelbinium !

C'est la crainte de perdre cette possibilité qui m'avait fait hésiter à aller chez un fournisseur externe, mais j'en ai trouvé un qui :

• autorisait la création d'alias (mais en nombre limité) ; finalement, j'utilise cette fonctionnalité assez peu grâce aux trois fonctionnalités suivantes ;
• gère le signe + : toto+…@exemple.com se retrouve dans toto@exemple.com, toto pouvant être un alias ;
• permet d'associer un autre domaine au domaine principal (…@autre-exemple.org se retrouve dans …@exemple.com) ;
• propose un compte catch-all, c'est-à-dire que n'importe quoi en @exemple.com qui ne correspond pas une adresse existante ou n'est pas géré par l'une des fonctionnalités ci-dessus se retrouve dans ce compte ;
• obtient le score maximal aux tests anti-spam.

Pour nous émanciper des géants du numérique : Zelbinium !

À l'époque, il y avait aussi l'AmigaOS…

Pour nous émanciper des géants du numérique : Zelbinium !

Ce qui serait bien comme solution, c'est ce qui existe dans l'édition de partitions musicales.
D'un coté, on a Lilypond, qui serait l'équivalent de LaTeX, et de l'autre, des logiciels comme Frescobaldi, qui serait l'équivalent des logiciels WYSIWYG. Sauf que, dans ce cas de figure, Frescobaldi génère des fichiers au format Lilypond.

Lorsque j'écris une partition musicale, j'utilise dans un premier temps un petit utilitaire de mon cru qui génère des fichiers au format Lilypond, ce qui est facilité par le fait que le format Lilypond est un format texte, que je complète ensuite avec à l'aide de Frescobaldi, et je termine en intervenant directement sur les fichiers Lilypond pour d'éventuels ajustements. Ainsi, j'ai le meilleur des deux monde. Je l'avais d'ailleurs déjà évoqué sur LinuxFR.

Et apparemment, ça existe des logiciels WYSIWYG, ou du moins WYSIWYM, qui font du LaTeX…

Pour nous émanciper des géants du numérique : Zelbinium !

Ah ben, ça n'a pas été long. L'encart a disparu, sans que cela m'ai été notifié.

Ceci dit, ce n'est pas encore fini, la contestation étant marquée en cours d'examen.

D’après ce que j'ai compris, YouTube/Google n'intervient pas lors d'une contestation : elle est simplement envoyée au titulaire putatif des droits d'auteur, à charge pour lui de renoncer ou non à ses revendications, à sa discrétion…

Je vais surveiller ça pour voir comment cela évolue…

Pour nous émanciper des géants du numérique : Zelbinium !

Voici un extrait de ce qui est marqué dans la section relative aux droits d'auteur de la vidéo concernée :

Même si vous ne participez pas au Programme Partenaire YouTube, des annonces peuvent être diffusées sur votre vidéo. Les revenus générés par ces annonces servent à payer les artistes et les titulaires des droits d'auteurs qui vous autorisent à utiliser leur contenu.

Ce n'est pas explicitement indiqué, mais je suppose, vu le texte, que l'auteur m'autorise à utiliser le contenu qui lui a été faussement attribué.

Donc, je dirais que la réponse est oui.

Par curiosité, j'ai lancé une procédure de contestation, avec pour motif que l'œuvre est dans le domaine public et que j'en suis l'interprète ; je devrais recevoir une réponse sous 30 jours, d’après les indications…

Pour nous émanciper des géants du numérique : Zelbinium !

Il y a quelques temps, j'ai publié sur YouTube (et également sur PeerTube, mais ce n'est pas le sujet) une vidéo avec, comme accompagnement sonore, une œuvre du domaine public interprétée par mes soins, cela pour éviter tout problème de droit d'auteur.

En bas de la description de cette vidéo trône, depuis pas mal de temps, un encart, intitulé Musique utilisée dans cette vidéo, qui référence un album contenant une interprétation de la même œuvre. Déjà, l'intitulé est trompeur, car il suggère que l'accompagnement musical de cette vidéo est issu de cet album, alors que c'est mon interprétation de cette œuvre qui est utilisée. Et l'auteur de cet album n'est pas le compositeur de l'œuvre, sinon l'intitulé aurait pu se comprendre.

Ce n'est pas de la publicité intégré à la vidéo, comme celle qui fait l'objet du lien ci-dessus, mais cela reste de la publicité, pour laquelle je ne touche bien évidemment aucune rémunération…

Sans compter mes démêlés avec le Content ID, que j'ai relaté dans ces commentaires.

Pour nous émanciper des géants du numérique : Zelbinium !

On peut penser qu'il n'y a pas de différences, à l'usage, entre Visual Studio Code et VSCodium, et que passer de l'un à l'autre ne pose aucun problème. Or, ce n'est pas tout à fait exact, car VSCodium n'utilise pas le même dépôt pour les extensions que Visual Studio Code, et certaines extensions sont absentes de ce dépôt. On peut, certes, corriger cela en modifiant un fichier de VSCodium, mais, même dans ce cas-là, certaines extensions ne fonctionneront pas. Là aussi, il y a moyen de remédier à cela. Cependant, la légalité de ces deux contournements est sujette à caution :
https://github.com/VSCodium/vscodium/blob/master/DOCS.md#extensions-marketplace.

Pour nous émanciper des géants du numérique : Zelbinium !

C'est vrai que XUL complétait parfaitement HTML4 (ou plus exactement XHTML), lui apportant les composants graphiques permettant à l'utilisateur d'interagir efficacement avec l'application. On basculait facilement de l'un à l'autre avec les espaces de noms XML, et on pouvait utiliser les CSS sur du XUL.

XULRunner était quand même pas mal utilisé à l'époque. Je me rappelle notamment que l'application TomTom Home, une application Windows qui permettait de mettre à jour les GPS de la même marque, était basée sur XULRunner.

Moi-même je l'ai utilisé, quoique de manière atypique (utilisation de C++ à la place de JavaScript). Je m"étais même fendu d'un journal à l'époque : https://linuxfr.org/users/epeios/journaux/xulrunner-et-c (désolé, mais le blog n'existe plus).

J'étais bien embêté quand ils l'ont arrêté. Je me suis rabattu sur HTML5 dés que ce dernier a été standardisé, avec CEF pour commencer, puis avec Electron, mais toujours en C++ (on ne se refait pas…).

S'il refaisait l'équivalent de XULRunner avec le Firefox d'aujourd'hui, je pense que je laisserais tenter…

Pour nous émanciper des géants du numérique : Zelbinium !

On peut trouver des membres d'ARN ce soir (comme chaque vendredi) au siège de l'association GEM Aube (97 Avenue de Colmar, 67000 Strasbourg) à partir de 19h (vaut mieux plutôt y aller vers 19h30). Je ne sais pas si ce sera le cas ce soir, mais il y a parfois également le responsable de ReflexLibre.
Officiellement, c'est la Stammtish de la Hackstub, mais comme pas mal de membres de la Hackstub sont également membres d'ARN…
Seule contrainte : venir avec un masque, pandémie oblige…

Pour nous émanciper des géants du numérique : Zelbinium !