Laurent J a écrit 2933 commentaires

Plusieurs raisons pour une fonctionnalité désactivée par une pref :

1) elle est en cours de dev, elle est à tester, des bugs subsistent ou l’implémentation n'est pas complète
2) spécification W3C encore instable et/ou des points de la spec ne sont pas clairs
3) feature non standard, réservée à certaines plateformes (c'est le cas par exemple pour l'API TCP socket, activée seulement dans Firefox OS pour les applis privilegiées). Ils attendent qu'une spécification émerge et devienne stable avant de laisser tout le monde l'utiliser. Ceci pour éviter au final qu'il y ait des trucs en -moz-* (css) ou moz* (js) qui trainent dans le code des sites web (et qui sont cassés par la suite parce que plus implémenté ou comportement changé). C'est une nouvelle politique de publication des nouvelles fonctionnalités.

Non il a raison. C'est implémenté depuis Firefox 25. C'est juste que pour le moment, c'est désactivé dans les releases officielles via une pref media.mediasource.enabled.

Mais le truc c'est qu'il travaille tous le temps avec des builds non stable. Dans lesquels c'est activé) :-p. Il a juste pas remarqué (ou oublié) que c'était pas dans la stable ;-)

Et oh, miracle, quand on met cette pref à true, youtube est beaucoup plus content :-p

Déjà, ne pas pas confondre Hello (nom de code "loop", utile pour s'y retrouver dans about:config ;-), et WebRTC.

WebRtc est une technologie web : n'importe qui peut faire son propre serveur webrtc, et donc son propre service. Pas besoin de Hello pour ça. rechercher sur google les quelques libs Webrtc opensource qui facilite le développement de son "site webrtc".

Hello est service, basé sur webrtc. Mozilla propose donc son propre serveur webrtc. Les sources sont disponibles !. Et tu peux dans les prefs du navigateur indiquer donc ton propre serveur (voir les prefs loop.* dans about:config).

Mais le souci de webrtc (la techno), c'est que tu dois avoir un serveur pour la "découverte" des autres utilisateurs (ensuite la communication se fait directement entre les deux clients, si les proxys/nat le permettent). Ce qui veut dire que si tu as ton propre serveur pour Hello, tu seras bien seul (ou alors contacter tout tes amis pour qu'ils configurent Firefox correctement)… L'alternative est donc d'implémenter son propre service (donc sans Hello) : une page web quelque part + un serveur pour la gestion des users, et c'est parti. C'est comme ça que font beaucoup de provider. comme http://Talky.io (basé sur des libs opensource d'ailleurs).

Ce qui serait bien, c'est que les serveurs d'annuaires puissent communiquer entre eux, pour que si tu contacts l'un deux, il puisse te mettre en relation avec un utilisateur qui est enregistré sur un autre serveur. Bref un truc à la SMTP/XMPP, coté serveur. (mais c'est hors scope webrtc).

7% d'écart, c'est pas la mort…
Euh… Quand même, si! Surtout pour un navigateur qui se veut OS, vaut mieux supporter plus que l'autre même, en avance, car FFOS (par exemple) n'a pas d'autres API.

C'est pas fini cette mauvaise foi ? Sans dec !

Tu as regardé ce qui manquait ? La plupart des trucs, ce sont des choses rarement utilisée, et sur lesquels les autres navigateurs sont aussi à la traine (IE pour pas le cité). Le seul truc qui coince il est vrai pour des développements "classiques", ce sont quelques fonctionnalités sur les formulaires, mais franchement rien de très méchant.

Et html5test est TRÈS loin d'être exhaustif. Il manque les dizaines de webapi implémentées dans Firefox mais pas dans Chrome.

Le support de Javascript ES6 est meilleur dans Firefox que dans Chrome (et encore bien meilleur si on tient compte des trucs ES6 supportés par Firefox depuis des années mais qui manquent des petites adaptations pour être conforme aux dernières évolutions de la norme). Et aux dernières nouvelles le moteur JS de Firefox est le plus rapide à la plupart des tests.

Bref, Gecko n'est pas un "vieux" moteur.

tu veux tester une fonctionnalité hype? faut aller sur Chrome

Ah ? Je veux utiliser par exemple les proxy en JS (très utile pour mocker des objets, pour implémenter des itérateurs spécifiques etc). Non, je ne vais pas sur Chrome. mais sur Firefox.

je veux faire du MathML (ouai ok, c'est pas super hype), je vais sur Firefox, pas sur Chrome.

je veux utiliser les API (ambiant light, proximity etc) qui me permettent de modifier le comportement de mon appli pour qu'elle soit moins gourmandes en énergie quand il le faut ? J'utilise Firefox, pas Chrome.

Je veux communiquer au niveau TCP socket, pour utiliser des protocoles autres que HTTP ? Je vais sur Firefox(OS), pas Chrome. Même si cette API n'est pas standardisée, cela montre tout de même (ainsi que plein d'autres API) une avance non négligeable de Firefox sur certains domaines.

Les web apps ça a déjà pas marché avec…

Et bien sûr, ce n'est absolument pas parce que les techno web de l'époque n'étaient pas aussi mature qu'aujourd'hui.

Sérieux. Comparons ce qui est comparable.

Tu compares des fabricants de mobiles avec un éditeur d'un OS. Tu compares des solutions propriétaires pour la plupart, avec une solution Open-Source.

Quand ce n'est qu'un fabricant de mobile qui pousse une techno (propriétaire), oui, il y a beaucoup de chance que ça plante.

Quand ils sont plusieurs à pousser un même OS libre sur leur matos, tout de suite, ça va beaucoup mieux. La preuve avec Android.

On mettra Apple à part, car ils ont su innover au niveau ergonomie. Et si ils ont abandonné les web-apps, c'est plutôt parce que ça les empêchait de contrôler ce que l'utilisateur pouvait installer, et donc monnayer l'installation des applis.

et aujourd'hui ça ne marche toujours pas avec FirefoxOS. Quelle surprise.

Je ne comprends pas cette réaction que je vois dans bon nombre de commentaires. Le truc est à peine sorti, n'a pas eu le temps de faire ses preuves, que tout de suite, il y en a pour conclure "ça ne fonctionne pas".

J'aimerais bien savoir sur quoi repose ces conclusions.

Apparemment vous vous fiez tous au contenu du MarketPlace. C'est, selon moi, un très mauvais indicateur.

En effet, les premiers téléphones Firefox OS vendu au grand public au monde, ne l'ont été qu'il y a tous juste un an et deux mois au Brésil. UN AN. Assez rapidement, il l'a été aussi dans quelques autres pays d'amérique latine, et d'europe de l'est. Et il n'est arrivé en France qu'en septembre dernier, et encore, il n'est pas vendu par des opérateurs (donc des ventes qui restent confidentielles).

Comment pouvez-vous donc dire que "ça ne marche pas" ?

Oui, les développeurs ne sont pas précipités pour développer des applis pour Firefox OS, parce que déjà le marché est limité (pays émergeants au niveau smartphone), et de plus, pas forcément pour les marchés qu'ils visent. Les développeurs sont surtout embauchés par des boites qui ont l’Europe et l’Amérique du nord comme cibles, non ? En tout cas, la connaissance que vous semblez avoir du marché, c'est celui que vous connaissez (et encore), c'est à dire celui de l'Europe.

Et puis si il y a peu de développeurs, c'est probablement aussi qu'ils ne sont pas au courant aussi tout simplement. Mozilla n'a pas la force marketing que peut avoir Google quand il fait la promotion de son Android.

Bref, peu de développeurs, donc peu d'applis.

Pour le moment. Ce n'est que le début. Des dizaines d'opérateurs et constructeurs ont annoncé sortir des devices sous Firefox OS (voir toutes les news sur le blog mozilla) : téléphones, tablettes, tv connectés etc..

Avant d'annoncer une mort qui n'a pas lieu, je pense qu'il serait bien de patienter que le produit devienne mature et soit vendu dans une majorité de pays, en particulier en europe et amérique du nord.

L'app store d'Android et d'Apple ne se sont pas rempli en 2 jours… Android n'a pas "explosé" ses ventes les premières années..

Tout dépend comment l'appli est packagée par son développeur. Ses fichiers ne sont pas "retéléchargés par la suite" seulement si elle a été distribué dans un zip.

Le manifest de l'appli peut indiquer un simple lien vers l'appli hébergée sur un serveur web, au lieu d'un lien vers un zip. Donc il te faudra avoir une connexion internet pour l'utiliser. À moins que l'appli utilise toutes les fonctions appcache/offline de HTML5. Dans ce cas il te faudra une connexion internet seulement au premier lancement.

Il y a une différence fondamentale entre Camino (le navigateur sur MacOS dont tu parles), et Firefox/Thunderbird.

Pour le premier, l'interface utilisateur était réalisée nativement avec Cocoa. Gecko n'était utilisé que pour les pages web.

Dans Firefox et Thunderbird, l'interface utilisateur est réalisé en XUL (un dialect XML) + CSS + Javascript, et est donc affiché par Gecko. Gtk2 (ou gtk3 ou qt3) ne servent donc qu'à instancier des fenêtres (vides, puisque le contenu est pris en charge par Gecko avec XUL), à récupérer des infos graphiques comme les couleurs par défaut des widgets graphiques (pour une meilleur intégration visuelle via CSS), à dialoguer avec l'environnement graphique, comme par exemple à avoir des boites de dialogue pour ouvrir/enregistrer des fichiers, gestion presse-papier etc. Bref, la partie graphique de ces toolkits est peu utilisée en fin de compte. Contrairement à Camino.

je dirais plutôt un inconvénient selon moi, surtout si il y a plusieurs utilisateurs.

un wiki, c'est censé être modifié très souvent, le contenu bouge etc. Cela veut aussi dire qu'une modification dans une page = un commit (que ce soit dans un dépôt git ou un autre système d'archivage).

Résultat(1) : on se retrouve avec des centaines de commits (dont beaucoup ce sont des petites corrections d'orthographes ou autres). Et bien souvent, les utilisateurs ne mettent pas de "message de commit" (y compris moi, par flemme), donc on se retrouve avec des commits ayant le même intitulé par défaut.

Si le contenu du wiki est dans le même dépôt que le code source, on se retrouve alors avec un historique complètement illisible. Ce qui annihile tout intérêt de versionner le code source.

La documentation dans le même dépôt que le code source, pourquoi pas (je le fais bien pour slimerjs), mais faut pas que ce soit un wiki (c'est à dire, modifiable par une interface web). Et faut que ce soit une doc qui évolue en même temps que le code, donc très proche du code. Par exemple, une doc de référence (api etc) ok. Pour des tutoriaux ou manuels : je préfère un dépôt à part, car au final ils ont leur vie propre, et n'ont pas le même rythme de vie (par exemple, pour la documentation d'une lib, on va écrire les tutoriaux qu'une fois que l'api est relativement stable, et pas au fur et à mesure, sinon on risque de réécrire des parties du tuto 50 fois -> perte de temps).

(1) ceci est une constatation que je fais à partir de wikis que je possède ou possédait, ouvert à plusieurs personnes.

En ce qui me concerne, j'ai adopté Gitlab parce que c'est ce que j'ai trouvé de plus complet avec une interface et des fonctionnalités modernes.

Je l'utilise pour les projets de mes clients et les projets internes. J'ai aussi installé gitlab-ci pour lancer des tests auto et déploiement automatique. (Je n'utilise pas Jenkins car je trouve que c'est une horreur sans nom au niveau interface, d'un autre temps, et super lourdingue à l’exécution, et si tu veux faire un truc pas supporté par un plugin, c'est la méga galère à configurer).

Par contre pour les projets open-source, j'utilise Github. C'est plus facile pour les contributeurs, et je n'ai pas envie de mélanger projets privés/projets publics. Pour le déploiement continue de mes projets open-source (packages, site web etc), j'ai installé Strider-cd sur mon serveur.

Et pourquoi pas un port en GTK3 ?

Ce n'est pas du ressort de Thunderbird, mais de la plateforme sur laquelle il repose : Gecko. Et c'est en cours.

En ce qui concerne Qt, pareil, c'est du ressort de Gecko. Il existe un port Qt de Gecko, mais je ne sais pas si il est vraiment maintenu.

Pareil, j'aimerai bien comprendre en quoi le support openVZ pose problème avec le noyau 3.x de Linux dans Proxmox ? Je commence à en avoir marre de garder un vieux noyau 2.x. Ça devient handicapant : on ne peut pas utiliser certaines technos récentes comme Docker.

OK ton argument du coup c'est de mettre un couteau sous la gorge à tout le monde ?

pas compris le rapport avec ma question, et d'ailleurs tu n'y a pas répondu. Donc je repose la question : Comment Mozilla pourrait gagner l'argent nécessaire à ses activités, tout en devenant une fondation "pure" au niveau de l'esprit du libre ?

Ma question est sérieuse !

(c'est quand même bizarre, à chaque fois que je pose cette question, je n'ai jamais de réponse censée).

Ça se voit que tu dis ça sans rien connaître

Ah mince. Tu veux dire que le gars avec qui j'ai travaillé dans le même bureau pendant 4 ans m'a menti et n'est pas co-chairman du groupe CSS au W3C et que donc tout ce que je sais du W3C est erroné ??

Alors oui il y a des personnes "indépendantes" (comme Fantasai au groupe CSS) qui sont des "invités expert", qui participent donc activement au développement des standards. Oui j'ai un peu forcé le trait dans ce dialogue qui est fictif comme je l'ai indiqué. Mais globalement c'est ce qui se passe au final. Si un "implémenteur" ne veut pas implémenter une propriété CSS par exemple, pour de multiples raisons ("ça ne sert à rien pour nous", "c'est mal spécifié", "c'est trop compliqué") il ne le fait pas, le fait savoir. C'est déjà arrivé (même chez Mozilla, comme par exemple les fontes SVG), et ça arrivera encore.

Et si cet "implémenteur" représentait 80% du marché (qui est une statistique complètement fictive pour le moment, je rappelle), et bien la majorité des développeurs web n'utiliseront pas cette propriété.

Bref, au final, si il y a un acteur au W3C qui a le monopole sur le web, qu'il y ait des experts indépendants ou pas dans les groupes des travails ne changera rien : il fait ce qu'il veut sur le web.

C'est pour cela qu'il est important qu'il y ait plusieurs moteurs de rendus pour le web, qu'il y ait plusieurs navigateurs, et donc que Mozilla doit exister, et qu'il faut que Mozilla ait une part de marché non négligeable (sans pour autant avoir le monopole, ce n'est pas l'objectif de Mozilla d'ailleurs).

Je sais que certaines contributions proviennent de Mozilla, mais de la à arguer que c'est dû à son nombre d'utilisateurs… ça me paraît un peu douteux.

Ah ? si Mozilla représentait seulement 1% des utilisateurs, tu crois que ses représentants au W3C aurait autant de poids, autant de crédibilité dans les débats dans les groupes de travail ?

Discussion fictive:

Mozilla (1% de pdm): "mes utilisateurs/développeurs trouvent qu'il serait bien d'avoir telle propriété CSS/HTML parce que ceci cela…"

Google (80% de pdm): "(LOL) Je n'ai pas eu de retour sur ce type de problématique, je ne pense pas que ce soit intéressant pour mes utilisateurs. De toute façon, j'en ai pas besoin dans Gmail/Google+/GTruc, donc je ne l'implémenterai pas. je préfère qu'on passe du temps à discuter sur cette propriété trucmuche (dont j'ai absolument besoin pour gmail), ça me semble plus important pour l'avenir de Google^W du Web."

beaucoup de projets libres sont fait par des bénévoles, et également des entreprises, qui se financent autrement qu'en vendant leurs utilisateurs.

Des exemples ? (à gros budgets si possible).

J'aurais préféré un autre compromis.

Ah ! Je suis très intéressé (et Mozilla aussi) ! Vas-y, on t'écoute !

Attention, ne nous sort pas des solutions qui ne permettent pas d'embaucher à temps plein les quelques centaines de développeurs qui bossent sur Firefox, FirefoxOS, MarketPlace, Firefox Sync, Firefox Android, DevTools, et les dizaines d'autres projets R&D (ou pas), comme les problèmes de Privacy, les formats libres (audio, video…), les problèmatiques de certificats TLS gratuit etc…

Si ils avaient moins de revenus, Mozilla pourrait certes couper dans tous ces budgets R&D, mais cela voudrait dire qu'il serait plus compliqué de se maintenir au rythme de la concurrence (Google Chrome etc…)… Et puis avec moins de budget, donc moins de projets et de participation au développement des technos du web (W3C et cie), du coup, Mozilla deviendrait un acteur mineur. Le logiciel libre en prendrait un coup je pense (dans le domaine des navigateurs).

En pratique, je trouve que les certificats auto-signés sont plus fiables et plus sécurisés. On risque une man in the middle a la première connexion, mais après, on est vraiment sûr de notre interlocuteur.

Oui et non. Si le certificat change, ton navigateur râle de nouveau. Mais tu ne sais pas si c'est à cause d'un MITM, d'un proxy pourri ou si c'est parce que le propriétaire a vraiment changé son certificat.

je risque a tout moment un man in the middle par quelqu'un qui a mis l'autorité de certification dans sa poche

Tout comme pour un certificat auto-signé.

ajout d'une table des matières pour les articles longs ;

Ça c'est juste une histoire de présentation, pas de syntaxe (puisqu'il suffit de répertorier tous les titres). Donc au final pas de rapport avec Markdown :-)

Projet super cool, je plussoi !

Mais… c'est quoi la charge ? même pas un petit robot , un personnage lego, une bière, une navette lego, ou encore une chaise ?

les traditions se perdent, je vous jure.. :-)

Non mais sérieux, arrêtez vous tous avec vos "github ça pue c'est proprio". Vous êtes totalement ridicule et montrez votre incompétence manifeste sur le développement d'un service comme Github.

Github, et toute appli qui est utilisée par des milliers d'utilisateurs simultanément, ce n'est pas quelques dizaines de fichiers de code source en [ici ton langage preféré] qu'il est possible magiquement de libérer sous licence libre.

Le "site" github n'est qu'une facade, la partie visible de l'iceberg et franchement libérer son code source ne servirait à personne, principalement parce l'appli est fortement liée à une multitude de services et outils sous-jacent, taillés, configurés, organisés, architecturés, pour supporter chaque jour des millions de requêtes http, des milliers d’exécutions de jobs en tout genre etc…

Vous voulez que Github libère le code source ? Ok, vous allez vous retrouver avec des centaines de pages de doc pour installer l'infra nécessaire pour faire fonctionner le site github, des dizaines de source de jobs dont vous ne saurez que faire parce que trop spécifique à l'infrastructure déployée par les gens de github. Et puis au final, vous allez vous rendre compte que, comme beaucoup de société comme Github, ils utilisent beaucoup d'outils existants (au hasard, Redis), et ont déjà libéré depuis longtemps des composants/outils (ex: leur système wiki, Resque et j'en passe). En notant que ce qu'ils ont libéré, ce sont des choses qui sont réutilisables ailleurs.

Libérer par exemple le site github serait comme libérer le tableau de bord d'une centrale nucléaire. ça ne servirait à rien, puisque tu n'aurais pas le reste de la central nucléaire (c'est à dire, dans le cas de github, toute l'infra serveur et réseau de github). Et que bien sûr, ton tableau de bord, étant spécifique à une installation de central nucléaire, tu ne peux l'utiliser pour autre chose.

Pour résumer : non, Github ce n'est pas UN logiciel comme gitorious ou gitlab. c'est un service d'une part, et d'autre part (et avant tout), c'est une infrastructure complexe, composé d'une multitude d'outils et composants, capable de supporter un trafic réseau très lourd, et capable de traiter un volume de données hallucinant. Une infra, ça ne peut pas se libérer.

Bref, Github, c'est déjà pas mal libre, et c'est déjà bien suffisant, car le reste n'aurait strictement aucun intérêt pour personne. Pour preuve, Gitlab au début, était basé sur la plupart des composants libérés par Github, ils n'ont eu qu'à développer l'interface HTML. Jusqu'à ce qu'ils se rendent compte que ces composants n'étaient pas forcément adaptés à ce qu'ils voulaient faire, parce que leur objectif n'est pas de fournir une plateforme de dev collaborative pour des centaines de milliers d'utilisateurs, mais pour des installations plus modestes et qui soient plus simples à installer/à administrer. Et ils ont fini par remplacer des composants de github par des trucs plus adaptés…

Personnellement j'appelle ça un avantage.

Largement insuffisant. Tu oublies l'aspect technique : sécurisation des serveurs, des clés privées etc… Et là bizarrement, personne ne fait confiance à CACert parce qu'ils reconnaissent eux-même qu'ils ne peuvent satisfaire toutes les exigences en matières de sécu que demandent Mozilla, Debian etc… Ce sont les fenêtres ouvertes dont parle Zenitram plus haut.

et j'aimerais bien aussi que le choix par défaut soit « cette session uniquement ».

Ce qui est complètement con. Parce que tu ne sauras pas la prochaine fois si le certificat que tu as accepté la première fois est toujours le même, et donc si tu es potentiellement victime ou pas d'un MITM.

Tu n'es pas non plus obligé de mettre à jour ton compilateur toutes les six semaines..

Oh, du (presque) RPL (à l'envers) :-)

Les étudiants pourraient presque utiliser une calculatrice HP pour programmer :-)

Pour moi c'est le même niveau de difficulté sur cet exemple.

Non, pour moi l'exemple que tu donnes est plus compliqué, car l'écriture de l'expression mathématique n'est pas "naturelle". Sauf si l'environnement de calcul (la "ligne de commande" de la calculatrice) est une ligne de commande python.

Je m'explique : le gros avantage des langages que j'ai présenté, c'est que la manière d'écrire les formules dans les programmes, c'est exactement pareil que lorsque l'on tape la formule hors programme. Avec la 8500G, dans sa "ligne de commande", pour calculer 2x√3x284², je tape 2x√3x284². (il y a les touches √, x, ²). C'est assez naturel (pas autant qu'un vrai éditeur d'équation qui permet de taper une équation comme sur le papier, il est vrai). Et dans un programme, je tape exactement la même chose.

Idem avec la HP48 en notation algébrique (en notation RPN, c'est moins naturel, mais une fois maitrisé, on calcul beaucoup plus vite ;-) RPN ROXOR).

Bref, l'utilisateur n'est pas perdu, il rentre doucement dans le monde de la programmation, avec un très faible investissement.

Avec une machine avec un langage uniquement python :

• soit on garde un interpréteur de ligne de commande classique qui comprends directement 2x√3x284² : l'utilisation "normale" de la calculatrice reste simple et classique. Mais dés qu'il faut programmer, il faut vraiment apprendre un nouveau langage, parce que l'écriture des formules n'est pas la même. Il faut donc savoir que pour calculer une racine carré, on ne tape pas √ mais faut appeler une fonction sqrt(). Premier obstacle : apprendre ce qu'est une fonction, des arguments etc (même si ça peut être assez rapide à comprendre pour un mathématicien). Deuxième obstacle, se souvenir des équivalences notation algébrique <-> fonction python. Par exemple : en lisant a**2, je n'aurais pas su que c'était la notation "puissance" si je n'avais pas eu un équivalent sous les yeux. L'éditeur de programme pourrait faciliter les choses (on appuie sur la touche √, et ça insert un sqrt()), mais la lecture des programmes peut rester un peu compliqué et ça peut dérouter l'utilisateur les premiers temps.

Bref, le temps d'apprentissage est plus long, la marche plus haute, pour un non développeur. Et tout utilisateur ne se destine pas à devenir développeur.

• soit l’interpréteur de ligne de commande est un interpréteur python. Donc même syntaxe en ligne de commande et dans les programmes. Mais là, l'écriture des formules devient vite pénible et peu intuitive pour un nouvel utilisateur (c'est très loin d'être "comme sur le papier", comme sur les bouquins de classes).

Bref, pour moi, Python pour remplacer le "basic" des calculatrices n'est pas une bonne solution (ou alors la calculatrice se destine uniquement aux geeks). Par contre, comme "deuxième" langage pour les développements complexes, ça peut être une bonne chose. Ça ouvre la porte à tout type de programmes.

PS: autre argument en défaveur du Python comme langage principal : l'indentation. Pas seulement parce que ça oblige à indenter, mais surtout parce que les écrans de calculatrices sont petits. À mon avis, on se retrouve vite à scroller horizontalement, et là, ça devient très très pénible (pour info, l'écran de la hp48, c'est 13 colonnes avec une fonte normale; on peut avoir une fonte plus petite mais on attend peut-être 20-25 colonnes, ce qui reste insuffisant à mon avis, et ça devient vite fatiguant à lire).
Sur un écran de 15 colonnes, ton programme devient :

a = input("Sai
if a > 0:
  print a * sq
else:
  print "ERREU

ça devient juste illisible (et pourtant la formule est simple). Avec des langages comme ceux que j'ai présenté, n'ayant pas d'indentation à respecter, tout peu passer à la ligne.

<< "Saisissez
A" PROMPT → A
  << IF 'A>0'
  THEN
    '2*√3*A^2'
       →NUM
  ELSE
    "ERREUR"
    0 DISP
    WAIT
   END 
  >>
>>

C'est moi beau que sur un écran 80 colonnes, mais ça reste lisible sur 15 colonnes.