Bonjour,
J'avance dans l'exploration du logiciel, en même temps qu'un vieux projet est en train de reprendre vie grâce aux multiples outils qu'il met à notre disposition, notamment pour structurer l'écrit. C'est très précieux, et mille merci pour cela.
En avançant, donc, j'ai relevé quelques points (sans doute pas exhaustifs), dont certains relèvent semble-t-il de bugs, d'autres de pistes d'amélioration (suggestions forcément subjectives).

• Les "bugs":

1. À la création d'un lieu, la rubrique "Ville", même si elle est renseignée, fait l'objet d'un enregistrement vide. Comme la rubrique Pays en est, semble-t-il, dépendante, elle devient vide à son tour (en ouvrant de nouveau la fiche "Lieu", dans les champs déroulant correspondant, on a bien la trace d' enregistrements vide). Je suis parvenu à contourner le problème en utilisant la fonction de renommage: Outils -> Renommer -> renommer ville: je sélectionne l'entrée vide, et je la renomme. Cette fois, l'enregistrement est bien pris en compte et s'affiche normalement. je peux alors choisir le Pays qui va lui aussi s'afficher.
2. À la création d'une scène, ce qui est saisi dans le champ "heure" n'est pas enregistré, quel que soit le mode de saisie (à la main ou par défilement des flèches incrémentales). L'heure reste toujours à 00:00:00.
3. Numérotation des scènes: si j'ai créé 2 chapitres, dont le premier comporte n scènes, lorsque je crée la première scène du chapitre 2, elle sera numérotée 2.n+1, la suivante 2.n+2, etc., au lieu de, comme on pourrait s'y attendre, 2.1, 2.2, etc. Cependant, si je déplace une de ces scènes dans la vue "Gérer les chapitres et les scènes", la numérotation change, et devient effectivement 2.1, 2.2, etc.
4. L'affichage du résumé/texte d'une scène dans la vue chrono: pb d'encodage et/ou de conversion du texte en html: les caractères accentués sont remplacés par leur valeur unicode et le texte qui suit est mis en gras et en gros. Contournement: copier le texte et le recoller entre balises  (onglet html). L'affichage et alors correct, mais cette solution est volatile: à la prochaine intervention sur la fiche "scène", on revient à la case départ...
5. Dans l'assistant personnage, si je veux l'utiliser une seconde fois pour compléter une information, toutes les informations précédemment saisies disparaissent.
   

• Suggestions:

1. Un correcteur orthographique dans les champs résumé, notes, etc...
2. Pour l'éditeur externe: lorsqu'on choisit l'option "créer le document", pouvoir avoir le choix du nommage de ce document: soit par numérotation de la scène auquel le document est rattaché (comme c'est actuellement le cas), soit par son titre.
3. Pouvoir préciser la nationalité des personnages. Dans l'assistant, ajouter "cheveux gris" (et peut-être rouges, bleus, verts, par les temps qui courent...) et "chauve".
   
4. Dans la vue "gérer les chapitres et les scènes", supprimer le "blink" rouge sur la scène sélectionnée (distrayant et répétitif...)
5. Dans la vue "Relations", pouvoir afficher le nom de la relation (et pas seulement sa description). À ce propos, je n'ai pas compris l'utilisation des rubriques "1er personnage", "second personnage", n'ayant pas trouvé l'endroit où je pourrais les renseigner...

Voilà, je m'en tiens là pour aujourd'hui, je vais surveiller la page de téléchargement (après Dimanche, donc) pour y découvrir les nouveautés de la prochaine mouture.
Très bon WE

Philippe
Debian Buster
oStorybook 5.05.3
java-11-openjdk-amd64

Comme j'ai changé la manière de gérer les propriétés, j'ai laissé la chose dans un état instable pour ce qui est de l'éditeur externe. C'est corrigé. Il est possible que le cas 1 soit lui aussi lié à ça, mais ce n'est pas certain.

 Merci de cette réponse. Ce que je ne parviens toujours pas à comprendre, c'est comment, sur une même machine, 3 instances du même logiciel se comportent de 3 manières différentes...
Je vais installer la version de ce soir (enfin ce matin pour vous ), et voir ce qu'il en est.
Bonne journée,

Philippe
Debian Buster
oStorybook 5.05.3
java-8-openjdk-amd64

 Bon, voilà, c'est installé. Pour le cas n°3 (pb éditeur externe), en effet, c'est réglé, merci.
En revanche, pour le cas n°1 (plus de modification ni de création de scène possible, plus d'onglets en bas de l'éditeur), c'est toujours pareil. Je penche pour une corruption de la Bdd. Comment peut-on y remédier (j'ai déjà tenté le "optimiser la base"). J'ai vu qu'on pouvait obtenir un dump sql par la commande export, mais la commande import ne le "voit" pas (donc même si je parvenais à le corriger "à la main" en mode texte, je ne saurais pas quoi en faire ensuite...).

Philippe
Debian Buster
oStorybook 5.05.3
java-8-openjdk-amd64

 Au moins un problème de réglé.
Pour le cas 1 je peux tester votre fichier, me l'envoyer à l'adresse de contact. Sinon, voici quelques détails techniques qui peuvent vous intéresser. Le moteur de BDD est h2database (fair eune recherche sur ce mot clé). Le fichier "osbk" n'est rien d'autre qu'un "dump" de la BDD, comme vous dites, qui est ziper. Ce principe a été adopté pour permettre à l'utilisateur de rester totalement maître de ses données. Le "dump" en question est en fait une méta transaction SQL qui permettrait de réinjecter les données dans n'importe quelle BDD compatible SQL. Donc, si vous connaissez bien SQL vous pouvez tout à fait "travailler" sur le fichier une fois décompressé. Ceci étant je préférerais avoir votre fichier pour essayer de mettre en place une solution efficace ne nécessitant aucun bidouillage de la part de l'utilisateur.

 Je vais donc envoyer le fichier en MP. L'idée de mettre les mains dans le cambouis ne rebute pas a priori, mais au-delà de la connaissance de sql, il y a celle de l'architecture globale de la base que vous maîtrisez, et pas moi j'y passerais sans doute du temps, et ce serait sans doute en effet risqué. Je garderai donc ça pour mes moments de loisir (sur une copie ).

Philippe
Debian Buster
oStorybook 5.05.3
java-8-openjdk-amd64

Bonjour,

Voici mes déductions :

Lors de vos tests vous avez voulu voir ce que le mode scénario donnait, ainsi certainement que le Markdown. La conversion du mode HTML, le mode normal, vers le mode Markdown n’est pas disponible, du coup le résultat devient ingérable. C’est vrai que je devrais le signaler et empêcher ce genre de transformation. C’est ce que je vais faire de ce pas. Et pour aller plus loin je vais ajouter la conversion qui permettra de passer d’un mode à l’autre, avec des pertes de mise en forme puisque le mode HTML est bien plus riche que le mode Markdown.

En attendant il vous suffit de décocher les cases Scénario et Markdown pour retrouver un fonctionnement normal. Pour tester le mode scénario créez un nouveau fichier.

Je n’avais pas imaginé qu’un utilisateur veuille changer le mode, c’est une erreur de ma part.

Merci pour le suivi et les réponses.
Modifications effectuées, tout rentre dans l'ordre.
J'ai en effet, au cours de diverses tentatives, "cliqué un peu sur tout ce qui bouge", et je n'avais pas imaginé que ça puisse avoir ce genre de conséquences...
Peut-être rendre inactive la case à cocher permettant le changement de mode, après que le choix initial ait été fait à la création du fichier?

Philippe
Debian Buster
oStorybook 5.05.3
java-8-openjdk-amd64

Citation :

rendre inactive la case à cocher

 C'est ce que j'ai fait pour cette version. La suivante, déjà en chantier, permettra de modifier le type de saisie avec transformation à l'appui. En revanche il ne sera pas possible de décocher le mode scénario.