treesheets
treesheets copied to clipboard
aardappel
Increasing the size of a subgrid does not work correclty
Increasing the size of a subgrid while having a cell with negative size as drawroot will decrease the overall size of the currently zoomed in grid, even if the inner subgrid is much smaller (i.e. deeply nested) than the text in the currently zoomed in grid.
Replicate by:
- Create new grid of 10 cells
- Create a subgrid in a cell
- Write some text in the subgrid cell
- Decrease the size of the cell in the subgrid to -5
- Create another subgrid in the cell of the previously created subgrid
- Write some text in the deepest cell
- Create another subgrid and write something in the cell 3 more times
- Zoom out 4 times
- The deepest layer should now be visible but fairly small compared to the the text in the top layer
- Increase size of the deepest cell
Instead of the text in the deepest cell getting bigger, the other text will get smaller and will result in the currently selected cell folded.
Yeah I seem to remember it has an algorithm that tries to be smart about how to display the sizes in the current view (if different parts of the grid have different sizes), but that may sometimes be counterintuitive.
Well, is that algorithm that smart then? I think if it simply counted the size relative to the drawroot that would work best.
Not sure, have a look at the algorithm as it stands now, and propose what exactly you would change.
I've spent a lot of time going through how the layout size works and I think I have a solid idea now. My proposal as to how it should instead work is: The drawroot should be taken as a kind of base, and all the sizes in the cells should be relative to their parent. If any of the subcells become tiny, all their subcells are also forced to be tiny. This may result in some subcells being large, but this is preventable by making them smaller. Additionally, any documents from previous versions could be automatically converted into the new version by setting the relative size to their current size - parent size, so this change should work fine for any previous documents.
Being displayed as "tiny" (and all other font-sizing) is already a relative measure relative to the current drawroot.. when you make em tiny, you set their size to something that will make them tiny in the current view, but then as you zoom in, they will not be tiny anymore.
So what you're explaining is already how I understand it works. There's no need for conversion to relative sizes, as relative sizes are what are computed on the fly as relative to the drawroot size.
The system has some funky side effects, for example if current drawroot is 0, and child is -4, and its child is -2, then as you zoom in one step that second child becomes a whole lot bigger.. so generally you don't want to have larger sizes, but then again, sometimes you do, if you have a big "title" in a sub grid.
The system has some funky side effects, for example if current drawroot is 0, and child is -4, and its child is -2, then as you zoom in one step that second child becomes a whole lot bigger.. so generally you don't want to have larger sizes, but then again, sometimes you do, if you have a big "title" in a sub grid.
The system actually has some specific cases where it does not work how expected at all, and this makes making some specific layouts near impossible. See the .cts file in this comment.
Being displayed as "tiny" (and all other font-sizing) is already a relative measure relative to the current drawroot.. when you make em tiny, you set their size to something that will make them tiny in the current view, but then as you zoom in, they will not be tiny anymore.
There is a counterexample where zooming in does not make the drawroot not tiny. See the .cts file. incorrect-zoom-behaviour.zip