oStorybook 4.10.4 on Linux Mint 18

1. When I tell oStorybook to open LibreOffice on a scene that doesn't already have a LibreOffice document associated with it, it creates a brand new (empty) document in the directory that contains the oStorybook project file, and then opens a second brand new (empty, unsaved) document in LibreOffice. The desired behavior would be to create the empty document in the proper directory (as it does) and then open *that* document.

It's possible that the above is a problem with LibreOffice rather than oStorybook...

2. After saving the new document, oStorybook does not reliably receive and store its name - and when it does store the name, it does not include the path. On reopening the document file with no path, the default location is the directory containing the oStorybook program. Desired behavior is: i) reliably receive the filename with path, ii) if the path is the same as the path to the project file then strip it and store just the filename, otherwise store the whole thing, and iii) if there's a filename without path, use the location of the project file as the default path.

3. Upon observing #2, if I click the button to link to an existing ODT file, the default location to look for that file is my home directory. Desired behavior, again, is that the default is the directory containing the project file.

------------------

Other suggestions:

a. A copy-scene function. It should give an opportunity to change at least one of: thread, chapter, scene#, and then copy everything about the scene with the specified changes. If I'm going to rewrite a big piece of a scene, I like to copy the current version to a different thread named "killed scenes". More than once I've salvaged several paragraphs from a scene I killed some days earlier.

b. In chronological view, could the minimum size of the block for displaying the text of the scene be reduced to near zero? When using LibreOffice, quite a lot of scenes have no text for that block; otherwise, there are a number of uses for a "scene" that is just a historical marker, with a date and title and (usually) either no text or very little text.

It would also be nice to be able to shrink that block even on scenes that do have large amounts of text, but that would probably be rather more work.

c. It would be nice if the character, location, and item lists had notations for which of their various entries have relationship, tag, and item assignments, possibly with buttons to bring up those assignments. Because of the lack of this information at the points where it's most needed, I'm basically not using those assignments (or items), instead using character attributes.

d. Sort things better for dropdowns. When creating or editing an assignment, the character dropdown is apparently in ID order, which is not very helpful with nearly 50 characters (so far). It would be nice if the dropdown list were either (preferred) grouped and then alphabetical like the character tab on the scene-editing window, or (acceptable) alphabetical by abbreviation or last+first name.

e. This one is more work: The ability to have several books in one file, each consisting of designated threads, and have various operations specify which book (or have an overall setting for which book to apply those operations to). Sometimes a project is a series of related books with a lot of background information in common and with some books containing background information for other books. (I favor using threads for this because that way books can cover overlapping date ranges, have duplicate chapter names, etc. However something else might work better.)

I see that one can group chapters into parts, but so far I haven't found where doing so changes the behavior of anything, or one can choose to do something with only certain parts.

While looking for that, I also spotted the "copy elements" operation and have a few suggestions for that: (a) offer a "select all" box with the list of elements of a given type, and (b) provide operations to copy strands and scenes.

And while playing with that, I found a a couple odd behaviors that occur if there are two projects open and one of the projects has a dialog box open: (i) the other project is pretty much frozen; and (ii) with both projects minimized, clicking on the taskbar button for either one will bring up the one with the open dialog, and for a while there will be some confusion about which button goes with which project (the latter part might be a problem with the Linux Mint 18/Cinnamon environment).

As I improved the export function, I'll make the imprt one. By this way I think I'll rewrite the copy/paste function. I note the suggestion for "select all".