Feature request: fully Sepearate Character, Items, Locations, Project notes windows

[DarthNewton]

I think I may have made this request before...but I don't think it was
ever addressed:

It would be nice to have the Character, Items, Locations windows fully
separated. As it is right now the add/edit is locked to the main
Ywriter window (aka can't edit project notes when character editor is
open). And you can't have both Character and Items open at the same
time. I tend to work on several aspects of my story at once and shift
between characters the locations and back. Having truly separate
windows would speed that up considerably.

Yes I know I can access them via the scene editor but when the character
editor is brought up via the scene editor, again everything is "locked"
until I finish instead of a true separate window (aka I can't go ohhh
add this bit of dialog to that scene). Because of this I tend to bring
it up in the main Ywriter window so the scene editor doesn't become
locked. But then if I get a idea to put in the project notes I can't
until I am finished with the characters etc.

My mind tends to go in 100 different directions at once when writing and
I make notes and work on several aspects shifting quickly. If I don't I
make notes I forget them which is often a great idea that may never come
back. So as you can see having seperate windows would be a great help
to me. But if it is not possible I understand and will keep using
notepad for quick thoughts until I can orgainze them later (which I
would rather do in ywriter at the start).

Btw thank you again Simon for such a great piece of software (not
complaining here).

[David York]

This is an interesting general issue with programming. The idea of having a
dialogue box/window taking exclusive focus is to help either the program
from running into difficulties (eg from having two pending edits) or users
from getting into difficulties remembering where they are and saving changes
properly.

I don't have any problems with the way yWriter handles such issues. I have
a suspicion that I am not alone in this.

The nearest way to fake multiple open dialogues (which might save a few
clicks during a long session) is to keep within yWriter and open up dummy
scenes (all kept open) for editing characters, locations and items but
accept that the actual edit is going to lock things with a dialogue box.
Easier in multiple monitor setups. Not ideal for you but it keeps things
manageable for most.

If you really want to live on the edge - read 'Zen and the Art of Concurrent
Direct Editing of the yWriter Project File' and 'The Rough Guide to Putting
Right Error Arising After Reading Zen and the Art of Concurrent Direct
Editing of the yWriter Project File' :-)

If you want to ask Simon for some generally useful enhancements - how about
suggesting some simple reports of 'tags in use'? (Otherwise you have to
have a good memory or inspect the dialogue you get during print scenes (etc)
per tag - as they are displayed in the dialogue 'Pick Tags')?

--
You received this message because you are subscribed to the Google Groups
"yWriter" group.
To post to this group, send email to ywr...@googlegroups.com.
To unsubscribe from this group, send email to
ywriter+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/ywriter?hl=en.

[Dick Keaton]

I share Darth's desire (assuming I understand it correctly) to have
character, items, and location edit/dialogue windows visible while in
scene edit mode. To me this would be a valuable enhancement. I think
the ability to refer back and forth to all these items while in actual
scene composition mode would provide a productive assist to many
writers. I broached this subject with Simon sometime ago (at least a
year - maybe more). As I recall from my programming days, it is a
fairly basic matter of 'modal' vs. 'non-modal' dialogues. Although I
don't remember exactly what Simon's objections were, he had some
pretty solid reasons (as he always does) for not implementing this
feature. It may have been the time and effort involved or other
programmatic implications. I can't recall. Perhaps he could re-visit
this request or let us know why he chooses not to. Most importantly,
as already noted many time by many people, yWriter is a great tool
with or without this particular function, and we all owe a great debt
of gratitude to Simon.

Dick

[Dave Shaw]

I don't remember what Simon said about the programming issues at the time. One
pretty obvious one to me (I've been programming corporate systems on midrange
iron since 1978) is that all project attributes other than the scene texts
themselves are stored in a single XML file. This organization doesn't lend
itself to safe non-modal updates, since it's awfully difficult to avoid good old
'lose all the updates but the last one' syndrome. There are, of course,
alternative ways to organize the attributes, but they have drawbacks of their
own, and would require major changes to all the relevant code. That would be
major update material, and quite possibly beyond the effort level that Simon
would want to make, since, after all, yWriter is just a tool that he wrote for
his own use that he shares with the rest of us.

Of course, Simon is quite brilliant, and may find a way to meet the spirit of
these suggestions without such major alterations of the tool. Keep making
suggestions and give him time. I'm sure yWriter is just going to keep getting
better as long as he keeps working on it.

Dave Shaw

[DarthNewton]

Well first off of course I realize that this is simply a tool Simon
created and shares with us. And I love it. I was just offering a
suggestion that I thought perhaps he and others might find useful. :)

And Dick, you are quite correct in my idea of having the different
aspects (character, items, location and project notes) have different
windows. This would allow referencing as well as faster editing.

As for a single XML file...ohhhh for some reason I thought it used a
separate file for each (character, Items, Locations etc). Not sure
why...I know there one project file. Oi mental failure lol. Well this
explains why then. If you had several such windows open edited one then
switched between the it may "over write" other changes between windows
if you didn't save before you switched (window one note 1 window 2
character added then saved...window 1's note doesn't exist now and if
you save window 1 character info you just added goes poof).

I suppose other than a major rewrite the only way to prevent issues
would be to have them writable one at a time? But that would likely be
a large rewrite in and of itself. :/

Ah well guess I will just have to use work-around for this (probably
continue to make a fast notepad note and put them/organize them in
ywriter later).

[Simon Haynes]

yWriter5 uses a single XML file for data, yes, but this data is stored in memory and accessed from all over the program so there's absolutely no problem with changing things in two places at once. The xml file is written out from time to time, but it's only about 100-300kb in size on average so this isn't a big hit on the system.

The internals of the program are pretty complicated, but basically there's an object for each character, item and location, an object for each scene and chapter, and they're all stored in parent collection type objects. Where one thing needs to 'own' another (e.g. locations in scenes), each scene object keeps track of the relevant IDs.

You can get a pretty good idea of the internal structure by looking at the yW5 project file in Notepad.

Anyway, back to the question. Because yWriter allows multiple scene windows, when you add/edit/delete/sort characters/items/locations it's necessary to report the changes to all the other scene windows plus the main screen. I do this with events - when you save a location, for example, it raises an update event to the main screen, and the main screen then updates its own location list and tells any open scene to do the same. Multiply that by the number of places you can change things like characters, items and location, or set the VP character, and the number of places which DISPLAY char/loc/items, and you can see there is a huge amount of code behind the scenes to keep everything you see in sync with the data.

Now we're getting to the question. There are several places in the program where you can add characters. It would take a massive amount of code be to handle multiple copies of the list view where you can pick what to add and display what's already available. That would be yet another set of forms I'd have to keep track of and update every time someone edited/added/deleted a C/L/I anywhere in the program.

To allow multiple dialog boxes (the ones where you actually type in character-specific details) might not be too much of a stretch, but you wouldn't be able to open multiples from the list because once I display one modal window, the windows underneath are locked.

There is one other option: make the C/L/I list non-model, and write code to refresh it when anything changes elsewhere in the program. Then make the 'new char', 'new item', 'new location' dialog boxes non-modal as well, and don't bother tracking whatever is in those.

Just some things to think about.

Cheers
Simon
--
Freelance software engineer: http://www.spacejock.com
Author & freelance writer: http://www.spacejock.com.au

[DarthNewton]

Ahhh good it operates from memory, I didn't think of that aspect. :)
And I wasn't thinking of multiple character detail boxes, just the main
characters window as a separate dialog box for reference. Since most of
the data is displayed in the min list anyway and that is enough (most of
the time). Personally I don't change them all the time but I do
reference them all the time. To only have one character full bio/info
open at a time I personally don't see a problem in that as I don't edit
more than one at time (or view more than one full bio at a time).

I think if the tracking feature was removed that it would be a great
loss to many. I haven't used it as much, but I am sure I will in the
future. Just as I am sure that many people here use that feature. But
if no one uses that feature and thinks the idea of C/L/I dialog
boxes/list non-model is better I will of course go with the community
(not to mention the developer heh). :)

Sorry for the lateness of this response but I am trying to get a book
published at the moment and have been a bit busy the past few weeks
(that and I have been thinking about this issue, and what would work
best for others).