1

Bonjour à tous ! smile

Cela fait maintenant un an que j'ai commencé à programmer en C sur tigcc (et en C tout court), et à force de coder il m'est venu le besoin de créer une librairie pour gérer des boîtes de dialogues complexes facilement.

Je me suis intéressé à ce qui existait déjà et ait découvert Advanced Dialogs, une librairie statique utilisant extgraph, mais elle s'est avérée laide, lente et légèrement buggée.

J'ai donc créée ma propre librairie statique, bien plus esthétique et performante, jusqu'à ce que je me trouve face à un nouveau problème : la taille. Créer un petit programme (une trentaine de lignes) utilisant ma librairie et créant une seule boîte de dialogue (assez complexe tout de même) me prend plus de 20 ko !

Et au vu de la limitation de la calculatrice de la taille des fichiers à 65ko, jamais je ne pourrais créer un gros programme utilisant cette librairie !


J'ai deux idées en tête pour résoudre ce problème mais je ne saurais trouver la meilleure :

1) transformer ma librairie statique en librairie dynamique?
2) j'ai entendu parler d'un moyen de passer la protection des 65 ko. Est-ce une bonne solution, c'est-à-dire simple et efficace?

Merci.

2

Lepzulnag (./1) :
1) transformer ma librairie statique en librairie dynamique?

Ca ne fait que mutualiser le code si plusieurs programmes utilisent ta lib. En clair, si un seul programme de ta calc utilisent la lib, ça ne change rien. Si deux l'utilisent, la lib dynamique est préférable.
Lepzulnag (./1) :
2) j'ai entendu parler d'un moyen de passer la protection des 65 ko. Est-ce une bonne solution, c'est-à-dire simple et efficace?

64ko. Le seul moyen est d'utiliser plusieurs fichiers pour un même programme. Ca peut effectivement se décomposer en programme exécutable, librairie dynamique, fichier de données externes. Arrive un moment où tu n'as pas le choix, oui.

3

Ok merci smile

Donc je pense que je vais bel et bien transformer ma librairie statique en librairie dynamique. Juste quelques précisions pour vérifier que j'ai bien compris ce que j'ai lu sur la création d'une librairie dynamique (corrigez-moi si une affirmation est fausse) :

Dans le code de la librairie :

1) il faut mettre USE_KERNEL et int_library dans chaque fichier.
2) le nom de ma librairie, supposons MyLib, est le nom du fichier qui sera transmis à la calculette.
3) les fonctions que je voudrais exporter, je devrais les nommer MyLib_xxxx où xxxx est un nombre. (puis-je commencer par 9421, par exemple, puis 7412, ou faut-il suivre un ordre croissant ?)
4) les fonctions que j'utiliserais de façon interne, je peux les nommer comme je veux.

Dans le code des programmes utilisant la librairie :

1) il faut mettre USE_KERNEL dans chaque fichier.
2) pour importer une fonction, il suffit de faire MyLib_xxxx(arguments).

4

Lepzulnag (./1) :
J'ai deux idées en tête pour résoudre ce problème mais je ne saurais trouver la meilleure :

1) transformer ma librairie statique en librairie dynamique?2) j'ai entendu parler d'un moyen de passer la protection des 65 ko. Est-ce une bonne solution, c'est-à-dire simple et efficace?

Franchement, elles sont toutes les deux mauvaises. Le vrai problème est la taille, 20 Ko pour des boîtes de dialogue n'est tout simplement pas acceptable!

Donc pour commencer, il faudrait te demander s'il valait vraiment le coup de réinventer la roue, sachant que AMS fournit déjà un système de dialogues. Forcément, réinventer ses propres dialogues prend de la place! (Place qui à mon avis serait mieux utilisée pour des fonctionnalités que le système d'exploitation ne propose pas encore…)

Ensuite, il faut savoir que dans une bibliothèque (lib) statique, seules les fonctions effectivement utilisées (à condition que tu utilises les options par défaut de l'EDI, notamment -ffunction-sections lors de la compilation de la lib et "Remove unused sections" lors du linking de l'application, sinon c'est carrément par fichier .c) seront effectivement linkées. Donc si tout ton code est dans une seule fonction, c'est très mauvais, il faut décomposer ton code. Au lieu de mettre tout ton code dans la fonction équivalente à DialogDo, mets-la dans des fonctions auxiliaires que tu appelles par pointeur de fonction, et fais en sorte que tes fonctions équivalentes à DialogAdd* mettent les pointeurs vers les bonnes fonctions auxiliaires dans la structure de ton dialogue. Ainsi, si tu n'utilises par exemple pas d'entrées de texte dans un programme, le code pour les entrées de texte ne sera pas inclus.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

(tiens, je suis d'accord avec Kevin sur un point : 20 Ko, pour une gestion de boîtes de dialogue, ça me paraît gros)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

6

Oui en effet, ma 3e idée était de réduire la taille, mais je ne voyais pas comment cela était possible. smile

Par rapport aux systèmes de dialogues par défaut d'AMS, je ne pense pas avoir réinventé la roue, mais créé le pneu. Il n'y a esthétiquement rien de comparable, ma bibliothèque utilisant les niveaux de gris, et permettant plus de possibilités que les fonctions de l'AMS (une gestion aisée des onglets, bien plus de designs possibles, quelques widgets/items supplémentaires comme les checks, multichecks et boutons, la possibilité pour l'utilisateur de gérer facilement une barre de progression).
Mais bon nous sommes tous d'accord, ce pneu est obèse sad

Aussi merci beaucoup pour le conseil Kevin, en effet je ne savais absolument pas comment la bibliothèque gérait les fonctions des bibliothèques statiques smile Je retiens ta technique avec les pointeurs de fonctions, et je pense pouvoir bien optimiser le code. Il faut voir aussi que j'utilise extgraph, et ajouter à la taille de mes programmes ses propres fonctions.

Je vais avant tout optimiser, et si je suis satisfait en resterait à une bibliothèque statique, car je pense que c'est le plus adapté pour des boîtes de dialogues.

7

Folco :
Lepzulnag :
1) transformer ma librairie statique en librairie dynamique?

Ca ne fait que mutualiser le code si plusieurs programmes utilisent ta lib. En clair, si un seul programme de ta calc utilisent la lib, ça ne change rien. Si deux l'utilisent, la lib dynamique est préférable.


Je pensais qu'une bibliothèque dynamique, c'était un fichier présent sur la calculette qui en contenait le code. C'était donc une solution puisque cela aurait séparé les 20ko en deux fichiers : la bibliothèque et le programme l'utilisant. La taille de la bibliothèque serait donc (plus ou moins) soustraite de celle du programme, le faisant reculer de la limite des 64ko.

8

C'est effectivement le cas, mais ça ne fait une différence pratique que quand le programme dépasse effectivement les 64 ko quand il inclut ta bibliothèque. Sinon, la différence ne se remarque effectivement que quand plusieurs programmes l'utilisent, comme le dit Folco.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

9

Ah oui, même réflexion que les autres, 20 ko c'est énormes, niveaux de gris ou pas... Tu pourrais poster les specs stp ?

(ps -> laissez-le coder ce qu'il veut, j'ai fait exactement la même chose, une fois sur TI en asm, une fois sur PC en C++, juste pour voir comment ça pouvait marcher. C'était bien fun. oui)

10

Folco (./9) :
Ah oui, même réflexion que les autres, 20 ko c'est énormes, niveaux de gris ou pas... Tu pourrais poster les specs stp ?


Euh... pardonne mon ignorance, mais que sont les specs ??

11

Les spécifications. En gros le détail de ce que permet de faire ta bibliothèque.
avatar

12

Voilà :

I) Création et gestion aisée d'une boîte de dialogues au design personnalisable (au niveau du titre, du background, des bordures, 3~4 choix différents pour chaque)

- Gestion simple des onglets (jusqu'à 6 onglets, nombre modifiable par l'utilisateur).
- Widgets statiques (ligne H/V, rectangle, image, texte avec quelques options [police, alignement, algorithme de saut automatique à la ligne]).
- Et widgets dynamiques (check, multi-checks [avec deux designs possibles], saisie de texte, pulldown, bouton). Je comptais ajouter un "menu", mais c'est assez délicat de le faire personnalisable et simple d'utilisation à la fois.
- Utilisation simple des barres de progression (considérées comme un widget statique, l'utilisateur peut redessiner ses barres de progression à l'aide d'une simple fonction).
- Possibilité d'associer à chaque widget une fonction CALLBACK qui réagit selon deux critères : le "survol" du widget et sa "modification". Avec cela il est possible de faire des boîtes de dialogues très variées et simplement. Les boutons trouvent également leur utilité grâce aux fonctions CALLBACK.
- Possibilité d'associer à chaque onglet une fonction CALLBACK qui réagit lors de l'appui de certaines touches, précisées par le programmeur.
- Possibilité d'afficher un ou deux boutons "Enter/Esc", au texte personnalisable, et possibilité de ne pas réagir à l'appui des touches ENTER/ESC.
- Possibilité d'afficher une boîte de dialogue sans l'activer, et de l'activer plus tard.
- Gère automatiquement si les niveaux de gris ont été préalablement activés ou non avant l'activation d'une boîte de dialogue afin de ne pas fatiguer ceux qui ne les utilisent pas.


II) Boîtes de dialogues standard

- Ouvrir, Sauvegarder, Message d'erreur. Entièrement créées avec cette bibliothèque.


Le tout a été esthétiquement longuement recherché. Les boutons "ENTER/ESC" et boutons dynamiques réagissent différemment au survol et à l'appui pour un effet encore plus joli. Les AUTO_INT 1 et 5 ont été désactivés respectivement pour les niveaux de gris et la gestion personnelle des touches ALPHA, 2ND, SHIFT et DIAMOND.

J'ai surement oublié plusieurs choses étant donné que mon code est actuellement sur un autre ordinateur, mais je pense que cela est suffisant et permet de montrer que j'ai voulu donner à cette bibliothèque simplicité d'utilisation, esthétique et personnalisation. Mais j'ai peut-être mis trop d'options et mon code est trop lourd.

13

C'est plus une gestion de boîtes de dialogues là, c'est limite un mini-gestionnaire de fenêtres grin
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

14

Et pourtant, je ne crois pas. Faut avouer que c'est lourd.

Merci d'avoir posté tes spécifications happy

(Si j'avais du temps à tuer, le challenge serait de faire la même chose en asm, en ... 5 ko sans les graphismes trilove)

15

Facile à dire tongue

Screenshot, sinon ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

16

Zeph (./15) :
Screenshot, sinon ?


Avec les demandes de spécifications, puis de screenshots, j'ai l'impression que suis déjà en train de présenter mon projet, alors que le problème de taille n'est pas résolu grin

A l'origine je comptais distribuer ma création, avec la doc et tout le blabla, car si moi-même en trouve l'utilité, surement d'autres personnes aussi. Mais la taille m'a un peu découragé (qui voudrait d'une bibliothèque qui prend la moitié de la taille de son programme ?), d'où l'origine de ce sujet.

Enfin je veux bien donner les screenshots, mais comme je ne suis actuellement pas en possession de mon code ni de mon câble, je ne le puis sad Ce week-end je les posterais.

17

Lepzulnag (./16) :
qui voudrait d'une bibliothèque qui prend la moitié de la taille de son programme ?

Simple. T'écris ta lib en read-only, sans données en section de code, ni d'appels système relogés, tu dis que ça ne tourne que sous PedroM et le tour est joué. tongue

18

Alors maintenant que j'ai récupéré un câble, j'ai voulu mettre des screenshots, mais comme je n'utilise pas d'émulateur, cela semble impossible avec tiConnect tant que le programme tourne.

Existe-t-il un autre programme pour obtenir des screenshots ou est-ce simplement impossible on-calc quand le logiciel qui tourne est écrit en C ?

19

ou est-ce simplement impossible on-calc quand le logiciel qui tourne est écrit en C ?

Contrairement aux Nspire, les TI-68k et TI-Z80 ne tournent pas d'OS préemptif. Si tu ne donnes jamais la main (directement ou indirectement) au code de l'OS qui gère le silent link pour les screenshots, le déclenchement de screenshots sera impossible smile

Si tu ne veux vraiment pas utiliser d'émulateur, une solution possible pour avoir des screenshots est de créer des fichiers (de préférence avec les fonctions de vat.h) et d'écrire le contenu de l'écran dedans, quand telle ou telle touche a été pressée ^^
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

20

Bon courage pour faire ça avec du NVG
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.