Feature Request: Changing width of Xsheet cells?

[Rodney]

I will guess there is a way to manually change the width setting of cells in the xsheet but I don't know quite where to begin looking for such a thing.

Does anyone know where that setting can be found (or if it exists)?

Although I understand why cells need to be as small as possible and of same width as other cells in most cases I may drop a feature request to have an 'auto' width setting applied to the cells or some means of increasing the width.

In a perfect world I'd say having the width controlled similarly to the cells in Microsoft Xcel would be ideal.

In the meantime, I'd just like to have the cells a little wider.

Thanks in advance.

Edit:  I may have found where the width is stored and (if so) it would appear to be hard coded in the xsheetviewer.cpp code on lines 51 and 52.

It appears to be 74x20 pixels.

const int ColumnWidth = 74; const int RowHeight = 20;

[beeheemooth]

And I would like them to be more narrow. )

[Rodney]

I am changing the category of this topic to 'Feature Request' as I don't think the size of columns can currently be changed outside of setting in the code and recompiling.  As such the feature request would be to expose the height/width of xsheet/timeline columns to the user so they may be changed.

1.  Allow explicit sizes of cells in the xsheet/timeline to be set

This is the primary feature that is desired and the most likely place to store/edit this information would be in OT preferences.

2.  Outside the scope of this feature request but important for implementation consideration:

The long tail of this seemingly straightforward feature request eventually has to account for some other logical progression (anticipated future feature requests).

For instance.  Item 1 simply allows for simple change to the size of xsheet/timeline cells and keeps this size no matter what project is opened and regardless of how the settings were previously set.  There is no 'memory' or concept of what might be an optimal setting short of the user at that exact moment desiring a specific height/width for columns/cells.

Two other options present themselves at this point:

a.  Allowing for variation in the size of columns/cells

b.  Allowing for settings to be recorded and recalled for use with specific scenes/projects

c.  Allowing resize on-the-fly in the xsheet/timeline by dragging/double clicking/right clicking or other user interaction

This would suggest that any sizing done by user on the fly (if implemented) should be sticky so that the size gets set and can be recalled later (upon reopening the project for instance).

This would suggest the width settings would be stored in the scene file and not simply set in the UI Preferences.

I would imagine this secondary level of control would override the preference unless specifically turned off.

For instance, an option "Override with Project settings (if any)" might be an option required to allow the creator of a Project have their settings override the preference set by the user.  In other words, the creator of the Project set the column size to what they deemed optimal but another user that opens the file might not prefer that setting.

3.  Also outside the scope of this request:  Extended functionality that seeks to predetermine optimal settings.

a.  Add an 'auto' option to automatically resize the column based on the textual content off the cell.

This could be controlled by a textual size limitation (ex:  10 characters or 10 pixels).

That setting would then drive not only the size of the text displayed in the column but in the width of the column.

The limitation should be a range (minimum and maximum).

The auto setting presupposes that each column would have a different width as set by content unless a limit is specified.

b. Add a 'sticky' option that lets the user set and keep the width of any given column independently of the width of other columns.

I must assume some of this feature request is already being implemented as part of the broader Timeline refinement.

As such a specific PR might not need to be opened unless it best captures that aspect of development.

Submitted for your consideration.

Thanks!

[Snapai]

Would adjusting the cell-width in Timeline view go here, too?
Adobe Animate/Flash handles that with a few discrete options, though I can imagine a scroll bar with a few easy presets might be better.
Also while we're at it, rendering the cells' contents within them when they're large enough would be good too.
For an example, here are the cell widths that CS6 had, selectable from the timeline's dropdown menu:

Tiny (4 px cells): Small (6 px cells): Normal (8 px cells): Medium (16 px cells): Large (24 px cells):   Preview (40 px, triple height cells with preview images of the entire art of each frame):  Preview in Context (40 px triple height cells, with preview images of how the layer is framed on the stage/by the camera):

[Jane Eyre]

I'm pretty sure that zooming in functionality is planned for the timeline in the future. It would be great to see the the thumbnails of the levels when it is large enough.

Maybe once the size capability is in the timeline it will be possible to extend that to the xsheet?

[Rodney]

@Snapai said:

Would adjusting the cell-width in Timeline view go here, too?

Yes, definitely.

I will say that while I understand using Animate/Flash/After Effects as a benchmark for comparison (with very good reason!) I tend to shy away from such because I'm interested in how OpenToonz might be able to do <fill in the blank> even better.

As such my benchmark for comparison would actually be Microsoft Excel because of some of the functionality found therein I have never seen in any drawing/animation application.

Considering such we might find ourselves on the edge of new paradigms in digital animation.

For the record:  I favor the Xsheet over the Timeline... very few applications leverage the (classic) exposure sheet... and I find that to be one of the foundational strengths of OpenToonz.

If/when we make comparisons here we should very likely consider the strengths of traditional hand drawn animation and its resulting workflows before refactoring it within the digital context.

Where are the bar sheets, grey sheets and other form factors no longer considered worthy of use?  Well, to answer my own question, most appear to have been incorporated (read:  hidden) in a variety of applications.

 

Of course, gaining the Timeline view is very serious icing on the cake!  

@Jane Eyre said:

I'm pretty sure that zooming in functionality is planned for the timeline in the future. It would be great to see the the thumbnails of the levels when it is large enough.
Maybe once the size capability is in the timeline it will be possible to extend that to the xsheet?

Agreed.  At some point we will very likely find ourselves staring at the 'video editor' paradigm as those various worldviews converge.

We are nearly there already.

A question for the long term will be how can we continue to leverage the unique strengths and approach of OpenToonz so we concern ourselves less with the process and more with regard to creativity and perhaps most importantly... completion... of projects..

Not that I don't enjoy the journey just as much or more than arriving at the destination.  :)

[Snapai]

Toonboom Studio 8.1 had an xsheet, I haven't really messed with Harmony enough to know if it still does.
8.1 Xsheet: https://puu.sh/wYSdG/1c402ecdf5.png
8.1 Xsheet with thumbnails: https://puu.sh/wYSeT/f5f85d4bb4.png
It's just not nearly as popular as the timeline - particularly since this holds a lot more frames: https://puu.sh/wYShb/78ef05af00.png

(TBS8.1 project from https://www.youtube.com/watch?v=1wkCR2r2Tjw which I also used Blender on - would've done it in OT had I known about it then)

Here's Krita's timeline, with a dynamically-adjustable width (click and drag on the width button): https://puu.sh/wYSxa/54ea57816a.png

[Rodney]

I tried to use ToonBoom Animate's xsheet but recall I was frustrated by it and  it seemed to me to be more of an afterthought.

I had been looking for something more akin to traditional handdrawn xsheet usage and didn't see it there.

I would dust it off and investigate but I don't see pursuing a ToonBoom solution any time soon.

My curiosity was satisfied enough to know that I could work in it if I had to.

One could argue that OpenToonz doesn't quite have the ideal xsheet either but... the xsheet is so well incorporated into Toonz that it makes up for any current deficit.

I have not used TVPaint's xsheet and I understand it may be the best available in any software offering.   I cannot confirm or deny that but from what I've seen they have placed a proper emphasis on it's implementation and use and fully embrace the traditional handrawn approach.

The price of TVPaint was the major reason I couldn't approach use, mostly because if I recommend it others they have to spend a considerable amount of money.

It's one thing for me to spend my money but I have to think of others too.

I have seen enough of TVPaint use that I would recommend it to those who can easily afford it but in my estimation... with OpenToonz readily available... any user of TVPaint should also have a copy of OpenToonz installed and available for use.  There is no artist/animator who should not have OpenToonz on their computer.  At the very least... the portable version.  :)

Having said all that, TVPaint does have some xsheet functionality I'd love to see in OT.**

As related to this topic.. I'm not sure if TVPaint's xsheet columns can be adjusted.

**The folks at TVPaint don't seem to emphasize xsheet use in their promotional material.

[Rodney]

The ability to change the width of columns in the xsheet (and rows in the Timeline) is still desired.

I'll see if @manongjohn has any thoughts on this as he's very famillar with the xsheet and timeline code.

Update:  @manongjohn and I discussed this and there are a lot of moving pieces.

If you... yeah... you... have thoughts on this your input will be appreciated.  :)

[Jane Eyre]

I use a pretty small screen at school so I do really see the benefit of narrower columns. I think the major issue might be the size of the various buttons. I think for the classic and classic-revised headers, there would be pushback for shrinking the buttons at all.

However, for the compact header, I wonder if it could be made responsive? Perhaps at full size, the buttons fill up their row as they do now. When set to a different (smaller) size, the icons start wrapping to the next row & all stretch to equally fill the space in the row. Personally I wouldn’t go narrower than half the current width. It could be like the level strip where you set the size in a preference or it could have the zoom toggle like the timeline. Either way, the downside is that the buttons would start encroaching on the icon area. This would be pretty easy with CSS using flexbox, but I’m not sure how complex it would be in QT/C++.

It might be easier to just have a “half size” preference when the compact header is selected & forget about being responsive.

The overall downside to changing just the behavior with the compact header is that it’s pretty much guaranteed that people following tutorials would get confused about why their Xsheet doesn’t work like that.