Issue1288 Comments to frames

[davidlamhauge]

This addresses #1288, or at least part of it.
Writing comments to keyframes has been an old wish, and this PR solves it.
@Jose-Moreno suggested that there should be markers on the timeline, to show which keys had comments, but I think that should wait for the timeline rewrite.

https://youtu.be/6iypzTRL2pw
I've made a short video to show how it works, and is saved.

[Jose-Moreno]

@davidlamhauge Excellent work! After seeing your explanation video the panel reminds me to that of Toonboom Storyboard Pro, so that might help other professional storyboarders feel at home.

There are four things however that might need revision from a work perspective.

1. Ideally these "captions" should stay visible and editable for the duration of the "panel", that is, the total keyframe drawing exposure.

• Can we think about having a similar behavior to the "drawing on previous keyframe" feature but for the comments?
• This would allow writing on the frame exposure / empty frames but still would attach the comments to the previous or current "keyframe" container that represents a "panel".

2. I forgot to discuss something before and that was the slug field, which is used per Toonboom instructions to add "(...)Notes regarding the timing of dialogues and actions in the current panel. These can be added while creating the storyboard to give instructions on how to create the animatic."

• I've worked with old storyboard templates where we usually left the approximate duration of a shot in seconds and that's about it.
• However when using digital tools we now tend to use the timeline itself to provide the rough estimate duration for the panel so it is visually obvious, basically creating the animatic ourselves.
• I can see how a slug field can be useful if the storyboard artist hands over instructions to an additional editorial department....but should we add it? what do you think? 🤔

Just so the others can understand, the following is a very rough example of "traditional" slugging (note the rough timing for dialogue is given with circled numbers which represent the keys). But obviously this varies between templates and work environment.

not my work 😋

3. This is a more technical comment on the fields themselves. I see that those have a 100 character limit, while it's better to have succinct instructions, I think 100 is a bit too limited. 140 characters equates to a "tweet" in social media, which is already short.

• Do we need the character limit?
• Or can we up the char count to 200 at least?

4. Related to No.3 I ask @pencil2d/developers is it possible to have a resizable TextEdit widget that stops at a certain character count or vertical size and then makes a vertical scrollbar appear if the panel is too narrow vertically?

Once again, great work and thank you for your hard work David!

[davidlamhauge]

@Jose-Moreno Thanks for your comments.
Your considerations and ideas are easy to implement, if we decide to do it like you suggest.

1. I thought it was better to be able to write comments when you are on the actual frame, but your idea is equally good. Maybe better...?
2. I don't know what 'slug field' is. What is it that is written there?
3. I set the limit, since I think that if you need more than 100 chars, then you'd better write a mail or talk to whomever you want to communicate with.
4. My first plan was to use QTextEdit, which is what you ask for. When I decided to set the max size, I changed it to a QLineEdit.

If we decide to remove the limit size and use a resizable textedit, then it will not be the slick and compact solution that it is now, but I don't care much. I'll implement whatever we decide upon, and I fully support your first suggestion.

[davidlamhauge]

@Jose-Moreno I may be slow, but I've read the slug-field information several times, and I'm not sure I understand it.
Is it information you write, and want to save in the file, or is it information you could take from the timeline and fps, and just show in the comments window?
Who uses the information?

[Jose-Moreno]

@davidlamhauge While this is quite common in TV Show and feature film story-boarding. This information is for other the director and other artists that manipulate /reference the file down the pipeline.

I found this concept to be better explained at another site:

Slugging is when the storyboard is edited to the correct length of the show, by the director or the slugging director. The director checks for continuity through out the board, making sure the dialogue works with the appropriate scenes. The director times out all the principle actions in every scene and if the show is too long, must find sequences that can be deleted without disturbing the story telling. On the other hand, if the show is too short, the director has to find areas where he can either add new scenes or stretch out existing scenes, without slowing down the pace of the story.

Here's another definition from a book I have:

Note: The slugging director is also known as timing director.

So Slugging is not doing the animatic, but giving the panel drawings the correct length and timing to prepare for that.

The slug field then is basically where storyboard panel artists place the rough estimate duration of the dialogues and the shots themselves, for all the panel drawings they've done, which will be then reviewed and timed out before the animatic is constructed, based on that information.

So for professional storyboard artists in a studio pipeline this would probably be more useful than to average hobbyists.

In that sense, I suppose we could encourage people to simply use the "notes" field to write the "slug" annotations, but if there are actual notes required as well, such as directorial annotations, that's when a 100 characters limit might not be enough to be honest.

Of course, I'm not thinking of writing a love letter in those fields 😉 but no matter how concise you try to be, you still have to be descriptive enough with certain camerawork, transitions or even explaining the intent of the shot if it's complex enough.

Not asking it to be unlimited, just flexible enough between common sense and heavy duty. I think having a limit anywhere from 256 up to 512 characters would be more than enough for anything that anyone would ever need to write there, where the latter upper limit is merely a title and a single paragraph in a Letter-sized paper.

[davidlamhauge]

Thanks again @Jose-Moreno for your constructive comments.
So, what if I raise the limit to 250 chars, and rename the 'Notes' field to 'Slug (timing, camera...)'?
I suggest this to keep the simplicity, but of course it must fulfill the purpose of the program. We could have all kinds of comment fields, but I think 'Dialogue', 'Action' and 'Slug (timing, camera...)' would be enough for even the professional artist.

[davidlamhauge]

I have raised the limit to 250 chars, and rename the 'Notes' to 'Slug (Timing, Camera, ...)'.
I have also altered the behaviour, so if you have a frame 10 and 20, and you are on frame 16, you can add comments. The comments will be attached to frame 10.
I have not changed the QLineEdits to QTextEdits, since it will significantly increase the size of the window, and I'm convinced that more than 90 % of all comments will be 50 chars or less.

[Jose-Moreno]

@davidlamhauge I think it's fine to leave the notes field as you had originally, it's fine honestly.

As we discussed before I feel Dialogue, Action & Notes are more universal and should be kept. The professional can adapt and use that field to file the timing if they need to (that's why they are pros 😋 ).

As for the QTextEdit, I was just thinking about those resizable text boxes you see in some applications (the ones that can be dragged from their boundaries) which is why I asked before if the others knew a similar solution so the panel wouldn't become bulkier.

Thanks again for taking the time to review these comments. Hopefully once the others sort out their business they can review the code as well in case there's anything that requires adjustment. 👍

[MrStevns]

I've reviewed the code and created a pull request @davidlamhauge .
Aside from various refactoring I've changes 4 things:

1. The textfields are now multiple lines
2. Removed the apply button, content will now be updated every time you enter something
3. Fixed a nasty memory crash that happened inconsistently.
4. Removed artificial text limit, as I saw no reason to have this.

edit: David has discovered a problem with the out of focus trigger that i'll address...

[MrStevns]

LGTM now.

comments: Me and David tested and tried various things to pre-optimize the way comments are saved to keyframes, all of them either added too much complexity (my opinion) or didn't fulfil the success criteria 100%, that is to always make sure the comments are saved when done entering. In the end we went with simply applying to a keyframe per keystroke... if this turns out to be a performance issue, then we can optimize it later...

[davidlamhauge]

I merged the updated master branch into the PR yesterday, and it was not easy, since much of the save-xml code had been altered in the mean time. It is still saved in a manner that is discussed in #1306.
While testing the updated branch, I found a 'bug' that is not a real bug, but more an annoying behavior:
If you want to write comment to your frames, you set the cursor in the input field and start typing your comment. After writing one comment, you want to go to the next frame for another comment. You press the shortcut for next frame (Arrow-Right for me) but nothing happens, because the cursor is in an input widget, and that overrides the shortcuts. It took me a minute or so to understand what was happening, so I can imagine how frustating it will be for the general user.
Any good ideas for solving this?

[Jose-Moreno]

If you want to write comment to your frames, you set the cursor in the input field and start typing your comment. After writing one comment, you want to go to the next frame for another comment. You press the shortcut for next frame (Arrow-Right for me) but nothing happens, because the cursor is in an input widget, and that overrides the shortcuts. It took me a minute or so to understand what was happening, so I can imagine how frustating it will be for the general user.
Any good ideas for solving this?

@davidlamhauge Greetings. Honestly, in other software I've used that allows for such notes this "annoyance" is unfortunately normal and there's low expectations on such behavior.

Having to press Return/ Enter to terminate the Text Area editing before moving to a new frame is also common, since It isn't always as simple or practical to have the user memorize a complicated procedure of course, so if we consider your use case i.e writing and moving seamlessly between frames while keeping the focus on writing we could:

• Change the special shortcuts that are mapped for the timeline globally, so we can move the playhead across the frames regardless of feature (e.g CTRL + Right Arrow) this would mean that as users we would have this "super" hotkey that would work regardless of which panel has focus, and a sub hotkey for normal interaction (in this case it's period and comma by default which I use personally), that way we can keep what we have without much hassle.
• I think we also need to guide users to "stop" editing the Text Area consciously. For example, It is common to use in modern chat applications the Enter /Return key to "send" a message and to use the CTRL + Enter shortcut to create newline characters. We could adopt this convention to avoid complicating the system.
• This way, if you want to finish your edit, press Enter, if you want a newline in the current edit, press CTRL + Enter, if you want to keep the edit open and move to a new frame press CTRL + Left or Right Arrow

To me that would be the simplest solution and would avoid us requiring an overly complicated panel-focus system similar to Harmony (which also confuses people a lot in my experience)

Note: I apologize if some of the shortcuts have already been considered, I have not tested this branch in a while.