Voila quelques jours que je n’ai pas écris. Je voulais attendre d’avoir finis la tache sur laquelle je travaillais pour vous tenir au courant de l’avancement.
J’ai donc résolues quelques petits undo/redo : la rotation d’une image, le passage entre les mode : échelle réel et adapté à la taille de la frame, (donc les changements de résolutions de l’image) et pour finir, le undo/redo pour le changement d’échelle des flèches aux extrémité des lignes. Jusque là, tout ce qu’il y a de plus normal même si des fois, ça fait bien réfléchir pour comprendre pourquoi quelque chose qui semble bon en théorie ne l’est pas en pratique. J’ai donc fait ceci en une demi journée environ.
La majeur parties du temps restant depuis jeudi dernier, j’ai donc travaillé sur le undo/redo pour les gradients. Depuis le début de mon travail sur scribus, c’est le patch qui m’a demandé le plus de temps et qui était aussi le plus pénible à faire. La pénibilité viens du fait qu’il m’a demandé de mettre en place de nombreux undo/redo élémentaire donc pour une seul variables. Cela n’a rien de bien compliqué mais il faut créer des getters/setters, une fonction de undo/redo et faire en sorte que celui ci soit appelé et que le changement de variables se fasse bien avec les setters. Vous me direz, c’est un peu ce que je fais déjà depuis le début. Mais cette fois, j’ai du le faire de cette façon pour 42 variables différentes juste pour les gradients. Impossible de faire cela automatiquement puisque les méthodes appelées change de nom entre les fonction vu que la variables change et que le type change. Il est peut être possible de faire cela avec des commande préprocesseur mais comme je l’ai dis dans un autre article, je trouve cela pas très pratique étant donné que le code de scribus est très peut commenté, j’aime bien pouvoir trouver les fonctions à l’aide d’un grep -nri .
Heureusement, il n’y avait pas que cela a faire. Même si c’est pénible, ce n’est pas ce qui m’a pris tout se temps. Dans les gradients, certains ne fonctionnent qu’en interaction avec le canvas (zone d’affichage). Il m’a donc fallut ajouter un undo pour les actions de dragage de points. Ici aussi, un très grand nombre de variables sont en jeu et la plupart sont des variables de meshpoints. J’ai donc dans un premier temps ajouter les meshpoint dans les undoObject pour pouvoir faire une restauration directement sur ce genre d’objet. Malheureusement, je me suis rendu compte qu’en procédant de cette façon, le undo est enregistré à chaque déplacement d’un point, ou plutôt pendant son déplacement. Donc si on fait traversé tout l’écran au point, on remplie entièrement la pile de undo. Ce n’est donc pas envisageable. Le problème est donc : comment regrouper toutes ces actions en une seul. J’ai pensé à créer un UndoTransaction (qui est l’objet utilisé pour regroupé des actions dans un cas normal) déclaré en global ou en attribue du canvas. Ce n’est pas très jolie. Finalement, j’ai choisie d’enregistré la valeur du meshPoint sur lequel on viens de cliquer et lorsque l’on relâche le clic, on enregistre le points de départ et le points d’arrivé pour crée le undo. Il se trouve que c’est plutôt efficace même si du coup, les modifications pour ajouter des undo sur les meshpoints se trouve inutile. J’ai donc supprimé ces modifications. Il existe un deuxième type de canvas du même genre pour les gradients que j’ai donc traité exactement de la même façon. Pour que tout fonctionne correctement, il faut aussi ne pas prendre en compte cette action si aucun mouvement n’a lieux. Car pour changer la couleur du points par exemple, il faut le sélectionner. Il serait dommage de créer une action supplémentaire inutile. Un autre problème : le changement de mode du canvas. Lorsque le passait sur les gradient mesh. Il y a un changement de mode qui ne reviens pas avec le undo. Scribus finis donc par buguer. J’ai essayé toute sorte de chose sans succès. Finalement, ce n’est pas très beau mais j’ai ajouter un undo au changement de mode mais seulement pour certains mode. Après cela il faut passé par une petite étape de débogage. On fait pas autant de copié coller sans se trompé dans les modifications à apporter. Souvent les erreurs sont minim donc encore plus dure à trouver.
Ouf, me voila content tout semble fonctionner correctement. Pour l’instant mes tests se sont porté sur l’intérieur des polygones. Pour les bordures, je me suis donc rendu compte qu’il manquait une fonction de mise à jour du panel. Ce qui empêchait de faire un undo/redo correct et en réalité, cela apportait aussi des erreur lors des changements de sélection. j’ai donc ajouté cette fonction et ajouter les undo/redo pour ces gradients de la même façon que ce que j’avais fait précédemment.
Ouf. Finis...
C’est ce que je me suis dis. Malheureusement, il reste un petit onglets permettant de bouger le vecteur de gradients. J’ai donc commencer par le undo/redo qui suivait l’apparition de ce panneau. Encore une fois, cela demande un grand nombre de setter/getter mais finalement ça se fait. J’ai donc pris toutes les fonctions de ce panneau un par un pour les ajouter.
Ensuite, le canvas encore une fois. J’ai encore procédé comme précédemment. La différence étant : la dernier fois je pouvais sauvegarder un meshpoint. Cette fois, je dois sauvegarder individuellement une trentaine de variables pour les prendre en compte dans un undo final. Ce n’est vraiment pas jolie mais je ne vois pas comment traiter cela autrement. Avec une autre idée, je l’aurai sûrement appliqué également pour les premiers canvas.
Pfiou. Voila que les gradients sont finis !!! Et j’en suis bien content. C’est le plus gros patch que j’ai fais en nombre de ligne ...
Malheureusement, je sais qu’il me reste les gradients se trouvant dans l’onglet transparency du PP... Travail de demain ???
Cette après midi, j’ai donc changé un peu et travaillé sur le bug reporté par cezaryece : correction du undo pour la suppression de lettre. Et oui, quand on supprime des lettres et qu’on les fait revenir, le style de ces lettres est perdu.
Pour corriger cela, il faut donc enregistrer le style courant du caractère et regrouper tout cela en une seul action. Jusque là, pas de souci. Le plus gros problème est pour regrouper les actions en une seul. Puisque je crée une action a chaque fois que le style change, il faut que les nouvelles actions puisse s’ajouter à ce undotransaction. J’ai galéré un moment pour créer une action pour une chaîne consécutive avec un même style. Après avoir galéré un moment, je me suis rendu compte que c’était impossible car on ne sait jamais si ce qu’on vient de supprimé se trouve avant la chaîne ou après la chaîne. Mais après réflexion, cela importe peu. Seul l’état courant compte et peut importe ce qui est déjà supprimé. Je me content donc de regarder si le dernier mot supprimé est du même style. Si c’est ça, j’ajoute la lettre, sinon je crée une action. Et maintenant tout fonctionne.
Il ne reste plus qu’a commiter tout ça maintenant :-)
Bonne nuit à tous.