Je te remercie pour ta proposition. Pour avoir déjà réaliser quelques projets personnels, deux stages, sans oublier les projets d'école, je compte en effet faire de heftyAD mon first real programming project. De ce fait, je compte maintenir le code tout seul. En tout cas pour l'instant je me débrouille relativement bien (même si effectivement je dois t'accorder que la partie graphique d'une application mérite clairement qu'une équipe s'en occupe : placer les widgets au bon endroit, réfléchir à l’utilité d'un certain bouton, utiliser les couleurs adéquates, ..., rendre l'application intuitive, ce n'est clairement pas évident).
Toutefois, ce n'est pas pour rien que j'ai publié le code de l'application sur git. Les personnes intéressée pourraient toujours me faire part des éventuelles mauvaises pratiques de programmation. Aussi, afin de me simplifier la tâche, la traduction de l'application dans d'autres langues ne sera pas réalisée par moi. J'introduirais une fonctionnalité permettant à quiconque de traduire l'application dans n'importe quelle langue (et peut-être contribueras-tu).
Enfin, dans un futur relativement lointain (ou proche en fait), il n'est pas impossible que j'ai effectivement besoin de collaborer avec d'autres personnes sur le projet. Et dans ce cas, c'est avec joie que te solliciterais.
Je ne parlerais pas de programmation puisque ce n'est clairement pas mon domaine mais si jamais tu as besoins de quelqu'un pour rendre l'application un peu plus agréable à l'oeil n'hésites pas, tu sais ou me trouver!
Ah j'avais pas bien compris. Je suppose du coup que tu parles des icônes, logos et tout. Sinon voici quelques logos que j'avais déjà réalisés pour la version 1.3.
Le mec, son nom c'est Shadow (dessiné en une soirée et colorié avec Inkscape). Son style est inspiré des animes japonais que je regarde. Il sera l'ombre et l’assistant de l’utilisateur de heftyAD. L'image au milieu quant à elle correspond au logo. Toutefois, je compte redessiner Shadow (vue de face) en m'inspirant ce cette vidéo : https://www.youtube.com/watch?v=m9HaCkRK8fs&feature=youtu.be&t=660. Mais vu que je ne suis pas graphiste de base, j'aurais sans doute besoin (dans un futur proche) du l'aide de personnes plus talentueuses que moi dans le domaine.
@FarmBoo: Au fait quand tu dis "rendre l'application un peu plus agréable à l'oeil", fais tu bien allusion aux icônes et autres ? Ou sinon pourrais-tu mieux expliciter ? Par ce que ça m’intéresse bien d'avoir une application élégante (c'est d'ailleurs le sens de la lettre "e" dans "heftyAD").
Le projet avance. J'ai d'ailleurs mis en place il y a deux jours une version "propre" permettant de mettre en pause l'exécution de n'importe quel algorithme. Il reste encore pas mal de taff mais ça avance. De plus, j'ai mis à jour aujourd'hui le dépôt git du projet. Il est un peu mieux rempli je trouve (défiler vers le bas pour voir le texte).
Par ailleurs, plus j'avance sur le projet, plus je me rends compte en fait qu'il y a beaucoup voire trop de fonctionnalités à rajouter. Et si je devrais tout faire tout seul, ça risque de prendre pas mal de temps. Donc éventuellement si certains parmi vous sont intéressés par l'idée de contribuer au projet, et bien ils (ou elles) sont les bienvenu(e)s.
@FarmBoo: Au passage, si tu souhaites toujours rendre l'application un peu plus agréable à l'oeil, n'hésites pas à m'en informer.
Salut, très bonne idée de projet, si je puis me permettre d'apporter ma pierre à l'édifice :
Le choix d'un client lourd n'est peu être pas le plus approprié pour ce type d'application. Plusieurs raisons :
- Le web permet un accès beaucoup plus rapide et confortable au contenu qu'une application lourde. (rien à télécharger, rien à installer, juste un clic pour avoir la démo de l'algorithme souhaité)
- Mise à jour du contenu grandement simplifié, pas de redistribution de l'exécutable à prévoir - Pour un professeur éventuellement intéressé par ton projet, il n'a besoin que de donner l'url à ses élèves pour arriver directement sur l'exemple correspondant. Pour un cours en ligne, cela serait très appréciable. - Accès au contenu depuis n'importe où/n'importe quoi (salle de classe, transport, pc, smartphones, tablettes,... pratique quand on révise) - J'ai bien conscience que le développement d'une appli web et d'un client Qt n'ont absolument rien à voir, et comme tu as l'air à l'aise avec ce framework, j'imagine que tu n'as pas forcément envie de passer sur une autre technologie. Je pense cependant qu'une migration vers une appli web apporterait beaucoup d'avantage à ton projet.
Très bonne idée de permettre à l’utilisateur de créer sa propre structure de données
Est il possible de consulter l'algorithme? Si oui, sous quelle forme? Explications textuelles? Pseudocode? Langage de programmation? Dans ce cas, quel(s) langage(s) ?
Comment gères tu l'exécution des algorithmes? Sont ils écrits en dur dans ton code source? Tu aurais tout intérêt à les extraire du code source pour pouvoir les manipuler sans avoir à recompiler toute l'application. D'autant plus qu'un aspect "code interprété" faciliterait énormément l'exécution en mode debug de tes algorithmes (inspection des variables, breakpoints, ...)
Concernant la possibilité de rejouer des itérations, jette un oeil sur le pattern memento, si ce n'est pas déja fait
Bon courage!
PS: évite les trucs un peu trop tape à l’œil, comme les numéros de version et autres acronymes à rallonge
Edit : l'éditeur de message de ce site est une catastrophe!
Je te remercie pour ce message très constructif. Je vais donc répondre à tes questions une à une. Toutefois, j'anticipe en t'indiquant que je suis bien d'accord avec toi lorsque tu dis que l'éditeur proposé sur ce site est un peu limité, notamment en matière d’imbrication de listes à puces. Mais je pense qu'on peut contourner ce problème assez facilement.
heftyAD, web ou client lourd ?
Je ne doute pas des multiples avantages qu’offrirait le web si l'application y était hébergée. Mais le C++ étant réputé pour sa rapidité d'exécution et que de plus Qt propose pas mal de supports facilitant le dessin de graphics (cf. ces images par exemple), j'ai intuitivement opté pour ce langage. Surtout, je souhaite améliorer mes connaissances dans ce langage et ainsi mieux préparer mon insertion professionnelle. Faire d'une pierre plusieurs coups quoi.
Pour ce qui est de la mise à jour de l'application, je ne crois pas qu'il soit nécessaire de redistribuer l'exécutable. Je compte réaliser un Updater qui s'occupera tout seul de la mise à jour lorsque de nouvelles fonctionnalités sont intégrées à l'application.
Sim the Boss a écrit:
Pour un professeur éventuellement intéressé par ton projet, il n'a besoin que de donner l'url à ses élèves pour arriver directement sur l'exemple correspondant. Pour un cours en ligne, cela serait très appréciable.
Très intéressant ! Je n'avais pas vu les choses sous cet angle. Je pensais tout simplement que l'utilisateur, une fois qu'il a créé (ou téléchargé) un algorithme et un modèle, il les charge ensuite dans l'application et le tour est joué.
Sinon je comptais intégrer une sorte de « Store » dans le quel serait hébergé plusieurs exemples de modèles ainsi que des algorithmes associés. Tout le monde y aura donc accès. Quant à la possibilité pour un utilisateur (un professeur) de partager du contenu avec d'autres utilisateurs (des étudiants), on pourrait imaginer la possibilité de créer des Stores locaux. Les étudiants pourront ensuite y accéder seulement si le prof les y a autorisé.
Sim the Boss a écrit:
Accès au contenu depuis n'importe où/n'importe quoi (salle de classe, transport, pc, smartphones, tablettes,... pratique quand on révise)
J'avoue que là je ne vois pas trop comment je pourrais faire. Mais il est prévu qu'un utilisateur puisse exporter la sortie d'un algorithme ou le contenu d'un modèle.
Les autres questions
Sim the Boss a écrit:
Est il possible de consulter l'algorithme? Si oui, sous quelle forme? Explications textuelles? Pseudocode? Langage de programmation? Dans ce cas, quel(s) langage(s) ?
Il est prévu qu'un utilisateur puisse créer lui-même ses propres algorithmes en C++ (cf. les plugins de heftyAD toujours en cours de développement). Le code source d'un algorithme (via un plugin) sera accessible seulement si son créateur le permet. Mais dans le cas où il ne le permettrait pas, l'utilisateur est libre de ne pas l'utiliser.
Quant à la sécurité du code qui est fournit via le plugin, bah quand le code est disponible, c'est beaucoup plus simple à vérifier. Mais dans le cas contraire, je ne sais vraiment pas comment faire. Et je me doute bien que les différentes méthodes qui existent déjà ne sont pas forcément infaillibles. Au pire des cas, jobligerais tout le monde à montrer le coe de son algorithme. Comme ça plus besoin de se casser la tête.
Sinon oui pendant l'exécution d'un algorithme, des informations explicatives sont affichées. Tu peux vérifier en testant heftyAD-v1.3 (oui les numéros de version c'est bien). Mais dans cette version que j'ai codée pendant mes précédentes vacances estivales, il n'est pas possible de créer des algorithmes.
Sim the Boss a écrit:
Comment gères tu l'exécution des algorithmes? Sont ils écrits en dur dans ton code source? Tu aurais tout intérêt à les extraire du code source pour pouvoir les manipuler sans avoir à recompiler toute l'application. D'autant plus qu'un aspect "code interprété" faciliterait énormément l'exécution en mode debug de tes algorithmes (inspection des variables, breakpoints, ...)
Comme je l'ai précédemment mentionné, les algorithmes ne seront plus codés en dur dans l'application. Le gros problème que j'ai actuellement est de pouvoir contrôler le flux d'exécution d'un algorithme dont j'ignore complètement le code source (et donc la structure). Typiquement, regardons ensemble code ci-dessous :
void run(void) // corps d'un algorithme simple
{
for(int i=0; i<50; i++) {
blockIfSuspendRequested(); // met l'algorithme en pause si nécessaire
// code
for(int j=0; j<5000; j++) {
// code
blockIfSuspendRequested();
// code
}
}
}
On voit qu'on peut assez facilement mettre en pause l'exécution d'un algorithme. Mais pour ce qui est d'avancer/reculer d'une itération, c'est beaucoup plus compliqué, surtout pour les algorithmes récursifs. Je pense aussi à une structure de code semblable à celle ci-dessous (mais ce n'est pas évident non plus) :
Algorithm algo; // Algorithm présente une structure interne (à définir plus tard)
algo.next(); // on avance
algo.prev();
algo.pause();
// ...
Sinon heftyAD ne se veut pasz être un débogueur. Regarder le contenu dune variable, ..., personnellement je ne pense pas que ce sera facile pour quelqu'un qui souhaite s'améliorer en algorithmie sans trop se prendre la tête. Le but en fait est de pouvoir comprendre ce que fait un algorithme sans nécessairement disposer de son code source.
Sim the Boss a écrit:
Concernant la possibilité de rejouer des itérations, jette un oeil sur le pattern memento, si ce n'est pas déja fait
Oui il n'est pas impossible que j'en ai besoin. Si quelqu'un est intéressé par le projet et souhaite participer (car oui il reste encore pas mal de fonctionnalités à développer), il est le bienvenu. Ne serait-ce que pour réaliser les icônes, vous êtes le bienvenu aussi. Le projet étant gratuit, en participant, vous me permettrez d'aller plus vite sur certaines choses.
Grosse avancée sur heftyAD. Je le disais il y a quelques jours : j'avais du mal quant à la représentation des algorithmes afin que l'on puisse facilement en contrôler le flux d'exécution... Il y a quelques jours j'en ai parlé à un prof qui m'a ensuite orienté vers quelques pistes. Notre discussion a duré à peu près 2 minutes. Et vous savez quoi, ces deux minutes ont largement suffit car je m'y suis mis ce soir et je pense avoir trouvé une première solution à ce problème.
Dans la suite, je vous mets un code (légèrement commenté) qui montre comment on peut adapter n'importe quel algorithme à l'interface que propose heftyAD. Si vous ne connaissez pas le C++ ce n'est pas grave, vous pourrez toujours
lire les commentaires,
compiler le code en utilisant les commandes mises en haut du code source,
J'ai mis à jour l'affichage des plugins au sein de l'application. Ceux-ci sont chargés depuis un répertoire spécifique à l'application. Voici un rapide aperçu de ce que ça donne.
Un plugin n'est rien d'autre qu'un fichier .dll, .so ou .dylib (en fonction des OS) dont le contenu respecte l'interface de création de plugins mise en place dans le code source de heftyAD...
Une fois un algorithme choisi, on peut ensuite l'appliquer à un modèle. En cas de mauvaise manipulation, on peut obtenir un message d'erreur comme celui-ci :
En effet, l'algorithme du tri par fusion s'applique seulement aux tableaux, pas aux graphes par exemple. Sinon, si on choisit le bon modèle, la simulation démarre alors. De plus amples informations vous seront donner plus tard. Aussi, il faut que j'intègre des animations dans l'exécution de l'algorithme, afin de rendre l'application vraiment ludique.
Enfin, dans l'état actuel des choses, n'importe qui peut créer un algorithme et le lancer via une simulation au sein de l'application. La mise en pause est déjà opérationnelle. Maintenant il faut que je mettes en place le système permettant d'avancer et/ou reculer vers une itération souhaitée. De même, pour l'instant, les modèles associés aux algorithmes sont des widgets : il faut donc que je corrige ça, afin que les .dll ne soient pas inutilement grosses (celui montré ci-dessus fait 138 Ko , alors qu'il ne fait que trier un tableau, avec l'algorithme le plus naïf en plus).
Au fait j’oubliais, je travaille aussi sur la nouvelle version de Shadow, votre ombre et votre assistant au sein de l'application. Mais afin d’accélérer les choses, j'utiliserais celui que j'avais créé pendant mes précédentes vacances. Le voici en pleine action dans la précédente version de l'application :
J'ai testé heftyAD à l'instant qui est plutôt sympa (dommage que je n'en ai pas besoin^_^). Il me semble que t'en avais déjà parlé quelques messages plus haut et que c'est un peu la galère à implémenter mais ça serait cool d'avoir des flèches courbées *_*
Sinon c'est cool le système de plugin ! Ça marche comment concrêtement ? Les plugins doivent tous implémenter certaines fonctions que tu appellent depuis heftyAD ? C'était pas plus simple de mettre un place un petit interprêteur pour des scripts ?
Je te remercie pour ton intervention. Pour ce qui est de la possibilité de pouvoir courber les flèches (dans les graphes et automates), effectivement il y a quelques temps (pendant les précédentes vacances estivales), j'ignorais encore comment réaliser ce genre de choses. Mais à tout hasard, je suis tombé vendredi dernier sur ces super tutoriels :
Par contre ils ne sont pas documentés mais je devrais pouvoir m'en sortir.
Par ailleurs, quand tu dis
ErroMix a écrit:
J'ai testé heftyAD à l'instant qui est plutôt sympa (dommage que je n'en ai pas besoin^_^).
Merci d'avoir testé. Au passage, quelle version as-tu testé ? Celle sur le git du projet (la nouvelle donc) ou bien la version 1.3 accessible via le site web ?
Sinon j'ai envie de dire que c'est bien dommage que tu penses ne pas avoir besoin d'utiliser l'application. En effet, si tu es déjà super fort en algorithmie, je pense que ce serait l'occasion idéale pour expliquer ce que tu sais aux autres qui ne le savent pas. Si par contre tu n'es pas en informatique et que c'est la raison pour laquelle tu penses ne pas avoir besoin de heftyAD, je pense là aussi que c'est bien dommage. Le but de heftyAD est de permettre à n'importe qui de comprendre le fonctionnement des algorithmes, sans pour autant disposer de son code source. Et surtout, je pense en particulier que les étudiants s'ennuieront beaucoup moins à ce genre de cours.
Pour répondre à ta question sur les plugins, en effet un algorithme hérite de l'interface Iterable. Et voici ce à quoi ressemble un algorithme : Algorithm (il y a un exemple dans la doc de cette classe qui explique comment ça fonctionne). Sinon pour ce qui est des plugins, je te laisse jeter un coup d’œil à PluginInterface et AlgorithmPluginInterface. Si tu ne comprends pas, don't worry, n'hésites pas à me le faire savoir. Je réécrirais un autre message qui explique comment ça fonctionne sans pour autant me baser entièrement sur du code. Au pire je ferais une vidéo, même si je réservais la vidéo pour bien plus tard, lorsque le système d'écriture des algorithmes (plugins) sera vraiment clean.
Enfin,
ErroMix a écrit:
Sinon c'est cool le système de plugin ! Ça marche comment concrêtement ? Les plugins doivent tous implémenter certaines fonctions que tu appellent depuis heftyAD ? C'était pas plus simple de mettre un place un petit interprêteur pour des scripts ?
J’avoue que je n'ai pas tout compris concernant l'interpréteur. Pourrais-tu expliciter ?
Au début, je comptais carrément créer un langage de programmation dans lequel le code source des algorithmes serait exprimé. Mais après réflexion, je me suis rendu compte que même si cela me simplifierait beaucoup la vie (car l'algorithme sera écrit dans un langage simple et suffisamment générique puis sera ensuite généré le code C++ associé), les gens n'ont pas forcément envie d'apprendre un autre langage de programmation (enfin bon ce ne sera pas tant un langage de programmation, mais juste un langage pour exprimer des algorithmes). Peut-être faudrait-il que je reconsidère cette façon de procéder, car ça simplifierait (du moins je le pense) pas mal de choses, surtout pour le système permettant d'avancer et/ou reculer vers une itération souhaitée.
Merci et au plaisir de te lire. (Les autres aussi, si vous avez une remarque, je suis tout ouïe).
Justement, je n'arrive pas à visualiser ce que vous entendez par langage de script ou interpréteur de scripts. Ce serait bien si vous pouvez expliciter.
Pour l’instant, la version que j'ai déjà implémentée est plutôt simple et permet déjà de gérer facilement la mise en pause d'un algorithme. Je travaille actuellement sur la possibilité pour l'application de permettre d'avancer ou reculer vers une itération souhaitée.
// Vous pouvez tester le code à l'adresse : cpp.sh
#include <iostream>
/**
* Cet algorithme trouve et affiche le nombre de nombre pairs
* qu'il y a entre start et end.
*/
void runAlgorithm(int start, int end) {
int count = 0;
for(int i=start; i<=end; i+=2) {
count ++;
}
std::cout << "Il y a " << count << " nombres pairs entre " << start << " et " << end << "." << std::endl;
}
int main()
{
runAlgorithm(0, 10); // Afiche 6 : le nombre de nombres pairs entre 0 et 10.
std::cout << "---------------------------" << std::endl;
runAlgorithm(1, 10); // Afiche 5 : le nombre de nombres pairs entre 1 et 10.
}
La solution (d'adaptation à heftyAD) que je propose actuellement est basée sur une observation simple. En effet, on peut découper tous les algorithmes comme suit (que leurs codes sources contiennent ou non une boucle) :
avant toute exécution : une initialisation ;
une condition indiquant si l'algorithme peut toujours s'exécuter (afin d'exécuter une itération donc) ;
une opération préparant la prochaine itération, afin que l'algorithme puisse s’arrêter sil le faut ;
une opération indiquant ce que fait l'algorithme durant une itération ;
En partant de ces constats, la méthode exécutant un algorithme ressemble à ce qui suit :
void Algorithm::run(void)
{
preIterations(); // Initialisation des variables impliquées dans l'algorithme.
while(canIterate()) { // L'exécution peut-elle continuer ?
iterate(); // Exécuter une itération.
postIterate(); // On change la valeur des variables impliquées dans canIterate()
// afin que l'exécution puisse s'arrêter s'il le faut.
}
postIterations(); // Fonction pas super utile,
// fournie tout simplement parce qu'il y a preIterations().
}
J'espère que c'est beaucoup plus clair comme ça. Sinon, je suis toujours aussi curieux de comprendre ce que vous sous-entendez en parlant de langage de scripts. Est-ce pareil avec ce que je mentionne dans la toute fin de mon dernier post ?
La version que j'ai téléchargée est bien la 1.3. Je prendrai la nouvelle version depuis github à l'occasion.<br/><br/>
>Sinon j'ai envie de dire que c'est bien dommage que tu penses ne pas avoir besoin d'utiliser l'application. En effet, si tu es déjà super fort en algorithmie, je pense que ce serait l'occasion idéale pour expliquer ce que tu sais aux autres qui ne le savent pas. Si par contre tu n'es pas en informatique et que c'est la raison pour laquelle tu penses ne pas avoir besoin de heftyAD, je pense là aussi que c'est bien dommage
Ahah aucun des deux c'est simplement que les algo que j'utilisent ont peu d'intérêt à être représentés graphiquement ou alors mes outils le permettent déjà. <br/><br/>
Pour l'inteprêteur de script je pensais plutôt à en embarquer l'interprêteur d'un langage reconnu dans ton programme (J'sais pas ce qu'il existe comme langage de script adapté pour faire des math mais par exemple les moteurs de jeux embarquent presque tous un interprêteur Lua ou, moins couramment, JavaScript). Du coup l'utilisateur peut utiliser librement le langage de script et tu l'interface avec ton programme pour récupérer ce qui vient du script. J'suis pas un spécialiste de la chose (ça doit se remarquer à mon explication bancale ahah) mais en gros c'est une méthode qui existe et qui est reconnue pour être simple et efficace. Parmis les avantages : portables (contrairement aux DLL qui n'existent que sur Windows), un langage de script est bien plus simple à appréhender que le C++, ...
La version que j'ai téléchargée est bien la 1.3. Je prendrai la nouvelle version depuis github à l'occasion.
Pas de soucis pour la nouvelle version. Cela me ferait vraiment plaisir, même si je dois encore pas mal l'améliorer.
ErroMix a écrit:
c'est simplement que les algo que j'utilisent ont peu d'intérêt à être représentés graphiquement ou alors mes outils le permettent déjà.
Petit lapsus peut-être (les algorithmes ne sont pas représentés graphiquement). Le but de heftyAD n'est pas de permettre de représenter les algorithmes mais de permettre de comprendre assez facilement leurs fonctionnements. Et il n'y a vraiment pas de petits algorithmes : du moment où on peut en expliquer le fonctionnement, je pense que heftyAD pourra être utile.
ErroMix a écrit:
Pour l'inteprêteur de script je pensais plutôt à en embarquer l'interprêteur d'un langage reconnu dans ton programme (J'sais pas ce qu'il existe comme langage de script adapté pour faire des math mais par exemple les moteurs de jeux embarquent presque tous un interprêteur Lua ou, moins couramment, JavaScript). Du coup l'utilisateur peut utiliser librement le langage de script et tu l'interface avec ton programme pour récupérer ce qui vient du script. J'suis pas un spécialiste de la chose (ça doit se remarquer à mon explication bancale ahah) mais en gros c'est une méthode qui existe et qui est reconnue pour être simple et efficace. Parmis les avantages : portables (contrairement aux DLL qui n'existent que sur Windows), un langage de script est bien plus simple à appréhender que le C++, ...
Je te remercie pour la proposition. Personnellement je pense que j'aurais du mal à écrire un algorithme dans un langage de script alors que je peux directement l'écrire en C++. Mais je suis tout à fait d'accord avec toi que les personnes voulant écrire un algorithme ne souhaitent pas nécessairement le faire en C++. Je verrais dans la suite comment je peux faire pour que ce soit le plus simple possible. Peut-être devrais-je mettre en place un langage simple qui serve non pas à coder l'algorithme mais plutôt à le décrire. Il sera ensuite généré le code C++ de l'algorithme. Enfin bon cela reste une idée et vous avez le droit de m'en proposer d'autres. N'hésitez vraiment pas.
Sinon, pour information, l'équivalent des .dll Windows porte une autre extension sous les autres OS : en général .so sous Linux et .dylib sous Mac OS.
L'idéal serait de pouvoir écrire en pseudo (avec quelques mots clés bien entendu)... Cela permettrait de mettre rapidement à l'écrit des algorithmes et de les visualiser afin de les valider avant de les écrire en un autre langage...
L'être humain, contrairement aux geeks qui ne sont de toute façon pas des êtres humains, est un animal social taillé pour vivre en "meute".
Hummm. Cela rejoint un peu ce que je pensais au début : coder un langage simple permettant de décrire les algorithmes. Celui-ci sera compilé (ou peut-être interprété) afin que soit généré le code C++ associé. Le code C++ pourra ensuite être compilé à volonté. Du coup, les personnes qui s'y connaissent en C++ pourront coder directement avec ce langage alors que les autres pourront passer par ledit langage. Toutefois, je n'ai pas encore pensé à la structure de la grammaire du langage. Je n'ai pas non plus encore choisi les outils que j'utiliserais : sans doute Flex (ou JavaCC plus facile mais moins fiable parce que "nouveau" notamment en ce qui concerne la programmation en C++).
Je pense que je commencerais d'abord par rendre clean le codage de l'algorithme en C++ puis ensuite je rajouterais la couche du nouveau langage par dessus (si vraiment besoin il y a).
Je vous dirais d'ici la fin de la semaine (à priori) ce que j'aurais pu faire.
Bonne soirée à tous et à toutes.
Si certains ont des avis à partager/des remarques à faire, je suis tout ouïe.
heftyAD avance. Je voudrais tout d'abord vous informer que j'ai finalement redessiné l'assistant. Réalisé au crayon, son nouveau look vous est montré ci-dessous. Attention, on ne se moque pas !
J'ai ensuite essayé de le colorer avec Inkscape mais ça s'avérait trop compliqué, comparé à la version précédente de l'assistant pour laquelle la chevelure était beaucoup plutôt simple à imiter. Si vous êtes graphiste et que travailler sur le projet vous intéresse (heftyAD étant open-source, gratuit et donc pas de rémunération), surtout n'hésitez pas. Ou à contrario, si vous connaissez des logiciels permettant de bien redessiner assez facilement une "maquette ", merci de m'en informer.
Pour infirmation, voici l'ancien assistant ainsi que le logo de l'application tous dessinés à la main puis coloriés avec Inkscape.
De plus, en faisant quelques recherches sur internet aujourd'hui, je me suis rendu compte que certains algorithmes, ceux sur les graphes en particulier, lors de leur explication durant une simulation, nécessitent que l'on utilise un vocabulaire bien défini : cycle, chemin connexe, graphe parfait, etc. Afin donc qu'utilisateur puisse assez facilement comprendre ce qu'il en est, un nouvel onglet "Leçon" sera ajouté dans l'interface de l'application. L'application permettrait en fait non seulement d'expliquer le fonctionnement des algorithmes mais aussi de d'expliquer les notions sur les modèle associés (qu'est-ce qu'un graphe ?, une arête ? ...) Je ne compte pour l'instant pas encore implémenter cette fo,fonctionnalité (parce que j'ai déjà pas mal de boulot sur la simulation des algorithmes) mais je voudrais qu'en même vous tenir au courant.
Enfin, j'ai trouvé une solution permettant d' avancer ou de reculer vers une itération souhaitée. J'ai envie de dire "Yes, Yes, Yes...". Je ne l'ai pas encore codée mais normalement ça devrait fonctionner. Sinon pour l'instant les algorithmes sont toujours coder en C++ et les modèles toujours des objets graphiques. Mais ne vous inquiétez pas, tout ceci sera mis au "propre" au fur et à mesure.
Je vous tiens au courant pour la suite. Bonne après-midi à tous et à toutes.
Si vous avis des avis à partager ou des remarques à faire, surtout n'hésitez pas.
heftyAD avance. J'ai implémenté la fonctionnalité permettant d'avancer vers la prochaine itération. Je rappelle aussi que l'application est capable de mettre en pause le flux d'exécution d'un algorithme, sans pour autant disposer de son code source.
Si vous voulez vous remémorer les fonctionnalités phares de l'application, c'est par ici :
N'hésitez pas à ouvrir les images dans un nouvel onglet, afin de mieux les visualiser.
Voici par exemple ce que ça donne lorsqu'on exécute l’algorithme du tri à bulle permettant de trier un tableau.
On peut aussi dézoomer sur la zone d’affichage (à gauche).
Comme dans la version précédente de l'application, je rajouterais aussi une fonctionnalité permettant de sauvegarder la sortie de l'algorithme (je veux dire les textes affichés dans la parties à gauche).
Halalalalalala, ça avance, ça avance, ça avance !
Si vous avis des avis à partager ou des remarques à faire, surtout n'hésitez pas : je vous répondrais avec plaisir.
J'ai finalement redessiné l'assistant (au crayon). Voici la nouvelles version, coloriéée avec Inkscape puis déclinée sous plusieurs variantes, chacune apparaissant dans un contexte bien défini. J'ai pas mal galéré avec Inkscape avant d'arriver au résultat ci-dessous. Mais bon, j'en suis bien content, même si je l'améliorerais encore dans les prochains jours.
Voici ce que donne son intégration dans la panneau permettant de suivre l'exécution d'un algorithme.
Ce n'est sans doute pas encore parfait, mais ça avance et c'est l'essentiel je pense. Je rappelle aussi que dans l'état actuel des choses,
on peut créer son propre algorithme indépendamment de heftyAD ;
l'application peut ensuite contrôler le flux d'exécution dudit algorithme ; i.e. le mettre en pause, l'arrêter ou avancer vers la prochaine itération s(il y en a une).
Pour ce qui est de pouvoir reculer vers l'itération précédente, j'ai trouvé une solution mais je ne l'ai pas encore implémentée. Je vous remercie et bonne soirée à toutes et à tous.
L'interface du site est basé sur un template Wordpress gratuit. Mais je suis bien d'accord : il y a moyen de faire un site beaucoup plus joli. Si ça intéresse quelqu'un, qu'il n'hésite surtout pas.
Là je compte réaliser une vidéo expliquant clairement ce qu'est heftyAD et où c'en est. On verra bien si j'ai le temps de le faire.
Voici un nouvel algorithme créé avec heftyAD. Il explique comment générer simplement un mot de passe aléatoire. Certes l'intérêt est moindre pour quelqu'un qui s'y connaît en informatique. Mais pour quelqu'un qui n'y connaît rien, je pense que l'algorithme peut lui être utile et surtout n'importe qui peut vraiment comprendre.
Admirez combien heftyAD est souple : on peut vraiment écrire n'importe quoi comme algorithme. En tout cas, c'est l'un des buts escomptés.
De plus, notez que cet algorithme ne s'applique à aucun modèle, contrairement à l'algorithme du tris à bulles que j'ai montré ici et qui s'applique à un tableau. Aussi, vous remarquerez qu'aucun autre widget n'est affiché excepté le panneau de suivi de l'exécution de l'algorithme. Mais on peut créer soit même ses propres widgets et les ajouter à l'espace de simulation. Je vous montrerais ce qu'il en est dans un prochain algorithme que j'écrirais : son but sera d'expliquer comment on génère un labyrinthe parfait et ce, en des termes simples et claires bien sûr.
Sinon, dans un futur proche, je compte faire lire les textes par l'application. J'attends la sortie de Qt5.8 qui, à priori, intégreras un moyen de lire du texte dans une application Qt indépendamment de l'OS. La classe non ? En parallèle, je travaille aussi sur comment se passer non seulement du codage de l'algorithme en C++ mais aussi de la génération de plugins.
En voyant la discussion sur Dvp, ca m'a fait penser que j'avais oublie de t'embeter un peu... pardon, je voulais dire te donner mon avis
Pour commencer, un blog que j'aime bien, qui explique quelques algos pour les jeux : http://www.redblobgames.com/ (regardes en particulire A* ou visibility).
Du coup, quelques remarques si je compares les 2 projets.
J'imagine que tu n'es pas graphiste (ce n'est pas une insulte, je ne le suis pas non plus). Et celui qui ecrit ce blog doit etre un dev de jeux, qui a quelques talents artistiques. On voit la difference.
On avait parle du QML, cela pourrait ameliorer le rendu graphique de ton appli (ne pas utiliser le rendu de base des widgets).
Il existe pleins de sites pour les design (par exemple google material design, ou http://colorbrewer2.org/ pour choisir des couleurs). Cela permet rapidement d'avoir un rendu plus classe, surtout si on n'est pas designer.
En tant que dev, ton boulot est de fournir toutes ces possibilite de choix de rendu (forme et couleur des nodes, des fleches, degrades de couleurs, etc)
Note : a mon sens, la partie de gauche, avec tout le texte, est trop chargee.
2. les algos de graphs, c'est bien... mais c'est chiant
Plus precisement, parler d'un algo de graphe d'un point de vue theorique est pas "sexy". Alors que parler d'un algo de pathfinding (qui est le meme algo...) est "sexy".
Donne a un contexte a tes algos. Des applications concretes. C'est plus parlant de parler de Dijkstra pour une recherche de chemin dans un jeu que dans un graphe. Beaucoup d'algo sont vu en cours via une approche theorique (ce qui est normal), mais si tu fais la meme chose dans ton logiciel, c'est pas motivant.
Regardes les applications concretes des algos et utilises les. Et plus c'est graphiques (jeux par exemple, mais egalement simulation physique, cartographie, etc), mieux c'est.
3. Ta video presente ton projet... du point de vu du developpement. En gros, pour les eventuels devs interesses pour participer.
Il faut que tu fasses une video a destination des apprenants. Quelque chose qui donne envie d'apprendre les algos via ton logiciel.
Par exemple, le debut, ou l'on voit le graph qui est anime et pleins de couleur va dans le bon sens. Mais c'est trop rapide. Tout le reste... ce n'interesse que toi (ou presque, puisque tu es le seul dev pour le moment).
Voila, j'espere que ca va t'aider un peu. Bon courage.
Je te remercie pour ce joli paquet de texte. Le contenu est très intéressant. Je reviendrais dessus d'ici là : cette semaine j'ai des soutenances et rapports à rendre partout. Je récrirais une réponse plus détaillée d'ici demain peut-être.
Mais déjà, j'ai pu noter quelques trucs
gbdivers a écrit:
Ta video presente ton projet... du point de vu du developpement. En gros, pour les eventuels devs interesses pour participer.
Il faut que tu fasses une video a destination des apprenants. Quelque chose qui donne envie d'apprendre les algos via ton logiciel.
Entièrement d'accord. Il faut dire que c'est le genre de présentation que l'on fait pour nos soutenances à l'école. Mais j'ai déjà pensé à plusieurs autres scénarios, scénarios jouables seulement avec la prochaine version de l'application qui est encore très loin de ce que je souhaite.
gbdivers a écrit:
Par exemple, le debut, ou l'on voit le graph qui est anime et pleins de couleur va dans le bon sens. Mais c'est trop rapide.
En effet, on peut contrôler les temps d'attente entre les animations. Et ce que tu vois là n'est rien d'autre que ce que j'ai développé pendant mes précédences vacances estivales (alors que j'étais en stage et que je découvrais C++ en approfondi ainsi que le fonctionnement de Qt Graphics). Cette version est d'ailleurs testable
Pour commencer, un blog que j'aime bien, qui explique quelques algos pour les jeux : http://www.redblobgames.com/ (regardes en particulire A* ou visibility).
J'ai été vraiment impressionné, surtout par le "2D Visibility Algorithm" que je ne connaissais absolument pas. Sinon, concernant A*, le fait qu'il est fait le lien entre la représentation théorique de la map et son rendu effectif est vraiment nice. Je vais voir comment je peux faire pour que cela soit possible au sein de heftyAD. Avoir un graphiste sous la main pourra alors être très utile.
J'imagine que tu n'es pas graphiste (ce n'est pas une insulte, je ne le suis pas non plus). Et celui qui ecrit ce blog doit etre un dev de jeux, qui a quelques talents artistiques. On voit la difference.
Je suis entièrement d'accord pour les screenshots. Il est en effet prévu que l'on puisse configurer le mode d'affichage des éléments constituants un certain modèle (graphe, tableau, matrice, ...). Mais il y tellement de choses à faire... Voici une petite mise à jour sur les graphes juste en changeant la valeur d'un certain attribut depuis le code.
Merci aussi pour le lien vers les sites permettant de visualiser des couleurs avec leurs codes rgb associés. J'ai beau tapé tout ce qui me passait par la tête (en français, anglais, ... même en japonais) mais jamais ma requête n'a été suffisante pour que Google Chrome m'oriente vers ce genre de sites.
gbdivers a écrit:
On avait parle du QML, cela pourrait ameliorer le rendu graphique de ton appli (ne pas utiliser le rendu de base des widgets).
J'ai essayé QML hier. J'ai du lire pas mal de textes et j'avoue que c'est assez impressionnant. Le rendu ainsi que le fonctionnement de l'application peuvent même être facilement adaptés aux environnement des smartphones/tablettes. Pouvoir faire tourner heftyAD sur des périphériques Android (par exemple) n'est sans doute pas une nécessité mais cela demeure néanmoins une possibilité très intéressante.
Le seul problème est que là je n'arrive pas à évaluer combien de temps cela me prendra pour tout porter vers QML, sans doute parce que je découvre à peine. Aussi, l'approche qui est faite des threads dans QML me paraît assez étrange alors qu'avec Qt tout est tellement clair et limpide. J'ai d'ailleurs trouvé un seul exemple dans la doc de Qt : http://doc.qt.io/qt-5/qtquick-threading-example.html. Mais on ne peut pas vraiment dire que je l'ai lu à tête reposée... Chaque simulation (algorithme + éventuellement modèle) lancée au sein de heftyAD est contrôlée par un QThread différent.
gbdivers a écrit:
En tant que dev, ton boulot est de fournir toutes ces possibilite de choix de rendu (forme et couleur des nodes, des fleches, degrades de couleurs, etc)
Entièrement d'accord. Et comme je le disais précédemment, c'est quelque chose que j'ai prévu mais il y a tellement de choses à faire...
gbdivers a écrit:
Note : a mon sens, la partie de gauche, avec tout le texte, est trop chargee.
Je suis d'accord aussi. J'attendais impatiemment Qt Speech dans Qt5.8 pour voir s'il y a moyen de faire lire du texte par l'application. Comme ça l'apprenant pourra se concentrer sur le panneau central faisant aussi apparaître des animations au cours de la simulation. Ou bien tout simplement, je pourrais permettre à la personne créant l'algorithme d'enregistrer sa voix quitte à ce que l'audio associé soit lu à certains moments au cours de la simulation.
gbdivers a écrit:
2. les algos de graphs, c'est bien... mais c'est chiant
Entièrement d'accord. C'est l'une des raisons pour lesquelles j'ai commencé à développer heftyAD. Le but escompté est la vulgarisation des algorithmes : permettre à tout le monde de pouvoir comprendre facilement le fonctionnement des algorithmes. Mais je sais que je suis encore très loin du compte...
Ceux qui ont compris écrivent leurs algos, indiquent aussi des informations sensées expliquer ceux-ci (actuellement du texte -> d'où les textes dans la partie gauche) et ceux qui n'ont pas compris peuvent récupérer ces algorithmes et les exécuter afin de mieux comprendre.
gbdivers a écrit:
Plus precisement, parler d'un algo de graphe d'un point de vue theorique est pas "sexy". Alors que parler d'un algo de pathfinding (qui est le meme algo...) est "sexy".
Donne a un contexte a tes algos. Des applications concretes. C'est plus parlant de parler de Dijkstra pour une recherche de chemin dans un jeu que dans un graphe. Beaucoup d'algo sont vu en cours via une approche theorique (ce qui est normal), mais si tu fais la meme chose dans ton logiciel, c'est pas motivant.
Je n'ai vraiment rien à dire : ce que tu dis est tellement vrai. Ce qui est un peu chiant aussi, c'est que j'essaye de faire en sorte que d'autres personnes puissent créer leurs propres algorithmes. Et l'application étant sensée pouvoir contrôler leur flux d'exécution, je me retrouve à résoudre un problème carrément nouveau pour moi. Mais j'y suis presque.
gbdivers a écrit:
3. Ta video presente ton projet... du point de vu du developpement. En gros, pour les eventuels devs interesses pour participer.
Il faut que tu fasses une video a destination des apprenants. Quelque chose qui donne envie d'apprendre les algos via ton logiciel.
Par exemple, le debut, ou l'on voit le graph qui est anime et pleins de couleur va dans le bon sens. Mais c'est trop rapide. Tout le reste... ce n'interesse que toi (ou presque, puisque tu es le seul dev pour le moment).
Comme je te l'avais déjà dit dans ton précédent post, je suis entièrement d'accord avec toi. C'est d'ailleurs la 1ère fois que je réalise une vidéo pour présenter une application. Toutefois, j'ai déjà quelques autres idées de vidéos-démos. J'espère pouvoir montrer quelque chose de sympa très bientôt.
Un autre problème aussi, c'est que le thread qui exécute les algorithmes est à part et l'éventuel modèle auquel il est associé se trouve dans le gui thread. Du coup pour faire des animations, c'est assez galère. Mais en écrivant ma précédente phrase, je me rends finalement compte qu'on peut contourner ce problème. Je vais essayer la solution à laquelle je pense ; elle devrait fonctionner.
gbdivers a écrit:
Voila, j'espere que ca va t'aider un peu. Bon courage.
Tu ne peux pas savoir à quel point : ça m'aide énormément même je dirais. Le problème est qu'il y a tellement de choses à faire.
Mais au moins, la partie la plus compliquée (je pense), celle qui permet à heftyAD de contrôler le flux d'exécution d'un algorithme (avancer, reculer, mettre en pause, recommencer, ...) est quasi opérationnelle. Pour peu que l'algorithme en question respecte le contrat (l'interface) défini par l'application, celle-ci pourra contrôler son flux d'exécution. Le contrat dont il est ici question pour un algorithme est celui-ci :
Pour ce qui est du portage vers QML, j'ai bien peur que cela ne me prenne trop de temps. Mais c'est sûr qu'en bossant avec des dev plus expérimentés, ça ira beaucoup plus vite. Ce n'est d'ailleurs pas pour rien que le projet est open source.
Pour finir, je vous laisse sur ce zoli automate créé avec la précédente version de l'application.
Si vous avez d'autres remarques, surtout n'hésitez pas. Je vous répondrais avec plaisir. J'essaierais aussi d'avoir quelque chose de plus attirant à montrer d'ici là.
(Je vois que tu as découvert la modération "lien non perenne" sur Developpez )
misterFad a écrit:
en changeant la valeur d'un certain attribut depuis le code.
C'est déjà un probleme. Si tu veux être plus efficace (ie pas perdre ton temps a changer 10 fois chaque ligne de code pour le rendu), il est préférable de mettre ce type de propriété dans un fichier texte et laisser les utilisateurs la possibilité de modifier cela directement. Et te faire des retours sur ce qu'ils aiment comme paramètres.
Tu peux faire cela via QSettings (pour créer un fichier texte .ini), via CSS (cf les stylesheets de Qt) ou QML.
misterFad a écrit:
Pouvoir faire tourner heftyAD sur des périphériques Android (par exemple) n'est sans doute pas une nécessité mais cela demeure néanmoins une possibilité très intéressante.
Se poser sur son canapé avec sa tablette pour étudier un algo en utilisant ton application, tu ne crois pas que ca sera un plus ?
misterFad a écrit:
Le seul problème est que là je n'arrive pas à évaluer combien de temps cela me prendra pour tout porter vers QML, sans doute parce que je découvre à peine. Aussi, l'approche qui est faite des threads dans QML me paraît assez étrange alors qu'avec Qt tout est tellement clair et limpide. J'ai d'ailleurs trouvé un seul exemple dans la doc de Qt : http://doc.qt.io/qt-5/qtquick-threading-example.html. Mais on ne peut pas vraiment dire que je l'ai lu à tête reposée... Chaque simulation (algorithme + éventuellement modèle) lancée au sein de heftyAD est contrôlée par un QThread différent.
Long. Surtout que tu ne connais pas le QML. Et/ou que tu n'as pas correctement séparé ton code en modules.
Par contre, le QML sert pour l'interface graphique. Le reste de ton code metier (en particulier la simulation et les threads) n'ont pas besoin (a priori) d’être réécrit en QML. Il faut juste faire le binding en QML (c'est a dire ajouter les Q_PROPERTY dans tes classes Qt... rien de bien méchant si tes classes sont correctement écrites).
De plus, tu peux faire le portage progressivement. C'est a dire écrire une API QML en te basant ce qui existe et en ajoutant le binding QML petit a petit, classe par classe.
misterFad a écrit:
Entièrement d'accord. C'est l'une des raisons pour lesquelles j'ai commencé à développer heftyAD. Le but escompté est la vulgarisation des algorithmes : permettre à tout le monde de pouvoir comprendre facilement le fonctionnement des algorithmes. Mais je sais que je suis encore très loin du compte...
Un autre point que je n'avais pas abordé. Donner des explications claires et visuelles, c'est bien. Mais pouvoir appliquer ce que l'on a appris, c'est mieux.
Tu pourrais proposer la possibilité d’écrire son algo (a la manière de Scratch par exemple https://scratch.mit.edu/projects/10128431/#editor) pour voir si l'algo a bien été compris. Ou tester d'autres algos.
Une autre idée est la compétition d'algos. Il faut écrire un algo pour un jeu quelconque et se "battre" contre l'algo a étudier.
(Je vois que tu as découvert la modération "lien non perenne" sur Developpez )
Effectivement, oui : j'étais assez étonné au début de voir que mon lien a disparu. Mais après avoir remarqué que mon post a été édité par un modérateur, j'ai finalement compris.
gbdivers a écrit:
Si tu veux être plus efficace (ie pas perdre ton temps a changer 10 fois chaque ligne de code pour le rendu), il est préférable de mettre ce type de propriété dans un fichier texte et laisser les utilisateurs la possibilité de modifier cela directement. Et te faire des retours sur ce qu'ils aiment comme paramètres.
Tu peux faire cela via QSettings (pour créer un fichier texte .ini), via CSS (cf les stylesheets de Qt) ou QML.
Tu as tout à fait raison. Mais je comptais plutôt faire une interface permettant à l'utilisateur de configurer l'affichage des modèles. Mais bien sûr, pouvoir sauvegarder une configuration et la recharger plus tard ne ferait du mal à personne.
gbdivers a écrit:
Se poser sur son canapé avec sa tablette pour étudier un algo en utilisant ton application, tu ne crois pas que ca sera un plus ?
Vraiment rien à dire : entièrement d'accord.
gbdivers a écrit:
Par contre, le QML sert pour l'interface graphique. Le reste de ton code metier (en particulier la simulation et les threads) n'ont pas besoin (a priori) d’être réécrit en QML. Il faut juste faire le binding en QML (c'est a dire ajouter les Q_PROPERTY dans tes classes Qt... rien de bien méchant si tes classes sont correctement écrites).
En relisant la doc hier, c'est la conclusion à laquelle j'étais finalement arrivée. Tu fais bien de l'appuyer.
gbdivers a écrit:
De plus, tu peux faire le portage progressivement. C'est a dire écrire une API QML en te basant ce qui existe et en ajoutant le binding QML petit a petit, classe par classe.
Je vais faire une branche (sur git) pour le code QML (enfin bon peut-être qu'il y a moyen de procéder autrement). Par contre, vu que l'application pourra bénéficier d'un fonctionnement sur Tablettes & Mobiles, je vais devoir revoir son style/design. Plus de menu Fichier et j'en passe.
gbdivers a écrit:
Un autre point que je n'avais pas abordé. Donner des explications claires et visuelles, c'est bien. Mais pouvoir appliquer ce que l'on a appris, c'est mieux.
Tu pourrais proposer la possibilité d’écrire son algo (a la manière de Scratch par exemple https://scratch.mit.edu/projects/10128431/#editor) pour voir si l'algo a bien été compris. Ou tester d'autres algos.
Une autre idée est la compétition d'algos. Il faut écrire un algo pour un jeu quelconque et se "battre" contre l'algo a étudier.
Je ne connaissais pas Scratch mais j'ai envie de dire que le concept est plutôt intéressant. Et dire que le projet existait depuis 2007. Heureusement que le principe dans heftyAD diffère de celui qur lequel Scratch est basé. Car sinon, je risquerais d'abandonner mon projet. Même si leur interface devient rapidement comble quand on commence à rajouter plein de trucs. Mais c'est sans doute l'effet "découverte" qui fait ça.
Pour ce qui est de la compétition algorithmique, en écrivant les premières versions de l'application pendant les vacances, j'avais prévu une fonctionnalité permettant aux personnes intéressées de réaliser des challenges.
L'assistant qui parle se prénomme en effet Shadow. Sinon oui : l'idée de la compétition algorithmique pourrait être intéressante dans une certaine mesure, du moment où ce n'est pas un fork de CodinGame ou autre...
Une chose est sûre, permettre à un apprenant d'appliquer ce qu'il a appris est très crucial. C'est d'ailleurs l'idée des challenges. Il faudrait d’ailleurs que je mette à jour le Trello du projet. Il y a longtemps que je n'y ai pas touché.
Je devrais aussi choisir quelles tâches je veux réaliser en premier car sinon ça ne va pas trop le faire. Peut-être devrais-je passer aussi le projet dans la section Recrutement, en particulier pour recruter des graphistes pour les icônes et tout. PArce que là je me retrouve à galérer avec Inkscape et Gimp. Mais bon, ça fait sans doute partie de la formation.
heftyAD avance. Pour l'instant rien de nouveau au niveau du contenu. J'ai toutefois récemment réalisé un gros code refactoring. Ceux qui s'y connaissent en C++ vont sans doute se régaler en regardant le nouveau code du pattern Commande intégré à heftyAD... En gros, pour les néophytes, c'est ce pattern qui permet à l'utilisateur de pouvoir annuler ou refaire des actions au sein de l'application. Comme quoi les différentes applications qui intègrent cette fonctionnalité ne font pas de la magie (Ctrl+Z, Ctrl+Y, Ctrl+Maj+Z, ...).
Pour ce qui est du contrôle du flux de l'exécution d'un algorithme, tout fonctionne très bien et le système est d'ailleurs très souple. Par contre, je galère un peu en ce qui concerne la possibilité pour l'utilisateur d'avancer ou reculer vers une itération souhaitée. Voici les différentes actions applicables à un algorithme lorsque celui-ci s'exécute (regarder la barre avec les boutons Play et tout).
En d'autrs termes, heftyAD permet de contrôler le flux d'exécution d'un algorithme (dont il ne dispose pas du code source) au même titre qu'un lecteur mp3 pour un flux audio. Isn't that nice? Pour l'instant toutes les actions sont réalisables et ne dépendent pas de l'algorithme que l'on exécute. Mais seul le Next et le Prev me donnent un peu de fil à retordre (car un algorithme peut être mis en pause à n'importe quel moment, pas seulement en dehors d'une itération). Mais j'ai une idée qui devrait fonctionner une fois que j'aurais réglé les détails ci-après.
En effet, pour l'instant, on ne peut pas réaliser des animations au sein de l'application. C'est donc ce que je suis en train de corriger. Ainsi, pendant l'exécution de l'algorithme du tris d'un tableau par exemple, on pourra montrer le changement du contenu de deux cases en réalisant une animation.
Aussi, je vais améliorer le rendu des graphes et rendre ceux-ci plus proches de la réalité. Il sera possible de réaliser quelque chose comme ceci (faites "Ctrl+F", rechercher "this other one" et passez le curseur de la souris dessus). Le résultat est assez élégant je trouve. Du coup, je vais faire ça en mieux dans heftyAD : on pourra créer son graphe et en plus indiquer ces images si on le souhaite.
A votre avis
Enfin, je voudrais avoir votre avis sur un point. En fait, comme vous le savez sans doute déjà, heftyAD permet de créer son algorithme et d'indiquer des directives (actuellement du texte) expliquant son fonctionnement. Quelqu'un souhaitant comprendre ledit algorithme pourra alors récupérer des explications déjà écrites puis les jouer dans l'application...
Mais étant donné que je vais porter l'application vers les plateformes Tablet & Mobile, je me rends compte que créer un algorithme UN MINIMUM COMPLIQUÉ sur téléphone portable par exemple ne serait pas forcément pratique. Du coup, je me demande s'il faut adapter le contenu de l'application à la résolution de l'écran. Ainsi, lorsque je suis un PC par exemple, hé bien j'aurais accès à toutes les fonctionnalités, alors que sur téléphone portable, j'aurais juste accès à l'essentiel pour pouvoir réviser mes algorithmes (optimisation de l'espace quoi). De plus, aviez-vous déjà vu des applications (outre les applications Web) dont le contenu s'adapte en fonction de la résolution de l'écran ?
Discord NaN. Mon site.
Discord NaN. Mon site.