Suggestions pour un futur OS

[Levak]

librairie

Ça me surprend, venant de toi.

[mdr1]

J'ai fait une faute ? Ou tu préfères que je dise "bibliothèque" ?

(PS : go chat, j'ai des questions à te poser)

[Levak]

J'ai fait une faute ? Ou tu préfères que je dise "bibliothèque" ?

(PS : go chat, j'ai des questions à te poser)

Oui :

http://fr.wiktionary.org/wiki/librairie

4. (Programmation informatique) (Anglicisme) Bibliothèque de sous-programmes.
Ce logiciel utilise une librairie OpenGL pour l'affichage.

vs

http://fr.wiktionary.org/wiki/biblioth%C3%A8que

7. (Programmation informatique) Ensemble homogène de sous-programmes utilisés sur un système informatique.

[Adriweb]

J'ai des suggestions à ajouter, concernant le Lua, dites-moi ce que vous en pensez :

• Ajout de la capture de ":=", "->", "Ans", "{}"et "[]" via on.charIn.
• Ajout d'un évènement on.ctrlEnterKey.
• Idem pour tout ce qui est CTRL + A,B,F,G etc.
• Pouvoir faire des menus sans limite de taille et de nombre d'étages.
• Pouvoir afficher une boîte de dialogue habituelle de l'OS, au moins pour l'aide.
• Ajout de la librairie debug ; mais elle n'est probablement pas présente en raison du fait que debug.setmetatable peut alors modifier une métatable même protégée.

J'améliore un peu pour généraliser la demande :

• Avoir un on.charIn plus 'global' (détection en plus d'autres touches/symboles qu'actuellement)
• ^ et/ou au moins : qu'il y ait un 2ème argument passé à on.charIn indiquant les modifiers (par exemple, par masques sur 2 bits représentant l'état de [ctrl] et [shift])
• Amélioration de la toolpalette pour permettre des sous-menus sans limite arbitraire, ainsi que la possbilité de mettre des icons pour chaque item.
• Pouvoir invoquer des éléments natifs du GUI de l'OS (dialog, textbox, etc;)
• Accès à io.* et debug.* (ou même une sous-partie si nécessaire par raison de sécurité...)

[Levak]

Shift est déjà pris en compte par on.charIn.
Je sais, c'est atroce et dépend que des touches alphabétiques, mais quand même

[mdr1]

• Avoir un on.charIn plus 'global' (détection en plus d'autres touches/symboles qu'actuellement)
• ^ et/ou au moins : qu'il y ait un 2ème argument passé à on.charIn indiquant les modifiers (par exemple, par masques sur 2 bits représentant l'état de [ctrl] et [shift])

Perso, ça ne me dérangerait pas, mais je ne pense pas que ce que tu proposes là soit cohérent avec la façon de TI de faire gérer au Lua la pression des touches. En fait, on ne peut pas du tout détecter la pression de touches (sauf quelques unes dont tab, enter, touche directionnelles...) ; on ne peut pas voir le moyen, mais simplement le résultat de la pression de touches. Par exemple, un "pi" pourra être entré directement sur un clickpad, avec le menu sur une touchpad, dans le catalogue dans les deux cas etc.

Les autres points me semblent en revanche bien généralisés.

[Adriweb]

Je suis bien d'accord, mais il leur "suffirait" de créer une autre fonction/événement du genre on.rawInput(key, modifiers)...
Enfin bref, quand on veut, on peut

[mdr1]

C'est sûr. ^^
Mais je crois que le but de TI est de maximiser la compatibilité en éloignant le programme de la façon dont le caractère a été généré. Les touches diffèrent selon les modèles, et diffèrent avec l'ordinateur.

[Adriweb]

Bien sûr.
Mais certains APIs spécifiques aux plateformes sont présentes, donc ca en ferait une de plus (pour la plateforme majeure, qui plus est).

[mdr1]

Mais quel serait l'intérêt d'avoir une cause d'incompatibilité supplémentaire ? On pourrait certes ajouter certaines combinaisons de touches non exploitées par l'OS, mais il suffirait que TI ajoute ces combinaisons là.