Discussion:TeXswitcher

De Troulite
Aller à : Navigation, rechercher

Sommaire

Forme du document

Shivien (Bug du parser): Dans l'article tu as précisé que le document LaTeX devait être de la forme (entête)(partie)* mais dans les keywords de ton parseur si je me souviens bien (car il n'est plus a l'addresse essi/cremasch/c++) il n'y avait pas les keywords \begin et \end qui sont notamment utilisé pour \begin{document} et \end{document}, le \end{document} ne devant pas être prit dans une partie LaTeX il faudrait donc un document de la forme (entête)(partie)*(fin).
Xavier_OM (Bug corrigé): En effet il vaut mieux isoler l'entête et la queue du document, actuellement le \end{document} fait partie du dernier block parsé (ce qui n'a pas de sens). La sauvegarde du "header" et du "footer" ne sert qu'à pouvoir reproduire un document LaTeX complet et compilable, mais le vrai rôle de teXswitcher c'est de bosser avec le corps du document.


Xavier_OM (Que faire des commentaires précédant immédiatement un block ?): Un truc auquel je viens de penser en documentant mes méthodes C++ : on peut imaginer écrire des commentaires avant une section, qui résument rapidement ce que cette section fait... après réorganisation, les commentaires se retrouveront ailleurs, précédant une autre partie. Ce qui faudrait faire :
  • savoir si cette pratique est courante (j'y ai pensé en codant, mais un rédacteur ne commente peut-être pas une partie juste avant d'écrire le titre, titre qui souvent doit lui rappeler le contenu)
  • décider comment on traite ce cas :
    • les commentaires font partie du brol (mais comment distinguer les derniers commentaires d'une section des "commentaires d'entetes" de la suivante
    • on se contente d'un WARNING dans la documentation ou dans le programme.

Interface graphique

JG : Une GUI en GTK je sais pas combien pour Gnome, parce que Gnome c'est bien.
Xavier_OM : si t'es motivé pour un portage C#/GTK# on aura une version GTK et multiplateforme sans recompiler :P
Xavier_OM (Keyword++ et Keyword--): Je propose des boutons pour monter en grade ou dégrader les keywords. Au début j'avais permis l'édition de la case, mais vu qu'on ne peut accepter comme entrée que l'un des keywords, autant ne pas faire écrire l'utilisateur...
Xavier_OM (CTRL pour qu'une action porte sur tout le sous-arbre): On veut qu'une action (drag & drop ou modification du keyword) porte soit uniquement sur l'item séléctionné, soit sur l'item et son sous-arbre (exemple : la montée en grade). Pour cela on pourrait cocher une checkbox ou appuyer sur la touche CTRL. Je préfère la deuxième solution car sinon on risque de passer son temps à cocher/décocher, c'est énervant et cela rendrait l'utilisation beaucoup moins fluide.

Actions possibles

Xavier_OM : Il faut lister les cas possibles de déplacement de blocks. Je commence la liste, merci de m'aider à la compléter (écrivez vos commentaires à la suite de celui-ci mais avant la liste).
NB : a sous B veut dire qu'on place un block a (un trouffion) sous un block B (un gradé). Par exemple on place une subsection (a) sous une section (B).
  • Déplacement d'item :
    • a sous B : on ne change rien au sous-arbre de a, la hiérarchie est respectée. Il faut résoudre le problème de la représentation graphique, si on place une subsubsection sous un chapter, faut-il obliger l'utilisateur à développer des branches vides, ou place-t-on la subsubsection au même niveau que tous les fils du chapter ?
    • A sous b : comment modifier le sous-arbre de B en conséquence pour que le document soit correct ? Il faudrait dégrader B et son sous-arbre, mais on ne pourra dégrader les subsubsection (trouffions de base).
    • A sous B ou a sous b : on peut soit rendre l'opération impossible, soit l'accepter en dégradant A, ou a, et son sous-arbre.
  • Changement de keyword (avec ou sans répercussion sur le sous-arbre) :
    • a devient A : aucun problème pour le sous arbre qui peut soit être promu lui-aussi, soit ne pas bouger. Par contre il faut vérifier qu'on reste moins gradé que le noeud immédiatement supérieur.
    • A devient a : aucun problème pour le parent, mais il faut dégrader le sous-arbre de manière cohérente (problème des subsubsection, non dégradable)
    • A devient A ou a devient a : c'est con.

Fitioures pour la version 0.2

Xavier_OM :
  • édition du titre d'une partie ?
  • autoriser le drag&drop d'un item seul (sans le sous-arbre qui suit le mouvement)
  • autoriser le drop d'un item ENTRE deux autres items (pour réorganiser).
  • raccourcis pour développer tout l'arbre.
  • utiliser un parseur créé avec lex pour éviter les cas tel que : "% \section{".
Xavier_OM :
Quels raccourcis utiliser pour développer tout l'arbre ?
AK :
/ et * pour développer tout l'arbre, -> et <- pour développer tout le sous-arbre.
Shivien :
/ et * pour développer tout l'arbre, + et - pour développer tout le sous-arbre et -> et <- pour développer uniquement le dessous du noeud actuel.
Shivien :
Gérer un historique des modifications pour permettre des undo et des redo.
AK :
considérer les paragraph et subparagraph comme des keywords valides


Idées pour d'autres applications de teXswitcher

On peut remplacer le jeu de keyword par un autre très facilement, et donc gérer d'autres types de documents hiérarchisés... Si vous avez des idées, c'est ici qu'il faut les écrire.

Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Outils