#undo/redo

  • Hier, j’ai passé la journée à travailler sur la #création_de_page. En réalité, j’ai voulu commencer avec la création de gabarit. Il est assez perturbant de remarquer que la suppression est très bien prise en compte par le #undo/redo mais pas la création. En cherchant un peu, j’ai compris que la suppression est prise en compte car elle peut être traitée comme la suppression d’une simple page (ou le undo/redo existe déjà) alors que la création est un peu différente et rien n’existe à ce niveau là. J’ai d’abord cherché pendant une bonne partie de la matinée s’il n’était pas possible de changer la façon dont est créée une page pour l’adapter au gabarit. Finalement, ça m’avait l’air plus compliqué que de repartir de zéro. Cependant, je me retrouve une fois de plus confronté au problème de page que j’ai expliqué hier. C’est à dire, si on crée une page/gabarit, qu’on ajoute quelque chose puis que l’on défait les deux actions et les refait, la deuxième n’est plus pris en compte. Voyant à quel point ceci est important, je suis donc revenu sur le problème d’hier pour ensuite l’appliquer au cas des gabarits.
    Pour les simples pages, il m’a donc fallut revenir dans les fonctions gérant le undo/redo pour réparer ce problème.
    En gros, lorsque l’on crée le polygone, puis le défait, on enregistre que celui ci était sur telle page donc on enregistre aussi la page dans les actions. Ensuite, on supprime cette page. Pour que cela fonctionne encore, on crée un faux objet pour remplacer la page et on enregistre un id de cet objet pour pouvoir le retrouver. Ensuite, on remplace dans la liste des undo, la page par le nouvel objet à chaque fois qu’elle apparaît et lors du redo, on remplace de nouveau le faux objet par la nouvelle page créée. Plutôt astucieux mais apparemment, tous les objets n’étaient pas pris en compte. La liste des redo par exemple n’était pas affectée. Maintenant, le undo/redo pour la création d’une page est totalement opérationnel et donc l’import de page également. Je voulais attendre d’avoir fait de même avec la #création_de_gabarit, malheureusement, j’ai pour l’instant des erreurs inexpliquées. Je vais donc travailler dessus aujourd’hui en espérant que tout soit résolu très bientôt. Bonne journée :-)

  • Depuis ma reprise, j’ai refait une partie du travail perdu ce week-end. j’ai donc ajouté les trois #undo/redo sur les options. C’est assez surprenant de remarquer que ça avance très vite lorsque tout se passe tel qu’on le veut. Il m’a ici suffit de localiser où se trouvait la fonction gérant ces fonctionnalités, d’ajouter un groupement de l’action dans le cas d’une sélection multiple puis d’ajouter la valeur de l’option à une nouvelle tache undo/redo. Pour les trois options tout s’est donc bien déroulé. Pour la 4ème action, il semblerait que le bug n’existe plus puisque nous n’arrivons pas à reproduire le problème. Il a donc été mis de côté.
    Une fois ces taches faites, je me suis remis sur le undo que j’avais commencé avant la panne de mon ordinateur. L’#import de page. Il apparaît que le undo était en fait terminé. Ce qui n’est pas plus mal. Je suis en revanche tombé sur un problème de undo pour la création d’une page. Ce n’est donc pas directement lié à la liste de délivrables qui me sont attribués mais vu que je travaille sur le undo, ça serait vraiment super si on pouvait avoir un undo 100% fonctionnel à la fin de l’été. Sinon, j’aurais encore mes week-ends pour travailler dessus ^^.
    Le problème est lorsque l’on crée une page, puis un polygone, que l’on revient sur ces deux actions puis que l’on fait un redo sur ces deux actions, la deuxième action n’est pas prise en compte pour le redo.
    J’ai d’abord supposé que le problème venait de la création de la page. En effet, un polygone est lié à la page à laquelle il appartient. Ainsi lorsqu’elle est supprimée, c’est une autre qui est créée à la place lors du redo. Mais après quelques recherches, il se trouve que ce problème est pourtant traité. J’ai donc finis par remarquer que la fonction restore() qui est normalement appelée lors d’un undo ne l’est pas dans ce cas là. Je n’ai absolument aucune idée du pourquoi et il faudra donc regarder de plus près l’intérieur du fonctionnement du undo pour comprendre le problème. Puisque je ne suis pas en avance dans ma réalisation, je vais pour l’instant le noter de côté, réaliser les autres taches qui me sont directement associé et j’espère pouvoir corriger cela sur le temps qu’il pourrait me rester à la fin des GSoC. C’est partit maintenant pour la création de master page puis ce sera le tour du texte.

  • Pendant l’indisponibilité de mon pc, je n’ai bien sur pas avancé autant que je l’aurais voulu. Cependant, j’en ai profité pour faire une liste des #undo/redo inexistant ou fonctionnant mal. J’ai également réalisé un petit tutorial pour expliquer comment réaliser un undo/redo pour Scribus ci dessous. N’hésitez donc pas à aider à son développement :-)

    Qu’est ce qu’un undo/redo ?

    Comme leurs noms l’indiquent, un undo permet de revenir en arrière sur une action et le redo permet de refaire une action annulée précédement.

    Comment fonctionne un undo/redo ?

    Lorsque l’on effectue une action, notre programme mémorise les informations nécessaires pour défaire et refaire une telle action. Ces informations sont mises dans une pile ainsi, lorsque l’on appuie sur CTRL + Z, la dernière action est dépilée, les informations enregistrées permettent de supprimer la dernière action et à la place cette action est ajoutée à la pile des redo. Le fonctionnement du redo est identique à celui du undo.

    Comment est-ce mis en place à travers Scribus ?

    Bien sur, tout le système de gestion des undo/redo existe déjà. Pour mettre en place une telle action, la seule chose à faire est de dire quelles sont les informations dont on a besoin dans notre pile pour pouvoir revenir en arrière et effectuer de nouveau cette action. Puis il faut écrire la fonction appellée pour effectuer ces changements.

    Concrètement prenons l’exemple simple du verrouillage de guide :

    « void ScribusDoc::lockGuides(bool isLocked)
    {
    if (GuideLock == isLocked)
    return ;
    GuideLock = isLocked ;
    if (UndoManager::undoEnabled())
    {
    QString name ;
    if (isLocked)
    name = Um::LockGuides ;
    else
    name = Um::UnlockGuides ;
    SimpleState (star)ss = new SimpleState(name, »", Um::ILockGuides) ;
    ss->set("GUIDE_LOCK", isLocked) ;
    undoManager->action(this, ss) ;
    }
    }"

    Toute la partie relative au undo se trouve dans la condition : undoEnabled(). En effet, on ne veut pas prendre en compte ces informations si le undo est désactivé. Il faut savoir que le undo désactivé peut l’être par le programme et non par l’utilisateur. Lorsqu’on presse CTRL + Z, le undo est désactivé par scribus tant que l’action de retour n’est pas effectuée. Sinon, en faisant appelle à une fonction déjà existante pour revenir en arrière, on enregistrerait une nouvelle action de undo alors que ce n’est pas le but ici. Bref, il faut toujours encadrer ces informations dans une condition UndoManager::undoEnabled().

    Ensuite, on est ici dans un cas simple, c’est à dire un cas où les seules variables qu’on a besoin de stocker sont des int, float, boolean, ... des variables standards. Je vous parlerai des autres cas plus tard. Dans ces cas là, on peut utiliser un objet SimpleState pour stocker les informations. Ses trois parametres sont le nom (celui qui apparait à côté de undo lorsque l’on clic sur édition), sa description et une image correspondant à ce undo.
    Pour connaitre la liste des noms et des images déjà existants, il faut aller voir dans undomanager.cpp. On utilise ici Um: : au lieu de UndoManager: : mais les deux sont équivalents. Si vous souhaitez ajouter un nom ou une image à ceux disponibles, c’est donc dans undomanager.cpp et undomanager.h qu’il faut aller l’ajouter.
    Ensuite, pour ajouter une valeur à retenir, il suffit d’utiliser set() comme dans l’exemple précédent. Les arguments sont le nom que l’on donne à la variable et la valeur associée. Il faut avoir au moins une variable parmi celles entrées, qui soit unique pour savoir quelle est l’action qui est ciblée lors du undo. On trouve souvent dans le code :

    "ss->set("ACTION_NAME","action_name") ;"

    Simplement pour savoir le nom de l’action même si la valeur de la variable n’a aucune importance.

    Enfin, pour que l’action soit enregistrée :

    « undoManager->action(this, ss) ; »

    la première variable doit être l’objet ciblé par le undo (pas forcément this) et le deuxième argument est l’objet contenant toutes les autres informations.

    Cette fois, l’action est donc ajoutée à la pile de undo. Il faut ensuite la prendre en considération.
    Lorsqu’on demande un undo, la fonction appellée est la fonction restore se trouvant dans l’objet qu’on a passé en premier argument de undoManager->action(). Bien souvent la fonction restore() est déjà écrite (je n’ai pas encore eu l’occasion de voir un autre cas), en s’aidant des exemples au dessus, vous devriez avoir quelque chose du genre :

    " else if (ss->contains("UNGROUP"))
    restoreUngrouping(ss, isUndo) ;
    "
    Comme je vous l’ai dit, il faut avoir une variable unique dans notre simpleState pour pouvoir detecter quelle est l’action qu’on veut traiter. Cette variable est ici « UNGROUP ». Bien souvent, l’action à effectuer fait plus de deux lignes donc, pour ne pas surcharger la fonction restore(), on crée une fonction qui se charge du restore spécifique, ici restoreUngrouping().

    Voici un cas simple du restore spécifique :
    " if (isUndo)
    GuideLock = !ss->getBool("GUIDE_LOCK") ;
    else
    GuideLock = ss->getBool("GUIDE_LOCK") ;
    "
    Pour récupérer la variable, on utilise donc get() avec comme paramètre le nom de la variable. On peut utiliser également getInt, getBool, getFloat, ... puis on effectue les actions qu’on souhaite.
    On peut aussi voir qu’il y a deux types d’action. Celles dans le cas où isUndo est vrai et le cas où c’est faux. Cela permet juste de différencier le comportement de undo (isUndo = true) et de redo (isUndo = false)

    Vous savez maintenant faire un undo.

    Comment faire lorsque l’on doit se souvenir d’un objet et pas seulement d’un int/bool/float...?

    Un autre objet que simpleState existe dans un cas comme ça : ScItemState<Class>

    Exemple :
    « ScItemState<PageItem(star)> (star)is = new ScItemState<PageItem(star)>(Um::ChangeShapeType, »", Um::IBorder) ;"

    Il prend les mêmes arguments qu’un SimpleState mais on peut, en plus, lui donner le type d’un objet qu’on veut qu’il stocke. On ne peut donc stocker qu’un seul objet mais c’est mieux que pas du tout.
    Cet objet a une methode : setItem() qui permet de lui passer cet objet. On peut toujours utiliser la methode set() pour lui passer autant de int/float/string ... que l’on veut tant qu’il ne reçois qu’un objet. Pour passer cette restriction, il faudra donc utiliser des list ou des pair.

    De cette façon, on peut traiter une grande partie des undo/redo.

    Lorsque je fais mon action, j’ai plusieurs actions ajoutées à ma pile de undo.

    En effet, si on avait une action de déplacement décomposée en un déplacement vertical et un déplacement horizontal, lorsqu’on bougerait une forme, on aurait deux actions ajoutées à notre pile de undo. Et il faut donc enlever ces actions intermédiaires une par une pour avoir un undo complet (si la liste des actions intermédiaires n’a pas dépassé la taille maximum de la pile. Dans ce cas, on ne pourra pas revenir entièrement en arrière).
    Deux solutions s’offrent à nous dans un cas comme celui ci :
    Si en effectuant tous les undo intermédiaires, on atteint bien la position de départ, on peut regrouper toutes les actions en une seule de la façon suivante :
    « //démarrer le regroupement
    UndoTransaction(star) activeTransaction = new UndoTransaction(undoManager->beginTransaction(Um::Group + »/" + Um::Selection, Um::IGroup, Um::Delete, tooltip, Um::IDelete)) ;

    //finir le regroupement
    if (activeTransaction)
    {
    activeTransaction->commit() ;
    delete activeTransaction ;
    activeTransaction = NULL ;
    }
    "
    Tout ce qui est au milieu est regroupé en une seule action. Les arguments à entrer lors de la création d’une transaction sont : la cible de l’action (selection/page/...), l’image correspondante, le nom de l’action(celui qui apparait dans le programme), une description et l’image correspondante.
    L’autre possibilité, plutôt utilisé lorsque toutes les actions intermédiaires n’ont pas une action undo dédiée, c’est de supprimer de la liste toutes les actions intermédiaires en encadrant le code de :

    « undoManager->setUndoEnabled(false) ;
    //mon code
    undoManager->setUndoEnabled(true) ; »

    puis de créer une action à ajouter à la pile de undo qui permet de prendre en compte tous les changements liés à cette action.
    Il n’y a pas à se poser la question, « est ce que lors de l’appel de setUndoEnabled(false), le undo était déjà indisponible ? Parce que dans ce cas, setUndoEnabled(true) le rendrait disponible alors qu’il ne l’était pas normalement... ». Ceci est gérer tout seul par la fonction, il suffit de bien penser. Dés que j’utilise un setUndoEnabled(false), il faut bien utiliser setUndoEnabled(true) à la fin pour que tout soit remis dans l’ordre.
    En pratique, on peut utiliser les deux techniques citées précédemment de façon combinée. C’est-à-dire, si un undo est bien géré, on garde ce undo dans la liste et on ajoute seulement ceux qui sont mal gérés puis on regroupe toutes ces actions en une seule. C’est souvent le moyen que je trouve le plus efficace mais libre à vous de faire ce qui vous parrait le mieux.

    Je crois avoir fait un petit tour des différents fonctionnements du undo. Le plus dur maintenant est de trouver et comprendre les fonctions dans lesquelles il faut ajouter le undo et de corriger les bugs que l’ont peut découvrir en faisant des testes tordus.

  • Voila un moment que je n’ai pas donné état de mon avancement. Plusieurs contretemps m’ont empêché d’avancer comme je l’aurais voulu. Tout d’abord, j’étais en partiel pendant deux semaines (même si ce n’est pas le nombre d’heure de révision ou de partiels qui m’ont pris beaucoup de temps), mais surtout, le ventilateur de mon ordinateur a rendu l’âme. Ubuntu est plutôt gourmand en utilisation du processeur donc mon ordinateur surchauffait très très vite. A peine 15 minutes après son démarrage, j’étais dans l’obligation de l’éteindre sinon il s’éteignait tout seul. Ensuite, je me suis fait volé un ordinateur. Dans ces conditions, il est donc difficile d’avancer correctement. J’ai donc attendu patiemment mon retour en France pour faire une réparation. J’espère donc ne plus avoir de problème de ce genre par la suite.
    Au niveau de l’avancement , j’avais fait il y a un moment une toute petite modification pour que lors de la suppression d’un élément , si on effectue un undo, l’élément (ou le groupe d’élément) soit sélectionné par défaut. Cela permet d’avoir un meilleur workflow. Si on supprime sans faire exprès un élément puis qu’on le fait revenir, on peut continuer de travailler directement sur cet élément sans avoir à faire une resélection. Vu que c’est un changement mineur, je n’avais donc pas pris la peine de faire un article complet sur ce changement. Deuxième changement que j’aurais aimé finir mais j’ai malheureusement été interrompu par ce problème de ventilateur, l’ #importation de page.
    Lors de l’importation d’une page (sans insertion), les propriétés de la page sont chargées et appliquées mais ne sont pas remises correctement lors d’un undo. J’ai donc ajouté cette propriété. Malheureusement, cette partie de #undo/redo prend place dans les plugins de chargement de fichier. Il existe en réalité un plugin par version puisque le format des fichiers a évolué. Je n’ai implémenté ce changement que pour le chargement de la version 1.5 . Peut être que je regarderai pour les autres type de fichiers si on me fait remarquer que c’est important et qu’il y a des bugs à ce niveau là ou si j’ai suffisamment de temps pour faire ça par la suite. Malheureusement, l’indisponibilité de mon pc ne m’a pas encore permis de tester si cela crée des bugs lors de l’importation d’une page d’un fichier d’une version antérieur. Même si ceci ne devrait pas avoir lieu.
    Lors de l’implémentation de cette fonctionnalité, j’ai donc travaillé avec un fichier test que j’avais utilisé par le passé et, surprise, je pouvais observer un autre comportement étrange : une zone de texte qui apparaît dans la liste des undo mais qui ne peut être supprimé par celui ci. Après de multiples tests, j’ai donc compris que cet élément est verrouillé. Ainsi, il ne peut être supprimé même pas par un undo.
    Ce genre de bug ne se voit presque pas puisque normalement le verrouillage est appliqué, alors qu’ici, le verrouillage est créé en même temps que l’élément. En gros, dans le premier cas, si on crée un élément et qu’on applique un verrouillage, lors du undo, on enlève le verrouillage puis on enlève l’élément, ainsi tout se passe bien. Alors qu’ici, l’élément est créé avec le verrouillage, cette action n’apparaît donc pas dans la liste des actions undo et n’est donc pas enlevé avant de vouloir enlevé l’élément. Vous me suivez ? J’ai donc utilisé la fonction ayant déjà un undo pour appliquer le verrouillage et regrouper toutes les étapes d’import d’une page dans une seule action undo. Cela parait plus logique puisque cela ne correspond qu’à une seule action de l’utilisateur.
    Lors de l’arrêt de mon travail, je regardais l’importation de page avec insertion. Ce cas pose encore problème mais je n’ai donc pas encore pu le traiter. J’espère pouvoir me remettre au boulot le plus rapidement possible...

    • parfait !
      juste uner remarque : pourrais-tu compiler une liste de fonctionnalités que tu sais que tu n’as pas programmé ? à la fin du gsoc nous devrons décider quoi faire de cette liste...

  • Un petit peu d’avancement. Corriger et améliorer les actions #undo/redo, c’est aussi prendre en compte les bug reportés à ce sujet. Ici, j’ai donc traité un bug sur des modifications d’une figure importée depuis un fichier #EPS.
    C’est pour le moment la correction qui m’a demandé le plus de temps pour trouver la source du problème. En effet, même après avoir localisé la fonction où avait lieu ce problème, il m’a fallu descendre dans les fonctions pour localiser précisément le bug et apporter une correction.
    Je n’aime pas trop toucher aux fonctions de base de Scribus. Parce qu’elles sont de base justement, elles sont utilisées un peu partout et il m’est difficile de mesurer toutes les conséquences d’un tel changement. Mais bon, il arrive comme dans ce cas que l’on ait pas le choix.
    Pour être plus précis sur ce bug, il est ici question d’un plateau de Go que l’on veut redimensionner. Lorsqu’on le redimensionne puis qu’on annule le #redimensionnement, seul le quadrillage n’est pas redimensionné. J’ai donc fait des tests en dessinant des « lines » et il n’y a pourtant aucun problème de ce côté là. Ce n’est que par la suite que j’ai compris que les lignes utilisées pour les cases ne sont pas des « lines » mais des "polyline". Les polylines sont les objets utilisés pour tracer quelque chose à main levée par exemple. Pourtant, en traçant quelque chose à main levée, il n’y a pas de problème non plus à moins que tous mes points soient vraiment alignés. Finalement, je trouve que le problème viens du fait que j’ai un objet de largeur nul !!! En allant plus loin, vous pouvez voir que si vous tracez un polygone et que vous alignez tous les points, vous ne pourrez pas changer la dimension de la « ligne » ainsi créée. Le problème de fond est donc d’avoir des objets dont une des dimensions est nulle.
    Vous remarquerez qu’en partant d’un problème de undo/redo avec un fichier EPS, on se retrouve en réalité avec un problème dans le redimensionnement de n’importe quelle figure de taille nulle. Normalement, il est impossible d’avoir un objet de taille nulle. Si vous sélectionnez un objet et que vous mettez sa taille à 0 dans le panneau de propriété, celui ci reviendra directement à 1. Donc pour avoir une figure de taille nulle, il faut aligner manuellement tous les points de la figure.
    Il m’a donc fallu faire un choix. Soit je corrige le bug en traitant les cas de taille nulle dans le redimensionnement, soit je remonte à la source et je fais en sorte que la taille d’une figure ne puisse pas être nulle. Malheureusement, la taille est changée manuellement (et pas seulement à partir d’un setWidth) un peu partout dans le code. Changer cela obligerait à faire d’importante modification dans tout le code sans pouvoir en mesurer toutes les conséquences. C’est pour cela que j’ai opté pour un changement seulement dans le redimensionnement. Finalement, ces quelques lignes me permettent de finir la correction des problèmes de undo/redo liés aux figures qui étaient connus. Un nouveau sujet va pouvoir être commencé !!

  • 5 jours sans nouvelles, mais je suis encore là. Bien sur, je n’ai pas que Scribus à faire ce qui explique en partie ma pause mais aussi, je me suis confronté au #text_undo fait pas cezaryece que je dois exporter entre la version 1.4 et la version 1.5. Maintenant que j’ai vu ça de plus près, ça me parait beaucoup plus dur. Je ne m’attendais pas à ce qu’il y ait autant de différences entre les deux versions. Heureusement, JGhali m’a donné une piste pour commencer, ce que je ne tarderai pas à exploiter.
    Pour faire une petite pause dans ce travail, je me suis donc lancé dans l’opposé du patch précédent : le undo/redo pour la dissociation de polygone.
    Cette fois ci, l’approche est beaucoup plus simple puisqu’il suffit de d’appliquer les méthodes déjà existantes de combinaison pour le undo et de dissociation pour le redo. En effet, il n’y a pas de problème de perte d’information.
    En faisant différents tests, je me suis rendu compte qu’un mauvais #undo/redo pouvait causer assez rapidement des problèmes de segfault dans scribus. Ce qui ne fait pas souvent plaisir à l’utilisateur. En effet, le undo précédent est basé sur ce qu’il doit y avoir à la fin d’une action. Or si le undo suivant ne remet pas exactement comme c’était précédemment, certaines actions réalisées dans le undo ne sont plus possible. J’espère que je ne vous ai pas perdu avec ça ^^.
    Revenons au undo/redo sur lequel je travaille. Seul point restant à regarder : les données nécessaires pour effectuer les actions. La première idée à été de faire comme dans le patch précédent : sauvegarder les items utilisés. En faisant de cette façon, du premier coup d’œil tout se passe plutôt bien. Je joue un peu avec pour montrer comme ça marche bien à ma copine et bam... bug. J’ai d’autres polygones qui apparaissent si je fais undo/redo/undo/redo.
    Après réflexion, c’est logique puisque je sauvegarde un item mais que ceux ci sont recréés à chaque fois que je fais une dissociation de polygones. Donc la référence vers l’ancien item n’est plus bonne. Finalement, j’ai pu faire fonctionner ce undo/redo en utilisant la position des polygones dans la liste d’item puisque les objets créés ou supprimés le sont toujours au même endroit de la liste.
    Maintenant, il va falloir se remettre au texte undo... Plus de nouvelles bientôt...

  • Et voila un nouveau patch de fini.
    Il m’aura donc fallut toute l’après-midi pour en venir à bout. Finalement, j’ai opté pour deux actions dans le undo. La suppression des polygones (cette action est déjà gérée, autant en profiter) et différentes manipulations sur les différents #polygones. Vu que j’avais bien compris le fonctionnement pour le undo, il a été assez facile de le refaire dans cette nouvelle condition. Seul problème, lorsque je fais plusieurs #undo/redo à la suite, ça plante ... Vraiment pas très sympa comme comportement.
    Je regarde donc où est ce que ça plante (merci gdb) et je me rends compte que je n’ai pas le bon nombre de points dans mes polygones. En remontant petit à petit, je comprends qu’il y a des points ajoutés lors de la fusion et qu’il faut que je les supprime. Cette fois, le nombre de points est bon mais .. ça plante toujours.
    Il m’a malheureusement fallut un peu de temps pour me rendre compte que lors de la sélection des polygones à fusionner, je ne les sélectionnais pas dans le bon ordre, ça finissait par mélanger les points donc c’était pas génial.
    Cette fois, tout à l’air de fonctionner à merveille pour ce qui est de mon undo/redo en tout cas. Par contre, il reste un truc qui me dérange (et que j’ai repéré avant même de changer le code), si je combine au moins 3 polygones, que je fait un undo puis que je ferme le fichier, j’ai une erreur de segmentation à la fermeture. Ok, c’est juste à la fermeture mais n’empêche que c’est pas génial.
    Je vais donc voir où est l’erreur et apparemment, on fait des deletes sur chaque élément d’une liste mais plusieurs éléments sont identiques. Je commence donc par faire un petit hack pour ne pas faire de delete si l’élément est identique mais, une fois fini, je ne suis toujours pas satisfait. C’est bien, ça fonctionne mais il doit bien y avoir un souci derrière pour qu’il y ait plusieurs fois le même élément.
    Je retourne donc dans mon code et je me rends compte que c’est lors du undo de la suppression qu’il y a un problème. En effet, si je crée 5 polygones, que je les combine et que je fais un undo, je me retrouve avec 5 fois chacun des polygones dans la liste des items. Plutôt étrange comme comportement mais du coup, ça se rattache un peu à mon projet puisque c’est un bug de undo. C’est reparti pour corriger cette erreur.
    En lisant un peu le code, je trouve à un endroit : pour chaque élément à supprimer, mettre cette liste ainsi que l’id de l’élément sur la page. Pourquoi pas, mais on n’a pas l’id de l’élément dans la liste des éléments à supprimer (que j’ai donc ajouté par la suite). Ensuite, lors du redo, on recrée chaque élément de la liste et on les met à la position « id » sur la page. Oula, on recrée tous les éléments pour chaque élément. Il semble donc y avoir un problème. Bien sur, c’est pas souvent qu’on supprime plein d’éléments et qu’on joue avec le undo donc c’est possible que ça passe inaperçu mais il faut bien réparer ça quand même. Je supprime donc cette boucle pour recréer seulement l’élément défini par l’id. J’aurais bien aimé discuter de ça avec quelqu’un qui connaît mieux le code mais il est un peu tard donc personne n’est vraiment dispo. Peut-être plus tard. Quoi qu’il en soit, il y a maintenant un Undo/Redo opérationnel et amélioré pour la #combinaison_de_polygones.

    On m’annonce maintenant que mon dépôt git est disponible, je vais donc pouvoir commencer à uploader ces différents patchs pour ma version, youpiiiiiii :-)

  • Nouvelle étape, mise en place du #undo/redo pour l’#association_de_polygones. Je dis bien mise en place puisqu’il n’y a aucune trace de undo dans la fonction qui gère l’association.
    Comme toujours, je commence par quelques tests pour voir ce qui fonctionne ou ne fonctionne pas. Je remarque donc que les actions effectuées dans ce cas et qui n’ont aucun undo sont les « map » sur les « poline » et l’ajout de points pour le premier polygone ( qui représente le polygone fusionnés).
    À ce niveau là, deux choix s’offrent à moi. Soit j’ajoute un undo pour chacune de ces actions, soit j’applique « dissocier les polygones » au polygone résultant. Avec la deuxième solution, seuls les points ont été fusionnés dans le nouveau polygone. Si on attribue, par exemple, une couleur différente à chaque polygone, celles ci disparaissent en fusionnant mais ne reviennent pas en les dissociant. Le undo ne serait donc que partiel.
    Je commence donc avec l’autre solution. J’ajoute un undo pour les « poline.map » et un undo pour l’ajout de points à la forme finale. Je combine ça dans une seule action pour avoir en appuyant sur ctrl-z : recréer tous les polygones supprimés, supprimer tous les points ajoutés dans ma forme finale et restaurer les paramètres de départ, appliquer la transformation inverse à tous les polygones recréés.
    Jusque là, c’est parfait, j’ai un undo fonctionnel.
    Un autre problème se pause, je ne fait pas que un undo mais un undo/redo. Or le redo ne fonctionne pas.
    En effet, j’applique de nouveau mes « poline.map » mais je n’ajoute plus mes points pour les regrouper dans un seul polygone... Je pourrais simplement ré-appliquer « associer les polygones » mais je n’ai nul part dans mes undo enregistrés tous les polygones au même endroit et en ajoutant cette action, certaines autres actions enregistrées comme la suppression des polygones en trop ou l’application du poline.map se ferait deux fois. Décidément ce n’est pas la bonne solution.
    Je suis donc reparti pour créer plutôt une action spécifique pour l’association de polygones en utilisant autre chose qu’un simpleState pour enregistrer l’action.

    Plus de nouvelles bientôt

  • Ceux qui ne sont pas allés voir de plus près la candidature peuvent se demander ce qui va être fait durant ce projet. En réalité, il y a beaucoup de petites améliorations possibles qui, regroupées, amélioreraient grandement l’ergonomie de Scribus. Pendant tout cet été, je vais me concentrer sur ce qui est #Undo/redo (ctrl-z si ça vous parle plus).
    Bien sur, je pourrais me contenter de mettre sur ce blog ce qui est fait et comment c’est réalisé mais je pense que toute la démarche pour arriver à la mise en place du Undo/Redo correspondant est intéressant et je vous passe le temps de recherche dans le code.

    Je vais prendre ici l’exemple du premier Undo/redo sur lequel j’ai travaillé. En réalité, j’ai fait ça la semaine dernière, avant l’annonce officielle de Google.

    Lorsque l’on #crée_une_forme, on peut ensuite double cliquer dessus pour voir apparaître une fenêtre « Points ». Dans cette fenêtre, il y a ,entre autres, des boutons pour faire tourner ou redimensionner la forme. Malheureusement, le Undo ne marche pas très bien (Heureusement pour moi, ça me fait du boulot :-)).
    Pour faire le undo, il faut 4 étapes ce qui remplit la file de undo qui est limitée plutôt rapidement. Donc c’est pas bon.
    La première idée a donc été de regrouper toutes ces actions en une seule. Mais en faisant des tests, je me suis rendu compte que certaines actions enregistrées en undo étaient en trop puisque la forme n’était pas à la même place à la fin du undo. Retour à la case départ ...
    Pour comprendre un peu mieux, j’ai cherché qu’est ce qui créait les undo. Finalement, j’ai répertorié deux actions sur les « PoLine » et un « moveItem ». Ces actions étaient donc en trop.
    Pour corriger ça, j’ai encapsulé toute la fonction (jusqu’au undo créé spécialement pour cette action) en désactivant le undo et en l’activant à la fin. Cette fois, tout fonctionne. Mais je me dit : « le undo doit être activé pour que la suite fonctionne or, je l’active à tous les coups juste avant en mettant la valeur de undoEnable sur true ». J’essaie donc de sauvegarder la valeur de undo au début de la fonction puis de mettre la valeur du « undoEnable » sur cette valeur à la fin de la fonction. Cette fois, ça ne marche plus ...
    En cherchant un peu, je comprends que si on met la valeur de « undoEnable » deux fois sur false, il faut le mettre deux fois sur true pour qu’il soit de nouveau activé. Je peux donc revenir à ma solution précédente.
    Au final, ce changement m’aura pris quelques heures pour trois pauvres petites lignes. Ça m’a au moins permis de comprendre certains principes utilisés dans le undo pour la suite. Il fallait bien commencer quelque part et heureusement que celui ci était plutôt facile.
    Merci d’avoir lu et n’hésitez pas à me dire si certains passages vous parraissent un peu flou.