Aide pour une =?iso-8859-1?q?strat=E9gie_de_programmation=2E?=
28 réponses
bloiiing
Bonjour à toutes et à tous,
Je poste ce message car j'ai besoin d'aide pour définir une stratégie de programmation dans le cadre d'un programme que j'aimerais mettre au point en Java. Je précise que ce programme existe déjà dans un autre langage, le C++. C'est un logiciel libre sous license GNU, on peut donc l'adapter comme l'on veut.
Le logiciel en question s'appelle Plume Creator. Il sert à aider l'utilisateur à structurer ses idées pour en faire un livre, un article de presse ou de blog, un manuel d'utilisation, etc... Bref, c'est un logiciel qui sert à produire des textes. Son concept est excellent, c'est pourquoi je voudrais le reprogrammer en lui enlevant certaines options inutiles et éventuellement en en rajoutant d'autres.
La raison pour laquelle je voudrais porter ce programme de C++ à Java, c'est que le concept est en lui-même génial et fort bien pensé. Celui qui l'a écrit est lui-même écrivain, ça se devine. Mais la réalisation est inachevée et décevante à l'usage. Étant utilisateur de ce programme, je suis confronté à des pertes de données fort désagréables. Il est toujours décevant d'avoir perdu une ou deux heures de travail à cause d'un logiciel mal programmé...
Vous pouvez tester ce soft en le téléchargeant sur le site de l'auteur à http://plume-creator.eu/ . Sous Linux Ubuntu, il est installable depuis le centre d'installation des logiciels ( je ne sais pas comment ça s'appelle mais je pense que vous aurez compris ce de quoi je parle ).
Pourquoi en Java? Parceque c'est mon langage préféré et que je me sens capable de mener à bien ce projet dans ce langage.
Je voudrais dans un premier temps arriver à faire le minimum, c'est-à-dire un arbre à gauche avec l'arborescence du plan du document ( actes / chapitres que l'on doit pouvoir réordonner à volonté ), au milieu le texte proprement dit dans un JTextPane et à droite le synopsis et les notes de chaque chapitre chacun dans un JTextPane. J'aimerais de préférence arriver à faire ça sans pertes de données pour l'utilisateur. Ensuite, si je m'en suis sorti, je pourrais rajouter des options.
J'en viens donc à l'objet de ce message. J'aimerais avoir l'avis de programmeurs expérimentés en Java pour qu'on m'aide à définir une stratégie de programmation car je suis en train de m'embrouiller tout seul. J'ai des difficultés pour choisir une option de programmation.
J'ai utilisé des JTextPane pour les différents textes ( Notes, Synopsis et Corps du chapitre ). J'ai donc 3 JTextPane par chapitre. Est-ce que je dois les mettre dans un nouvel Object pour pouvoir les sauver en bloc et les restaurer à la demande? Est-ce que je peux mettre tous ces Object dans un Vector ( par exemple )? C'est le genre de questions que je me pose... Et avant de me lancer plus à fond j'aurais aimé qu'on me donne des idées pour réaliser ce programme ou du moins pour le démarrer. Je précise que je ne vais pas regarder comment ça a été programmé en C++ d'autant que je connais très mal ce langage. Je recommence de zero, from scratch... Le programme en lui-même est petit ce qui met sa réalisation à ma portée.
Je précise que le devellopement de Plume Creator s'est arëtté en 2013. C'est pourquoi je souhaite lui donner une seconde vie en Java.
Si vous avez des idées sur la façon de structurer et sauvegarder mes données, je suis preneur.
Il n'y a pas besoin d'avoir plusieurs JTextPane ouverts en même temps. Sauf pour représenter plusieurs informations (texte et notes d'un chapitre par exemple) ou si tu veux afficher plusieurs chapitres simultanément (j'ai l'impression que le logiciel d'origine fait ça, peut-être pour en garder plusieurs sous les yeux ?).
En fait, je préfererais garder l'ergonomie du logiciel d'origine sur ce point là. Il y a 1 JTextPane par Chapitre. Le passage des données dans la List<Chapter> se fera juste avant la sauvegarde dans un fichier.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
Le 19 Nov 2017 06:08:02 GMT
bloiiing <bloiiing.invalid@yahoo.com> a écrit :
Yliur wrote:
> Il n'y a pas besoin d'avoir plusieurs JTextPane ouverts en même
> temps. Sauf pour représenter plusieurs informations (texte et notes
> d'un chapitre par exemple) ou si tu veux afficher plusieurs
> chapitres simultanément (j'ai l'impression que le logiciel
> d'origine fait ça, peut-être pour en garder plusieurs sous les
> yeux ?).
En fait, je préfererais garder l'ergonomie du logiciel d'origine sur
ce point là. Il y a 1 JTextPane par Chapitre. Le passage des données
dans la List<Chapter> se fera juste avant la sauvegarde dans un
fichier.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le
logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque
chapitre ?
Il n'y a pas besoin d'avoir plusieurs JTextPane ouverts en même temps. Sauf pour représenter plusieurs informations (texte et notes d'un chapitre par exemple) ou si tu veux afficher plusieurs chapitres simultanément (j'ai l'impression que le logiciel d'origine fait ça, peut-être pour en garder plusieurs sous les yeux ?).
En fait, je préfererais garder l'ergonomie du logiciel d'origine sur ce point là. Il y a 1 JTextPane par Chapitre. Le passage des données dans la List<Chapter> se fera juste avant la sauvegarde dans un fichier.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
Yliur
Le Sun, 19 Nov 2017 10:13:14 +0100 Yliur a écrit :
Le 19 Nov 2017 06:08:02 GMT bloiiing a écrit :
Yliur wrote: > Il n'y a pas besoin d'avoir plusieurs JTextPane ouverts en même > temps. Sauf pour représenter plusieurs informations (texte et > notes d'un chapitre par exemple) ou si tu veux afficher plusieurs > chapitres simultanément (j'ai l'impression que le logiciel > d'origine fait ça, peut-être pour en garder plusieurs sous les > yeux ?). En fait, je préfererais garder l'ergonomie du logiciel d'origine sur ce point là. Il y a 1 JTextPane par Chapitre. Le passage des données dans la List<Chapter> se fera juste avant la sauvegarde dans un fichier.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
À mon avis il faut vraiment avoir éclairci ce point avant de commencer.
Le Sun, 19 Nov 2017 10:13:14 +0100
Yliur <yliur@free.fr> a écrit :
Le 19 Nov 2017 06:08:02 GMT
bloiiing <bloiiing.invalid@yahoo.com> a écrit :
> Yliur wrote:
>
> > Il n'y a pas besoin d'avoir plusieurs JTextPane ouverts en même
> > temps. Sauf pour représenter plusieurs informations (texte et
> > notes d'un chapitre par exemple) ou si tu veux afficher plusieurs
> > chapitres simultanément (j'ai l'impression que le logiciel
> > d'origine fait ça, peut-être pour en garder plusieurs sous les
> > yeux ?).
>
> En fait, je préfererais garder l'ergonomie du logiciel d'origine sur
> ce point là. Il y a 1 JTextPane par Chapitre. Le passage des données
> dans la List<Chapter> se fera juste avant la sauvegarde dans un
> fichier.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le
logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque
chapitre ?
À mon avis il faut vraiment avoir éclairci ce point avant de commencer.
Le Sun, 19 Nov 2017 10:13:14 +0100 Yliur a écrit :
Le 19 Nov 2017 06:08:02 GMT bloiiing a écrit :
Yliur wrote: > Il n'y a pas besoin d'avoir plusieurs JTextPane ouverts en même > temps. Sauf pour représenter plusieurs informations (texte et > notes d'un chapitre par exemple) ou si tu veux afficher plusieurs > chapitres simultanément (j'ai l'impression que le logiciel > d'origine fait ça, peut-être pour en garder plusieurs sous les > yeux ?). En fait, je préfererais garder l'ergonomie du logiciel d'origine sur ce point là. Il y a 1 JTextPane par Chapitre. Le passage des données dans la List<Chapter> se fera juste avant la sauvegarde dans un fichier.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
À mon avis il faut vraiment avoir éclairci ce point avant de commencer.
bloiiing
Yliur wrote:
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
Quand tu doublecliques sur un chapitre à gauche, ça t'ouvre un JTextPane ou un équivalent en C++. Quand tu doublecliques sur un autre chapitre, ça t'ouvre un nouveau JTextPane. Et ainsi de suite... Tu peux donc avoir plusieurs chapitres en cours d'édition en même temps. C'est très pratique de pouvoir passer de l'un à l'autre en clicquant juste sur l'onglet. C'est plus ergonomique.
Yliur wrote:
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le
logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque
chapitre ?
Quand tu doublecliques sur un chapitre à gauche, ça t'ouvre un JTextPane
ou un équivalent en C++. Quand tu doublecliques sur un autre chapitre,
ça t'ouvre un nouveau JTextPane. Et ainsi de suite...
Tu peux donc avoir plusieurs chapitres en cours d'édition en même temps.
C'est très pratique de pouvoir passer de l'un à l'autre en clicquant
juste sur l'onglet. C'est plus ergonomique.
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
Quand tu doublecliques sur un chapitre à gauche, ça t'ouvre un JTextPane ou un équivalent en C++. Quand tu doublecliques sur un autre chapitre, ça t'ouvre un nouveau JTextPane. Et ainsi de suite... Tu peux donc avoir plusieurs chapitres en cours d'édition en même temps. C'est très pratique de pouvoir passer de l'un à l'autre en clicquant juste sur l'onglet. C'est plus ergonomique.
bloiiing
Samuel DEVULDER wrote:
Le 19/11/2017 à 07:08, bloiiing a écrit :
Il faudra qu'il y ait une action de l'utilisateur pour que ça se fasse. Ça ne sera pas automatique comme dans le logiciel d'origine.
Quel est le problème avec la sauvegarde automatique ?
Le problème c'est quand tu fais une erreur de manipulation du style un Ctrl+x au lieu d'un Ctrl+c le logiciel te sauvegarde le texte erronné automatiquement. Je comprends pourquoi le logiciel original fait cette sauvegarde. Ça lui permet de faire des traitements sur les textes qui sont toujours à jour. Moi je préfère que ce soit l'utilisateur qui décide de sauver son texte ou non, avec un message de rappel en cas de fermeture d'un onglet ou du logiciel.
Samuel DEVULDER wrote:
Le 19/11/2017 à 07:08, bloiiing a écrit :
Il
faudra qu'il y ait une action de l'utilisateur pour que ça se fasse. Ça
ne sera pas automatique comme dans le logiciel d'origine.
Quel est le problème avec la sauvegarde automatique ?
Le problème c'est quand tu fais une erreur de manipulation du style un
Ctrl+x au lieu d'un Ctrl+c le logiciel te sauvegarde le texte erronné
automatiquement. Je comprends pourquoi le logiciel original fait cette
sauvegarde. Ça lui permet de faire des traitements sur les textes qui
sont toujours à jour. Moi je préfère que ce soit l'utilisateur qui
décide de sauver son texte ou non, avec un message de rappel en cas de
fermeture d'un onglet ou du logiciel.
Il faudra qu'il y ait une action de l'utilisateur pour que ça se fasse. Ça ne sera pas automatique comme dans le logiciel d'origine.
Quel est le problème avec la sauvegarde automatique ?
Le problème c'est quand tu fais une erreur de manipulation du style un Ctrl+x au lieu d'un Ctrl+c le logiciel te sauvegarde le texte erronné automatiquement. Je comprends pourquoi le logiciel original fait cette sauvegarde. Ça lui permet de faire des traitements sur les textes qui sont toujours à jour. Moi je préfère que ce soit l'utilisateur qui décide de sauver son texte ou non, avec un message de rappel en cas de fermeture d'un onglet ou du logiciel.
Yliur
Le 19 Nov 2017 12:20:12 GMT bloiiing a écrit :
Yliur wrote:
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
Quand tu doublecliques sur un chapitre à gauche, ça t'ouvre un JTextPane ou un équivalent en C++. Quand tu doublecliques sur un autre chapitre, ça t'ouvre un nouveau JTextPane. Et ainsi de suite... Tu peux donc avoir plusieurs chapitres en cours d'édition en même temps. C'est très pratique de pouvoir passer de l'un à l'autre en clicquant juste sur l'onglet. C'est plus ergonomique.
Pour ça il suffit de les créer au fur et à mesure des besoins, pas qu'il y en ait un par chapitre existant (mais pas forcément affiché) dans l'application. Et que se passe-t-il si tu affiches deux fois le même chapitre ?
Le 19 Nov 2017 12:20:12 GMT
bloiiing <bloiiing.invalid@yahoo.com> a écrit :
Yliur wrote:
> C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le
> logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque
> chapitre ?
Quand tu doublecliques sur un chapitre à gauche, ça t'ouvre un
JTextPane ou un équivalent en C++. Quand tu doublecliques sur un
autre chapitre, ça t'ouvre un nouveau JTextPane. Et ainsi de suite...
Tu peux donc avoir plusieurs chapitres en cours d'édition en même
temps. C'est très pratique de pouvoir passer de l'un à l'autre en
clicquant juste sur l'onglet. C'est plus ergonomique.
Pour ça il suffit de les créer au fur et à mesure des besoins, pas
qu'il y en ait un par chapitre existant (mais pas forcément affiché)
dans l'application.
Et que se passe-t-il si tu affiches deux fois le même chapitre ?
C'est vraiment très bizarre, qu'est-ce qui te fait dire que dans le logiciel d'origine il y a un JTextPane (ou équivalent) pour chaque chapitre ?
Quand tu doublecliques sur un chapitre à gauche, ça t'ouvre un JTextPane ou un équivalent en C++. Quand tu doublecliques sur un autre chapitre, ça t'ouvre un nouveau JTextPane. Et ainsi de suite... Tu peux donc avoir plusieurs chapitres en cours d'édition en même temps. C'est très pratique de pouvoir passer de l'un à l'autre en clicquant juste sur l'onglet. C'est plus ergonomique.
Pour ça il suffit de les créer au fur et à mesure des besoins, pas qu'il y en ait un par chapitre existant (mais pas forcément affiché) dans l'application. Et que se passe-t-il si tu affiches deux fois le même chapitre ?
bloiiing
Yliur wrote:
Pour ça il suffit de les créer au fur et à mesure des besoins, pas qu'il y en ait un par chapitre existant (mais pas forcément affiché) dans l'application.
Oui c'est ce que je pensais. On est d'accord.
Et que se passe-t-il si tu affiches deux fois le même chapitre ?
Là, normalement, on ne devrait pas pouvoir afficher deux fois le même chapitre. C'est comme ça dans le logiciel d'origine et c'est normal.
Yliur wrote:
Pour ça il suffit de les créer au fur et à mesure des besoins, pas
qu'il y en ait un par chapitre existant (mais pas forcément affiché)
dans l'application.
Oui c'est ce que je pensais. On est d'accord.
Et que se passe-t-il si tu affiches deux fois le même chapitre ?
Là, normalement, on ne devrait pas pouvoir afficher deux fois le même
chapitre. C'est comme ça dans le logiciel d'origine et c'est normal.
Pour ça il suffit de les créer au fur et à mesure des besoins, pas qu'il y en ait un par chapitre existant (mais pas forcément affiché) dans l'application.
Oui c'est ce que je pensais. On est d'accord.
Et que se passe-t-il si tu affiches deux fois le même chapitre ?
Là, normalement, on ne devrait pas pouvoir afficher deux fois le même chapitre. C'est comme ça dans le logiciel d'origine et c'est normal.
Samuel DEVULDER
Le 19/11/2017 à 13:27, bloiiing a écrit :
Le problème c'est quand tu fais une erreur de manipulation du style un Ctrl+x au lieu d'un Ctrl+c le logiciel te sauvegarde le texte erronné automatiquement
Ben c'est pas grave. Tu as le Undo pour ca! Mieux même, tu as des sauvegardes incrémentales dans la plupart des traitements de textes pour qui sauvegardent aussi l'état des undo/redo dans les sauvegardes automatiques. Il est important dans tout outil d'authoring de prévoir la gestion d'undo/redo. Un outil qu'il n'a pas cela de nos jour ne sera pas jugé pratique.
Je comprends pourquoi le logiciel original fait cette sauvegarde. Ça lui permet de faire des traitements sur les textes qui sont toujours à jour. Moi je préfère que ce soit l'utilisateur qui décide de sauver son texte ou non, avec un message de rappel en cas de fermeture d'un onglet ou du logiciel.
Il peut aussi le faire par mesure de sécurité en cas de crash inopiné. D'ailleurs un logiciel qui fait de la sauvegarde automatique n'est pas obligé d'écraser le fichier source, mais peut faire une sauvegarde cachée à coté. Si ca plante, à la réouverture du fichier source il regarde s'il n'y a pas une copie de travaille sauvegardée à coté et propose alors soit de charger le fichier d'origine soit la copie de travail. Les stratégies de sauvegarde/récupération sont nombreuses, variables dans le temps et ne devraient pas être fixées des le début de la conception d'un logiciel. Un logiciel bien conçu doit pouvoir supporter toutes les stratégies de sauvegarde/récupération. a+ sam.
Le 19/11/2017 à 13:27, bloiiing a écrit :
Le problème c'est quand tu fais une erreur de manipulation du style un
Ctrl+x au lieu d'un Ctrl+c le logiciel te sauvegarde le texte erronné
automatiquement
Ben c'est pas grave. Tu as le Undo pour ca! Mieux même, tu as des
sauvegardes incrémentales dans la plupart des traitements de textes pour
qui sauvegardent aussi l'état des undo/redo dans les sauvegardes
automatiques. Il est important dans tout outil d'authoring de prévoir la
gestion d'undo/redo. Un outil qu'il n'a pas cela de nos jour ne sera pas
jugé pratique.
Je comprends pourquoi le logiciel original fait cette
sauvegarde. Ça lui permet de faire des traitements sur les textes qui
sont toujours à jour. Moi je préfère que ce soit l'utilisateur qui
décide de sauver son texte ou non, avec un message de rappel en cas de
fermeture d'un onglet ou du logiciel.
Il peut aussi le faire par mesure de sécurité en cas de crash inopiné.
D'ailleurs un logiciel qui fait de la sauvegarde automatique n'est pas
obligé d'écraser le fichier source, mais peut faire une sauvegarde
cachée à coté. Si ca plante, à la réouverture du fichier source il
regarde s'il n'y a pas une copie de travaille sauvegardée à coté et
propose alors soit de charger le fichier d'origine soit la copie de travail.
Les stratégies de sauvegarde/récupération sont nombreuses, variables
dans le temps et ne devraient pas être fixées des le début de la
conception d'un logiciel. Un logiciel bien conçu doit pouvoir supporter
toutes les stratégies de sauvegarde/récupération.
Le problème c'est quand tu fais une erreur de manipulation du style un Ctrl+x au lieu d'un Ctrl+c le logiciel te sauvegarde le texte erronné automatiquement
Ben c'est pas grave. Tu as le Undo pour ca! Mieux même, tu as des sauvegardes incrémentales dans la plupart des traitements de textes pour qui sauvegardent aussi l'état des undo/redo dans les sauvegardes automatiques. Il est important dans tout outil d'authoring de prévoir la gestion d'undo/redo. Un outil qu'il n'a pas cela de nos jour ne sera pas jugé pratique.
Je comprends pourquoi le logiciel original fait cette sauvegarde. Ça lui permet de faire des traitements sur les textes qui sont toujours à jour. Moi je préfère que ce soit l'utilisateur qui décide de sauver son texte ou non, avec un message de rappel en cas de fermeture d'un onglet ou du logiciel.
Il peut aussi le faire par mesure de sécurité en cas de crash inopiné. D'ailleurs un logiciel qui fait de la sauvegarde automatique n'est pas obligé d'écraser le fichier source, mais peut faire une sauvegarde cachée à coté. Si ca plante, à la réouverture du fichier source il regarde s'il n'y a pas une copie de travaille sauvegardée à coté et propose alors soit de charger le fichier d'origine soit la copie de travail. Les stratégies de sauvegarde/récupération sont nombreuses, variables dans le temps et ne devraient pas être fixées des le début de la conception d'un logiciel. Un logiciel bien conçu doit pouvoir supporter toutes les stratégies de sauvegarde/récupération. a+ sam.
bloiiing
Samuel DEVULDER wrote:
Ben c'est pas grave. Tu as le Undo pour ca! Mieux même, tu as des sauvegardes incrémentales dans la plupart des traitements de textes pour qui sauvegardent aussi l'état des undo/redo dans les sauvegardes automatiques. Il est important dans tout outil d'authoring de prévoir la gestion d'undo/redo. Un outil qu'il n'a pas cela de nos jour ne sera pas jugé pratique.
Oui, j'y avais pensé au undo/redo. Mais je pense que la première version de mon logiciel n'implémentera pas cette fonctionalité. Mais à terme je pense que je serais obigé d'en faire une ( Même si je ne sais pas encore comment faire ). Mais bon, on verra ça plus tard.
Il peut aussi le faire par mesure de sécurité en cas de crash inopiné. D'ailleurs un logiciel qui fait de la sauvegarde automatique n'est pas obligé d'écraser le fichier source, mais peut faire une sauvegarde cachée à coté. Si ca plante, à la réouverture du fichier source il regarde s'il n'y a pas une copie de travaille sauvegardée à coté et propose alors soit de charger le fichier d'origine soit la copie de travail.
Oui mais le logiciel dont il est question sauvegarde automatiquement sur le fichier de sauvegarde et non sur un autre fichier. Il y a bien un fichier .bak mais ça ne résouds rien. J'ai perdu des morceaux de textes entiers rien qu'en montant et descendant certains chapitres dans l'arborescence de gauche.
Samuel DEVULDER wrote:
Ben c'est pas grave. Tu as le Undo pour ca! Mieux même, tu as des
sauvegardes incrémentales dans la plupart des traitements de textes pour
qui sauvegardent aussi l'état des undo/redo dans les sauvegardes
automatiques. Il est important dans tout outil d'authoring de prévoir la
gestion d'undo/redo. Un outil qu'il n'a pas cela de nos jour ne sera pas
jugé pratique.
Oui, j'y avais pensé au undo/redo. Mais je pense que la première version
de mon logiciel n'implémentera pas cette fonctionalité. Mais à terme je
pense que je serais obigé d'en faire une ( Même si je ne sais pas encore
comment faire ). Mais bon, on verra ça plus tard.
Il peut aussi le faire par mesure de sécurité en cas de crash inopiné.
D'ailleurs un logiciel qui fait de la sauvegarde automatique n'est pas
obligé d'écraser le fichier source, mais peut faire une sauvegarde
cachée à coté. Si ca plante, à la réouverture du fichier source il
regarde s'il n'y a pas une copie de travaille sauvegardée à coté et
propose alors soit de charger le fichier d'origine soit la copie de travail.
Oui mais le logiciel dont il est question sauvegarde automatiquement sur
le fichier de sauvegarde et non sur un autre fichier. Il y a bien un
fichier .bak mais ça ne résouds rien. J'ai perdu des morceaux de textes
entiers rien qu'en montant et descendant certains chapitres dans
l'arborescence de gauche.
Ben c'est pas grave. Tu as le Undo pour ca! Mieux même, tu as des sauvegardes incrémentales dans la plupart des traitements de textes pour qui sauvegardent aussi l'état des undo/redo dans les sauvegardes automatiques. Il est important dans tout outil d'authoring de prévoir la gestion d'undo/redo. Un outil qu'il n'a pas cela de nos jour ne sera pas jugé pratique.
Oui, j'y avais pensé au undo/redo. Mais je pense que la première version de mon logiciel n'implémentera pas cette fonctionalité. Mais à terme je pense que je serais obigé d'en faire une ( Même si je ne sais pas encore comment faire ). Mais bon, on verra ça plus tard.
Il peut aussi le faire par mesure de sécurité en cas de crash inopiné. D'ailleurs un logiciel qui fait de la sauvegarde automatique n'est pas obligé d'écraser le fichier source, mais peut faire une sauvegarde cachée à coté. Si ca plante, à la réouverture du fichier source il regarde s'il n'y a pas une copie de travaille sauvegardée à coté et propose alors soit de charger le fichier d'origine soit la copie de travail.
Oui mais le logiciel dont il est question sauvegarde automatiquement sur le fichier de sauvegarde et non sur un autre fichier. Il y a bien un fichier .bak mais ça ne résouds rien. J'ai perdu des morceaux de textes entiers rien qu'en montant et descendant certains chapitres dans l'arborescence de gauche.
