Page 1 sur 2
Quelques propositions
Publié : mar. janv. 26, 2010 12:51 pm
par cdeval
Bonjour Bernard,
après les extensions, voici deux idées pour occuper tes voyages en train !
1ère idée :
sauf erreur de ma part, il n'y a rien pour gérer le clavier dans un programme. Or, nous autres profs, on aime bien avoir nos fichiers tout prêt à projeter et n'avoir qu'à appuyer sur telle ou telle touche pour lancer telle ou telle action. Ce sera d'autant plus important si les extensions voient le jour sous xcas : on verra apparaître des "imagiciel" (comme disent les pédagogues) prêts à l'emploi.
2ème idée :
après avoir pas mal travaillé sur xcas et fait beaucoup d'aller retour entre la ligne programme, les figures géométriques, les lignes d'expressions, je peux dire que l'interface telle qu'elle existe ne m'est pas très agréable à l'usage et exploite mal les grands écrans que nous avons aujourd'hui.
Voilà ce que je verrais bien :
- ajouter un menu "Cfg->mode (écran)" juste en dessous de "mode (syntax)"
ce menu comporterait deux sous menus :
1) mode ligne :
c'est celui qui existe actuellement, utile pour les petits écrans, type netbook par exemple
2) mode fenêtré :
à l'ouverture de Xcas, plein écran sur les expressions, comme maintenant.
ensuite : à chaque fois qu'on veut une ligne d'un autre type (tous les Alt-P, Alt-G etc...) la fenêtre de xcas se sépare et dédie une fenêtre pour l'édition des programmes, pour la géométrie, etc... un peu comme DispG mais à l'intérieur de la fenêtre Xcas. (D'ailleurs DispG devrait recevoir à mon avis toutes les sorties graphiques, j'aime pas trop le graphique qui arrive sous la ligne de commande mais ça a l'avantage de garder l'historique. Bon finalement c'est pas si mal !).
Ainsi, plus besoin de jouer de l'ascenseur à chaque modification de programme, d'objets géométrique, etc...
on garde en permanence la fenêtre des expressions, ce qui permet de tester en parallèle ce qu'on vient de compiler sans le perdre des yeux. Ça m'avait pas mal gêné tous ces allers retours programmes/graphique/expressions quand j'avais fabriqué mes programmes sur les courbes de Bézier/Bspline.
Voilà,
A+
Re: Quelques propositions
Publié : mar. janv. 26, 2010 2:07 pm
par parisse
Pour le partage de l'ecran, je m'arrange pour que le programme et la ligne de commande servant a le tester et la ligne suivante soient tous les 3 visibles a l'ecran. Il est alors possible de modifier le source, recompiler et tester uniquement au clavier et sans faire defiler quoi que ce soit (avec F9 pour compiler, entree pour executer la ligne de commande et pageup 2 fois pour remonter vers le source et le modifier). Si on ouvre le programme dans une autre fenetre ca necessite de changer le focus, et Alt-Fn-Tab c'est plus penible a chercher que les touches ci-dessus (mais plus systematique je te l'accorde). Ce que je pourrais peut-etre faire, c'est quand on selectionne Nouveau programme ca ouvre une boite de dialogue qui demande le nom de la fonction et ses arguments et creerait a la fois l'editeur de programmes, la ligne de commande avec l'appel au programme, la ligne suivante, le tout tenant dans la fenetre xcas.
Sinon, pour l'imagiciel, tu penses a quoi en termes de touches, une sorte d'enregistreur de keystrokes qui puisse les executer par appui sur une seule touche?
Re: Quelques propositions
Publié : mar. janv. 26, 2010 7:57 pm
par cdeval
parisse a écrit :Pour le partage de l'ecran, je m'arrange pour que le programme et la ligne de commande servant a le tester et la ligne suivante soient tous les 3 visibles a l'ecran. Il est alors possible de modifier le source, recompiler et tester uniquement au clavier et sans faire defiler quoi que ce soit (avec F9 pour compiler, entree pour executer la ligne de commande et pageup 2 fois pour remonter vers le source et le modifier). Si on ouvre le programme dans une autre fenetre ca necessite de changer le focus, et Alt-Fn-Tab c'est plus penible a chercher que les touches ci-dessus (mais plus systematique je te l'accorde).
exact, j'utilisais aussi le clavier pour me déplacer mais j'avais beaucoup de fonctions dans une même ligne de programme, d'où le scroll nécessaire. J'aurais pu scinder...
parisse a écrit : Ce que je pourrais peut-etre faire, c'est quand on selectionne Nouveau programme ca ouvre une boite de dialogue qui demande le nom de la fonction et ses arguments et creerait a la fois l'editeur de programmes, la ligne de commande avec l'appel au programme, la ligne suivante, le tout tenant dans la fenetre xcas.
pourquoi pas, mais je ne sais pas si j'aurais l'utilité de cette fonctionnalité. Quand je commence à taper un programme, je modifie parfois le nombre d'arguments en cours de conception. Dans ce cas, il faudrait retoucher après coup ; pas pratique.
Par contre l'idée d'un assistant de création de squelette de fonction peut-être intéressant pour les débutants.
parisse a écrit :Sinon, pour l'imagiciel, tu penses a quoi en termes de touches, une sorte d'enregistreur de keystrokes qui puisse les executer par appui sur une seule touche?
non, des instructions de gestion de touche par programme, du genre :
Code : Tout sélectionner
a=key_pressed();
if(a=="A"){ appeler la fonctionA()}
if(a=="B"){ appeler la fonctionB()}
if(a=="Q"){ fin du programme}
Re: Quelques propositions
Publié : mer. janv. 27, 2010 8:10 am
par parisse
Sinon, pour l'editeur de programmes separe, il y a toujours la possibilite d'utiliser un editeur tiers, par exemple emacs, nedit ou notepad, de sauver dans l'editeur et de faire read("nom_fichier") dans Xcas.
Pour la touche j'avais mal compris, en fait c'est getKey() qui devrait faire ca, mais ca n'a pas l'air de fonctionner correctement, je vais regarder ca de plus pres.
Re: Quelques propositions
Publié : mer. janv. 27, 2010 9:19 am
par parisse
Bon, changer getKey() s'avere trop difficile, je fais juste une modif pour pouvoir tester si la touche est la cause du dernier evenement. Il faut retenir que getKey renvoie le dernier code caractere tape (et ca n'attend donc pas qu'une nouvelle touche soit tapee, de plus la touche tapee sera prise en compte ailleurs), il renverra l'oppose du code touche si l'appui sur la touche n'est pas le dernier evenement. Voici un exemple de programme qui affiche les codes tapes et s'arrete lorsqu'on tape sur A
Code : Tout sélectionner
touche():={
local c;
for (;;){
c:=getKey();
if (c>=32 && c<=255)
return c;
}
}:;
f():={
local c,oldc:=-1;
for (;;){
c:=touche();
if (c!=oldc){
oldc:=c;
afficher(c);
if (c==65)
break;
}
}
}:;
Re: Quelques propositions
Publié : mer. janv. 27, 2010 1:30 pm
par cdeval
super, c'est exactement ce qu'il me fallait.
je n'avais pas vu que cette fonction getkey() existait...
Quelques remarques à l'utilisation (mais tu me dis que tu as fait des modifs alors peut-être que ce que j'ai constaté n'a plus lieu d'être) :
1) la répétition d'une même touche n'est pas détectée
2) les chiffres du pavé numérique ne sont pas détectées
3) un caractère obtenu avec shift affichera deux codes ascii : celui du caractère shifté + celui non shifté.
Re: Quelques propositions
Publié : mer. janv. 27, 2010 2:08 pm
par parisse
oui, c'est tres proche de la machine en fait. Je vais encore reflechir a comment rendre getKey plus proche de ce qu'on en attend, alors je te conseille de patienter un peu avant d'ecrire tes scripts...
Re: Quelques propositions
Publié : jeu. janv. 28, 2010 8:56 am
par parisse
Bon, j'ai reussi a faire un getKey plus conforme a ce qu'on en attend. Pour l'instant j'ai compile xcas_root, les autres suivront.
Re: Quelques propositions
Publié : jeu. janv. 28, 2010 1:27 pm
par cdeval
super !
dis moi quand c'est prêt que je teste...
Re: Quelques propositions
Publié : jeu. janv. 28, 2010 1:31 pm
par parisse
les versions linux sont compilees (xcas_root et les package debian). Pour win et mac, peut-etre demain...
Re: Quelques propositions
Publié : jeu. janv. 28, 2010 9:02 pm
par cdeval
J'ai testé : ça marche !
Comme j'ai vu que tu avais mis une petite boite de dialogue, je te propose un raffinement :
getkey(chaine_de_caracteres) afficherait la chaine_de_caracteres dans la boite de dialogue avec gestion des sauts de lignes.
Cela permettrait de servir d'aide mémoire pour l'utilisation du programme, des trucs du genre :
"taper :
+ pour augmenter le pas
- pour le diminuer
0 pour réinitialiser la figure
Q pour quitter"
(je pense à ce que je fais régulièrement avec géoplan)
et puis pourquoi pas getkey() sans argument qui n'afficherait pas la boite (comme avant), ce qui évite le focus qui passe d'un fenêtre à l'autre et qui peut parasiter visuellement une animation...
Autrement, j'ai eu un petit plantage une seule fois avec le "-" du pavé numérique. Obligé de tuer xcas.
A part ça c'est exactement ce qu'il manquait, merci
Re: Quelques propositions
Publié : ven. janv. 29, 2010 8:38 am
par parisse
Alors, je change getKey de la facon suivante:
- getKey(-1) renvoie le code de la derniere touche frappee (ancien comportement de getKey), avec un signe negatif si le dernier evenement n'est pas la touche.
- getKey(arg1,arg2,...,argn) affiche la boite de dialogue avec un output multi-lignes affichant arg1 arg2 etc sur des lignes separees.
Re: Quelques propositions
Publié : ven. janv. 29, 2010 1:25 pm
par cdeval
Ce sera la perfection ! Merci !
Re: Quelques propositions
Publié : ven. janv. 29, 2010 2:35 pm
par parisse
ca devrait etre bon, pour linux, windows et mac.
Re: Quelques propositions
Publié : ven. janv. 29, 2010 11:03 pm
par cdeval
parisse a écrit :ca devrait etre bon, pour linux, windows et mac.
ça marche sur linux64.
J'ai essayé de fabriquer un petit exemple d'application : approximation de pi par le périmètre d'un polygone régulier tracé avec la tortue :
Code : Tout sélectionner
polygone_tortue(n,r):={
// n représente le nombre de cotés du polygone régulier
// r le rayon du cercle circonscrit
local k;
efface;
repete n, avance(2*r*sin(180/n)), tourne_gauche(360/n);
}
:;
approx_pi():={
local n,c,r,p;
n:=5;
r:=100;
for(;;){
c:=getKey("q : stopper le programme","+ : augmente le nombre de côtés de 1","- : diminue le nombre de côtés de 1","* : multiplie le nombre de côtés par 2","/ : divise le nombre de côtés de 2");
// c:=getKey(-1);
switch(c){
case 43:{n++;} // +
case 45:{n--;} // -
case 42:{n:=n*2;} // *
case 47:{n:=floor(n/2);} // /
};
if (c==113) break;
polygone_tortue(n,r);afficher("Polygone à "&n&" côtés, distance à pi="&evalf(pi-n*sin(180/n)));
}
}:;
j'ai eu quelques ennuis à l'usage :
- la fenêtre du getkey n'est pas redimensionnable et je ne vois pas tout mon texte. On peut toutefois scroller en mettant le pointeur dans le texte.
- les changements sur mon polygone ne se font pas à l'affichage jusqu'à ce que je sorte du programme avec la touche q
- si je mets c=getKey(-1) je vois l'occupation mémoire de xcas (à la ligne current cas status) augmenter sans arrêt jusqu'à l'arrêt du programme
Sinon, c'est exactement ce qu'il me fallait.
Bravo