cherche beta testeurs pour shell - Page 3

non il reproche les menu AMS tu peut en etre sur

vu que les menus ams sont moches par nature on peut penser ça kevin en effet

Flanker
: mais si t'aimes pas les icônes, tu peux toujours le mettre en mode liste (qui est beaucoup plus pratique je trouve, surtout pour les handles).

En effet.

Vark :
vu que les menus ams sont moches par nature on peut penser ça kevin en effet

Les menus AMS ne sont pas moches, et puis c'est l'interface prévue par la plateforme.

le prochain qui donne encore un argument de merde je le slappe, vous êtes prévenus

ils sont moches, peut-être, mais ils prennent pas trop de place
Si jamais j'arrive à faire des menus jolis et petits, je les mettrais, mais pour l'instant j'ai d'autres choses à débugguer (ce !$#% de désassembleur kernel, par exemple) avant

ben tu peux faire une interface très simple/belle/peu coûteuse en memoire rien qu'avec des tracé de lignes

C'est moche par rapport aux beaux menus arrondis de AMS.

LOL


allez


!slap Kevin Kofler
• fabetal_ slaps Kevin Kofler around a bit with a large trout !

mdr

>Kevin, comment tu peux dire que c'est moche alors que cttte interface n'existe même pas ?
>Vark Si tu te plains de mes icônes (je dis pas que t'as pas raison), tu devrais t'attendre au pire si je me met à faire des graphismes un peu évolué (un tout petit peu)

hum je te parle pas des icônes moi mais des menus

Et je pense que Kevin parlait lui aussi des menus d'AMS (#67 est pour moi une réponse à #66)...
Menus qu'il va bientôt être possible de faire en statique, tout comme les dialogs, en C, sans resource compiler, grâce à Wazabbe et à l'utilisateur qui prend ici le pseudo "C Bien" (il a vérifié et augmenté le boulot de Wazabbe).

Les menus d'AMS vont très bien. C'est ce qui prend le moins de place, puisque l'utilisateur n'a presque rien à refaire, c'est tout en natif dans le système. Par contre, c'est plus lent qu'un truc tout refait par le programmeur.

plus lent ? pourquoi ? le déplacement dans les menus est assez rapide je trouve, suffit d'avoir un curseur un peu accéléré (j'ai fait exprès de ne pas toucher à la vitesse du curseur pour laisser l'utilisateur choisir, moi je n'aime pas qu'on m'impose une vitesse)

/me dit que de toutes façons, le plus beau menu, c celui de SMA

t fou toi, c'est celui de Backgammon

Pen^2 :
dit que de toutes façons, le plus beau menu, c celui de SMA

Il n'est pas si beau que ça, et il est un des pires menus en ce qui concerne l'utilisabilité (3 lignes à la fois seulement etc.). J'avais écrit plus dans un ancien topic, mais je ne sais pas si je vais le retrouver avec le nouveau moteur de recherche pourri. (C'est bien gentil d'essayer d'éviter de faire planter le serveur MySQL, mais le moteur de recherche actuel est totalement inutilisable. Chercher seulement dans le titre ne sert strictement à rien.)

Vark :
t fou toi, c'est celui de Backgammon

Il n'y a pas de menu dans Backgammon, donc je ne vois pas ce que tu pourrais qualifier de "plus beau".

On l'a déjà dit à yAro ça
Et pour les menus, on en a déjà discuté et si je me rappelle bien, il est ressorti que tes critères de jugement général des menus sont assez minoritaires

moteur>ben moi ce matin g retrouvé mon topic sur le zoom 92 -> 89
mais bon c vrai que c limité.

Kevin Kofler
:

Pen^2 :
dit que de toutes façons, le plus beau menu, c celui de SMA

Il n'est pas si beau que ça, et il est un des pires menus en ce qui concerne l'utilisabilité (3 lignes à la fois seulement etc.). J'avais écrit plus dans un ancien topic, mais je ne sais pas si je vais le retrouver avec le nouveau moteur de recherche pourri.

Voilà, je l'ai retrouvé (sans utiliser le "moteur de recherche", qui ne sert à rien).
topics/22535-projet-rolo-baldurs-gate-like/8#232
topics/22535-projet-rolo-baldurs-gate-like/9#253
topics/22535-projet-rolo-baldurs-gate-like/9#263
Je cite:

Lis un peu les critiques qu'on fait souvent aux interfaces graphiques sous Linux. La plus fréquente est l'inconsistence entre les interfaces utilisateur proposés par différentes applications. La plupart des systèmes d'exploitations (et AMS en fait partie) ont un standard d'interface auquel les applications sont censées se plier. L'absence de ces standards mène à un chaos total, et l'utilisateur ne sait plus du tout quel comportement s'attendre de l'interface.

Personnellement, j'en ai marre de voir:
* des menus où il faut appuyer sur des touches non-standard. J'ai déjà vu de tout pour confirmer une sélection:
- [2nd]
- [DIAMOND]
- [F1]
- [->]
- [ENTER] (et souvent un ENTER bien particulier parmi les 3 de la TI-92+, histoire de perfectionner encore un peu le bazar)
C'est lourd de devoir lire la documentation ou essayer toutes ces touches à chaque fois qu'on veut choisir quelque chose dans un menu!
* des menus où on ne voit à l'écran que 3 des 10 options proposées
* des menus où on ne peut pas du tout distinguer entre les options qui lancent le jeu, les options qui permettent de faire un choix dans un popup (ou plutôt une imitation de popup avec les mêmes problèmes que pour les menus - cf. les 2 critiques précédentes) et les options qui ouvrent une boîte de dialogue (ou là encore une mauvaise imitation). Le standard d'interface de AMS veut que les premiers soient des boutons (Enter=OK) dans un dialogue ou des entrées normales dans un popup et que les deuxièmes soient des dropdowns dans un dialogue ou des sous-menus dans un popup. Quant aux troisièmes, il n'y a pas d'élément d'interface dédié, mais la convention multi-plateforme qui est également suivie par AMS lui-même prévoit l'utilisation d'une entrée de menu normale (sans sous-menu) et l'attachement de points de suspension au nom (par exemple "Options...").
* des programmes qui font 64 KO au lieu de 32 parce qu'ils ont réécrit toute l'interface utilisateurs ...

squale92 a écrit :
certes...
On va dire que Vertyos a pris un mauvais exemple

Regarde un peu les jeux avec des menus personnalisés, et tu verras que mes critiques s'appliquent à pas mal d'entre-eux. Juste à titre d'exemple, SMA est aussi un offenseur sur pas mal de ces points.

squale92
a écrit : les menus de SMA ne m'ont pas paru extrément complexes, les fois où j'ai essayé ce jeu...

Ça ne change rien au fait qu'ils sont en violation de pas mal des critères d'utilisabilité que j'ai évoqués (affichage de 3 options à la fois seulement - je ne sais pas pourquoi toue le monde choisit ce "chiffre magique" 3 qui est totalement inapproprié -, indistinguibilité des différents types d'éléments, touche de confirmation non-standard, ...).

La discussion commence là: topics/22535-projet-rolo-baldurs-gate-like/8#221.

Les menus d'AMS marchent bien, sont standards, inclus dans le système. La place qu'un menu prend est minime par rapport à une interface complète réécrite.
Matthieu n'a pas tort de les utiliser. Ils sont plus lents qu'une interface optimisée, mais c'est un de leurs seuls défauts.

>Xdanger : ils sont plus lents que quand ils sont utilisés. les touches du menu sont traitées en dernier, ça permet de garder une vitesse suffisante. Ce qui ralentit c'est le clavier (et on peut l'accélérer sans problème )
>Vark : je veux bien essayer de faire un joli menu avec juste des lignes, mais faudrait que tu me montres à quoi ressemble un joli menu pour toi
Enfin, CS n'a pas vocation à être un joli shell, juste un truc qui peut servir aux programmeurs (en particulier moi). Si je peux faire qqc de joli en plus, pourquoi pas, mais je ne veux pas que ça prenne trop de place (je vais finir par faire plus de 64ko )

Je ne vois pas en koi faire une interface personnaliser empècherais d'utiliser les menu d'AMS.
C'est surtout la barre de menu qui est pas belle et qui mériterais d'être retouché.
Ensuite, il s'agit de l'interface ente la barre de menu et la barre d'état qui prend le plus de place. Le mode icone n'en necessite pas beaucoup, c vrai, mais pour le mode liste, c presque indispensable. De plus, vue que c une structure en arborescence, le mode liste devrait disposer de 2 partie, une pour l'arborescence et une pour le contenus d'un dossier ou d'une section.
Dernier point concernant l'interface, ce serait de limité le nombre de menu afin d'utiliser l'espace restant pour afficher des infos utile (du genre la ram disponible, car c toujours chiant de devoir aller dans 3-4 menu/fenètre pour avoir cette infos avant de lancer un programme). Pasque les menu, c bien beau, mais c pas necessairement utils, vue que ce ne sont, en définitif, que des pop-up. Ce que je te conseillerais pour réduire le nombre de menu, c de regroupé sur une même fenètre avec des tab des info du même type, par exemple filtrage, association, etat mémoire je les mettrait dans une même fenètre dans 3 tabs différents, ce qui fait plus qu'un seul élément au lieu de 3. En procédent de cette manière, il ne te resteras que des menu que de 3-4 éléments, que tu pourras rassembler sous un seul menu avec des sous-menu contenant les 3-4 éléments.
A si, un petit détail, essyes d'utiliser un peu plus judicieusement la barre d'état, il y a plein d'espace qu'il serait possible d'utiliser.

En ce qui concerne les icones, ce n'est pas un prbm, à la limite, dans le read-me tu indique ou elle se situe dans le programme et l'utilisateur les modifie à coup d'éditeur hexa. Essayes de voir si tu peut récupérer les icones intégré dans certain programme _nostub et de gérer les banques d'icones d'ID.

Mais c'est vrai que c'est moche, faut pas le nier ... regardez PCT !

Flanker: pkoi servir aux programmeurs uniquements

Flanker :
mais je ne veux pas que ça prenne trop de place (je vais finir par faire plus de 64ko )

Les menus AMS sont idéaux pour ça, donc garde-les!

MacIntoc :
Je ne vois pas en koi faire une interface personnaliser empècherais d'utiliser les menu d'AMS. C'est surtout la barre de menu qui est pas belle et qui mériterais d'être retouché.

Si tu "retouches la barre de menu", tu n'utilises pas les menus d'AMS!

Ensuite, il s'agit de l'interface ente la barre de menu et la barre d'état qui prend le plus de place. Le mode icone n'en necessite pas beaucoup, c vrai, mais pour le mode liste, c presque indispensable.

Il n'est pas nécessaire de traffiquer les menus juste pour ça.

De plus, vue que c une structure en arborescence, le mode liste devrait disposer de 2 partie, une pour l'arborescence et une pour le contenus d'un dossier ou d'une section.

En revanche, ça, c'est une bonne idée.

Dernier point concernant l'interface, ce serait de limité le nombre de menu afin d'utiliser l'espace restant pour afficher des infos utile

Élément d'interface totalement non-standard et inutile. La barre des menus est là pour les menus, pas pour ce genre d'informations.

(du genre la ram disponible, car c toujours chiant de devoir aller dans 3-4 menu/fenètre pour avoir cette infos avant de lancer un programme).

Sauf que dans un bon shell (en 2 parties, comme le TICT Explorer), la RAM disponible dans le shell n'est pas celle disponible au lancement d'un programme, parce que la partie principale du shell est déchargée lors du lancement d'un programme.
Et puis, il y a des manières plus standard pour afficher ce genre d'informations:
1. la barre d'état.
2. un dialogue accessible en un seul appui de touche (F5 dans le TICT Explorer).

Pasque les menu, c bien beau, mais c pas necessairement utils, vue que ce ne sont, en définitif, que des pop-up.

Ce ne sont pas "que des popups", c'est le menu principal de l'application, et il est bien à sa place.

Ce que je te conseillerais pour réduire le nombre de menu, c de regroupé sur une même fenètre avec des tab des info du même type, par exemple filtrage, association, etat mémoire je les mettrait dans une même fenètre dans 3 tabs différents, ce qui fait plus qu'un seul élément au lieu de 3. En procédent de cette manière, il ne te resteras que des menu que de 3-4 éléments, que tu pourras rassembler sous un seul menu avec des sous-menu contenant les 3-4 éléments.

Les tabs dans les dialogues ne sont pas vraiment prévus par le système de dialogues de AMS, mais comme AMS lui-même les utilise (cf. menus [MODE] et [CATALOG] pour des exemples de tabs), ça peut se défendre. Pour réaliser des tabs, il faut rajouter un menu dans le dialogue, avec juste des titres et pas de items.

A si, un petit détail, essyes d'utiliser un peu plus judicieusement la barre d'état, il y a plein d'espace qu'il serait possible d'utiliser.

Cf. ma remarque au sujet de la RAM libre plus haut.

Essayes de voir si tu peut récupérer les icones intégré dans certain programme _nostub

Cf. http://pub26.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=161.topic pour la doc et la librairie statique (utilisable aussi en assembleur) téléchargeable pour gérer les commentaires, icônes etc. en ce format. Pour le feedback en vue d'une révision future, c'est là: http://pub26.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=174.topic.

> Kevin je t'ai pas attendu pour gérer les commentaires et les icônes.

Pour l'interface en deux parties, je pense que c'est le genre de trucs qui bouffent un max de place, qui sont un peu (?) lourds à programmer, et je ne sais pas s'il y a assez de place sur l'écran. Déjà que je lutte pour tout faire tenir sur un écran de 89....

Pour les titres des menus, je pense qu'en les raccourcissant je pourrais libérer un peu d'espace à droite pour mettre la RAM libre.

Pour la RAM libre, y a toujours une option 'libérer la RAM' pour exécuter un programme.
Sur 92+, ça va réduire la pile d'expression (on gagne 14ko) et sur les autres calc, ça efface CS et ça réduit la pile d'expression => on gagne 64ko. Pas besoin de découper le shell en 2 parties (mais c'est vrai que la méthode que j'ai utilisé est vraiment pas belle)

> nEUrOO y a déjà tout plein de shells hyper jolis, avec plein de fonctions pour ceux qui n'ont pas besoin des désassembleurs de CS, de son éditeur hexa, de son explorateur de handles.... Je pense pas être capable de faire plus joli

Flanker :
mais je ne veux pas que ça prenne trop de place (je vais finir par faire plus de 64ko )

Les menus AMS sont idéaux pour ça, donc garde-les!

MacIntoc :
Je ne vois pas en koi faire une interface personnaliser empècherais d'utiliser les menu d'AMS. C'est surtout la barre de menu qui est pas belle et qui mériterais d'être retouché.

Si tu "retouches la barre de menu", tu n'utilises pas les menus d'AMS![/cite]
Il s'agit d'un simple pop-up. La barre de menu est là juste pour faire jolie. Et comme elle est pas jolie, elle ne sert strictement à rien. Donc au tant les supprimer (en diminuant au maximum leur nombre) et/ou en dessinner de plus jolie à la place, en faisant appelle à un pop-up par la suite.

Ensuite, il s'agit de l'interface ente la barre de menu et la barre d'état qui prend le plus de place. Le mode icone n'en necessite pas beaucoup, c vrai, mais pour le mode liste, c presque indispensable.

Il n'est pas nécessaire de traffiquer les menus juste pour ça.

Comme je l'est dit, je ne parle pas de la barre de menu.

De plus, vue que c une structure en arborescence, le mode liste devrait disposer de 2 partie, une pour l'arborescence et une pour le contenus d'un dossier ou d'une section.

En revanche, ça, c'est une bonne idée.

Dernier point concernant l'interface, ce serait de limité le nombre de menu afin d'utiliser l'espace restant pour afficher des infos utile

Élément d'interface totalement non-standard et inutile. La barre des menus est là pour les menus, pas pour ce genre d'informations.

(du genre la ram disponible, car c toujours chiant de devoir aller dans 3-4 menu/fenètre pour avoir cette infos avant de lancer un programme).

Sauf que dans un bon shell (en 2 parties, comme le TICT Explorer), la RAM disponible dans le shell n'est pas celle disponible au lancement d'un programme, parce que la partie principale du shell est déchargée lors du lancement d'un programme.
Et puis, il y a des manières plus standard pour afficher ce genre d'informations:
1. la barre d'état.
2. un dialogue accessible en un seul appui de touche (F5 dans le TICT Explorer).

Il est toujours possible de déduire la ram utiliser par le shell, même s'il ne s'agit que d'une estimation.
La barre d'état est plus utils pour afficher des chose qui change souvent, par exemple la description d'un fichier dans Tictex. Et puis, la taille de la bare d'état est trop faible.
Le fait de devoir appuyer sur F5 est une gène. La ram dispo est quand même une info importante pour éviter de faire planter certain prog qui ne sont pas protéger contre ce genre d'erreur, et doit donc être accessible d'un simple coup d'oeuil.

Pasque les menu, c bien beau, mais c pas necessairement utils, vue que ce ne sont, en définitif, que des pop-up.

Ce ne sont pas "que des popups", c'est le menu principal de l'application, et il est bien à sa place.

Explique moi la différence entre un pop-up et le menu, hormis la petite case du haut ??

A si, un petit détail, essayes d'utiliser un peu plus judicieusement la barre d'état, il y a plein d'espace qu'il serait possible d'utiliser.

Cf. ma remarque au sujet de la RAM libre plus haut.

La barre d'état serait plus utiles dans un shell pour afficher les info sur un fichier particulier (comme le fait Tictex).

Aprés, Flanker, tu fait ce que tu veux, c juste des conseil en passant, mais y a toujours moyen de faire quelquechose de jolies qui prend quasiment pas de place, ce serait dommage de passer à coté

MacIntoc, ton message est limite illisible et peut porter à des contre-sens, vu que tu as oublié des cite dans tous les sens! C'est le parfait exemple où l'intervention d'un modérateur (qui a suivi le topic et sait par conséquent quelles parties du message sont des citations) pour corriger le message serait très utile.

MacIntoc
:

MacIntoc :
Je ne vois pas en koi faire une interface personnaliser empècherais d'utiliser les menu d'AMS. C'est surtout la barre de menu qui est pas belle et qui mériterais d'être retouché.

Si tu "retouches la barre de menu", tu n'utilises pas les menus d'AMS!

Il s'agit d'un simple pop-up. La barre de menu est là juste pour faire jolie. Et comme elle est pas jolie, elle ne sert strictement à rien. Donc au tant les supprimer (en diminuant au maximum leur nombre) et/ou en dessinner de plus jolie à la place, en faisant appelle à un pop-up par la suite.

C'est totalement faux. Un rolldown d'une barre de menus n'est pas un popup. Il y a des différences fondamentales:
1. L'endroit de l'affichage. Un popup est affiché n'importe où (normalement au centre), un rolldown est affiché à un endroit bien précis (en dessous du menu choisi).
2. Les touches disponibles! Différence très importante! Dans un rolldown, si tu appuies sur [droite] et qu'il n'y a pas de sous-menu (sinon, il faut appuyer encore une fois) ou si tu appuies sur [gauche], tu passes au rolldown d'à côté. Il n'y a pas du tout ce genre de fonctionnalité avec un popup. Tu peux aussi appuyer sur une touche [Fn] avec un rolldown ouvert pour en ouvrir un autre, autre chose qui n'est pas du tout prévue par les popups.
3. Un popup peut avoir un titre à lui-même, un rolldown n'a pas de titre à lui-même, le "titre" est celui du menu au-dessus.
etc.
Les points 1 et 3 sont peut-être simulables avec des popups, mais le point 2 certainement pas! Rolldowns et popups ne sont pas interchangeables.

(du genre la ram disponible, car c toujours chiant de devoir aller dans 3-4 menu/fenètre pour avoir cette infos avant de lancer un programme).

Sauf que dans un bon shell (en 2 parties, comme le TICT Explorer), la RAM disponible dans le shell n'est pas celle disponible au lancement d'un programme, parce que la partie principale du shell est déchargée lors du lancement d'un programme.
Et puis, il y a des manières plus standard pour afficher ce genre d'informations:
1. la barre d'état.
2. un dialogue accessible en un seul appui de touche (F5 dans le TICT Explorer).

Il est toujours possible de déduire la ram utiliser par le shell, même s'il ne s'agit que d'une estimation.

C'est n'importe quoi. Tu n'as jamais vu un shell en C apparemment. Ne mesure pas tout à l'aide de ton petit shell en BASIC. Avec une architecture en 2 parties, la mémoire prise par le shell lors du listing des répertoires est totalement différente de la mémoire prise lors de l'exécution d'un programme! Et cela parce que le shell est entièrement chargé lors du listing des répertoires et presque entièrement déchargé lors de l'exécution d'un autre programme. Il peut aussi avoir alloué une quantité très variable (dépendante, par exemple, du nombre de fichiers dans un répertoire) de mémoire temporaire avec malloc et consortes, qui sera elle aussi libérée lors du déchargement de la partie principale du shell. Le TICT Explorer prend une trentaine de KO lors du listing des répertoires, mais 7 KO seulement lors de l'exécution d'un programme.

La barre d'état est plus utils pour afficher des chose qui change souvent, par exemple la description d'un fichier dans Tictex.

Solution simple: on affiche des informations comme ça si aucun fichier n'est sélectionné. Par exemple si le curseur est sur l'entrée .. si elle existe.

Et puis, la taille de la bare d'état est trop faible.

123 files, 123456B, 1234567B free RAM
Ça devrait rentrer même sur TI-89, ça.

Le fait de devoir appuyer sur F5 est une gène. La ram dispo est quand même une info importante pour éviter de faire planter certain prog qui ne sont pas protéger contre ce genre d'erreur, et doit donc être accessible d'un simple coup d'oeuil.

Cette information est:
1. fausse et
2. pas si importante que ça
si le shell se décharge au lancement d'un programme comme il est censé le faire.

Pasque les menu, c bien beau, mais c pas necessairement utils, vue que ce ne sont, en définitif, que des pop-up.

Ce ne sont pas "que des popups", c'est le menu principal de l'application, et il est bien à sa place.

Explique moi la différence entre un pop-up et le menu, hormis la petite case du haut ??

Cf. ci-dessus.

A si, un petit détail, essayes d'utiliser un peu plus judicieusement la barre d'état, il y a plein d'espace qu'il serait possible d'utiliser.

Cf. ma remarque au sujet de la RAM libre plus haut.

La barre d'état serait plus utiles dans un shell pour afficher les info sur un fichier particulier (comme le fait Tictex).

Cf. ci-dessus.