You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some split panes designs have a size for the splitter (usually some kind of border of a different color clearly separating panes), and such designs are a bit tedious to implement with this library currently. It would be great that the computation of pane sizes take into account the splitter size.
It is still possible to work around this, this is one example of a solution:
It could also be supported by making it a SplitPanes prop, so that it is easy to take into account in the logic by using a basis of:
100 - ((panesCount - 1) * splitterSize / totalSize * 100) instead of 100.
Then, that value only has to be assigned to splitter children. The only caveat (or is it one?) is that it must be specified for each instance.
I do understand that it is not trivial to implement and rather niche. But I thought it would be great to bring to attention for consideration in the future. That would also fix a small bug where the splitter end sometime "jumps" 1px on and off.
The text was updated successfully, but these errors were encountered:
I understand it would be useful, but I do not plan to implement these features. The splitter size should be defined in CSS along with color and other properties. In other words, the size should be implicit rather than explicit (inside the code).
That said, I realize that changing the splitter style today is not straightforward; it should be a standalone component.
Some split panes designs have a size for the splitter (usually some kind of border of a different color clearly separating panes), and such designs are a bit tedious to implement with this library currently. It would be great that the computation of pane sizes take into account the splitter size.
It is still possible to work around this, this is one example of a solution:
but it would be great if the following was enough:
It could also be supported by making it a SplitPanes prop, so that it is easy to take into account in the logic by using a basis of:
100 - ((panesCount - 1) * splitterSize / totalSize * 100) instead of 100.
Then, that value only has to be assigned to splitter children. The only caveat (or is it one?) is that it must be specified for each instance.
This would allow for something like:
I do understand that it is not trivial to implement and rather niche. But I thought it would be great to bring to attention for consideration in the future. That would also fix a small bug where the splitter end sometime "jumps" 1px on and off.
The text was updated successfully, but these errors were encountered: