splitting with fraction=1.0 has unexpected result

[Omustardo]

When creating a split with a fraction of 1.0, the new tab can be placed in an unexpected surface.

Example code: https://gist.github.com/Omustardo/c613f21633fdbf382a6795e05ed55379

I'm not entirely sure what the expected behavior here should be, but the actual behavior was surprising to me. The "Bottom" and "BottomLeft" tabs were placed on top of each other, with the little tab area showing "Bottom" while the tab content showed "LastLeft".

Perhaps there should be a warning when not compiling in release mode? Perhaps it would be worth adding an additional warning to the documentation of the split methods?

[anhosh]

so i noticed that if you hover on the line above the initial LastLeft tab, it'll highlight it like this:

if you then click and drag it in any direction, the split will snap up to its correct position which accounts for tab body's inner padding:

i think the intended behaviour should be that the split should automatically snap into its correct position at the moment of creation, and not only when the user interacts with the split.

[anhosh]

i made a quick PR demonstrating what this behaviour would look like: #289. let me know if this is desirable before i merge it.

[Omustardo]

I have a minor concern about the documentation of the split_* methods. https://docs.rs/egui_dock/latest/egui_dock/dock_state/tree/struct.Tree.html#method.split_below.

The claim is that the fraction provided will be used:

fraction (in range 0..=1) specifies how much of the parent node’s area the old node will occupy after the split.

Perhaps it should be a weaker claim. Something like:

fraction (in range 0..=1) specifies how much of the parent node’s area the old node will attempt to occupy after the split.

This is probably a pre-existing discrepancy though, since you showed that the split snaps into position after a user interaction.

---

Perhaps a fraction of 1.0 shouldn't be allowed in any split_*? With the PR to ensure minimum sizes, I don't think it would respect a fraction of 1.0 unless the parent didn't have any area, and I'm not sure if that's possible.

---

All that said, the new behavior looks good to me! Having the tab stacked on another tab in a different surface made this issue tricky to discover, so almost anything to avoid that is a better state for developers (and probably end users). Thank you!

[anhosh]

I've updated the documentation, so this issue can be closed now.