Christian a écrit:Bonjour,
Pas sûr, si on parvient à nommer simplement par programmation la fenêtre dans laquelle on veut travailler, fenêtre d'ailleurs qui peut ne pas avoir été créée quand on lance le programme (ces problèmes ne se posaient pas sur la V200, d'architecture plus simple).
Alors oui, il y a toujours moyen d'améliorer la structure des classeurs, de donner un nom ou un id à chaque onglet+application et enfin d'accéder au contenu graphique via le TI-Basic comme tu le dis. Il y a toujours moyen, et c'est de très loin pas impossible.
Est-ce que cela remettrait en cause profondément la structure de la TI-Nspire? Est-ce qu'il y a une impossibilité majeure, comme tu semble le croire? Faudrait-il créer une fenêtre graphique spécialement dédiée à la programmation? Je ne sais pas, mais il me semble qu'un système digne de ce nom doit permettre une programmation graphique. Il est vrai que cela n'a pas été jusqu'à présent la priorité de TI, mais un jour viendra sans aucun doute.
C'est là que vient le problème, si on compare avec le temps qu'à mis les Request/Text à arriver qui sont pourtant natives et existaient au sein de l'OS bien avant (il suffisait normalement juste de rendre une instruction qui parsait les entrées utilisateur et le tour était joué),on peut se poser des questions sur un projet qui ramené à ce niveau est un véritable brainfuck. Le Lua était vraiment un projet à part, une nouvelle application avec un interface superficielle sur le TI-Basic (instruction math.eval() ). Méchamment je dirais qu'ils ont juste eu à télécharger la surcouche en C de l'interpréteur Lua, coder les fonctions graphiques (qui si ça se trouve utilise les routines de dessin de l'OS), quelques interfaces, et le tour était joué.
Sinon, LUA est une façon de contourner la difficulté, avec je n'en doute pas un certain nombre de lourdeurs.
A ce propos, dès que j'ai un peu de temps, je me plonge dans le site LUA TI-Nspire... J'aurais sûrement à ce moment des questions à poser.
Bien cordialement,
Christian
Comme déjà dit, la seule barrière/lourdeur qu'on peut sentir/percevoir, c'est celle de tout recoder. Même si le calcul formel est accessible via math.eval(), coder des applications mathématiques est et à toujours été, une difficulté énorme, non pas pour la théorie, mais pour les interfaces utilisateur. Un exemple simple : demander une valeur. Il me faut, à moi, pour bien organiser le code et avoir quelque chose d'extensible et de sécurisé et enfin joli, plus de 100 lignes de code. Juste un input. Le code fonctionnel ne fait pas plus de 20 lignes, mais tout ce qui amène ce code au niveau de l'utilisateur pour la personne penchée sur sa calculatrice représente 80% du travail et du code. Il est évident que des programmeurs sont bien plus intéressés par développer des jeux, qui ne nécessite - au mieux - de coder la réaction de 6 touches : droite, gauche, haut, bas, Enter, Esc - contre une bonne partie du clavier + souris si on s'aventure dans la création d'outils mathématiques.
Cependant, l'aventure est gigantesque et utopique quand on découvre ce monde dans son intégralité, les possibilités -presque - infinies à moins de prendre le temps de passer outre les états d'âme précédents.
Personnellement je travaille par classes avec le Lua, ce qui me permet de coder une et une seule fois un module et de l'utiliser dans plusieurs programmes (par copier/collé bien sûr, même si certains workarounds permettent de passer par les bibliothèques, comme montré
ici).
En espérant t'avoir donné encore plus envie d'abandonner le TI-Basic
