search

JetBrains / compose-multiplatform

Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
https://jetbrains.com/lp/compose-multiplatform
Apache License 2.0
15.91k stars 1.16k forks source link

SplitPane component #334

Open igordmn opened 3 years ago

igordmn commented 3 years ago

Consider implementing SplitPane component available as a maven artifact: https://github.com/JetBrains/compose-jb/tree/master/components

P.S. we implemented non-ideal version of it in: https://github.com/JetBrains/compose-jb/blob/9e67cfc916f696220d630ceb6e5b67e9570777a3/examples/codeviewer/common/src/commonMain/kotlin/org/jetbrains/codeviewer/ui/CodeViewerView.kt#L56

See also: https://github.com/JetBrains/compose-jb/issues/148

igordmn commented 3 years ago

@LAP2 implemented SplitPane here

Thanks!

Things that we need to do or think about:

  1. Is it right that we change size in percent's, not in pixels? Usual desktop programs don't work this way. Columns in desktop apps have fixed size, and only change their size when it is not enough space.

(it is important and we need to think about it before publication)

  1. How can we implement multiple columns? Now we can put one SplitPane into another. Is there a better way? In which cases nested SplitPane can cause undesirable behavior?

  2. Is an API for defining custom splitter minimal and powerful?

  3. Write tests:

    • try to coverage all cases in all if's in SplitPane.kt
    • write tests for recomposition with different arguments for Composable

  4. Configure maven publication

  5. Try to use SplitPane in codeviewer, issues and widgetsgallery.

altavir commented 2 years ago

Just tried it. Several issues:

SerVB commented 1 year ago

I've just taken a look at the SplitPane usage. It's cool that it already works, thanks! At the same time, I have some ideas how it can be improved. Should I write it here or in separate tickets? For now, writing here.

Is it right that we change size in percent's, not in pixels? Usual desktop programs don't work this way.

We have the whole window divided by SplitPane and it's a bit unexpected to see that the percent is persisted when the whole window is resized: both halves are resized.

Probably in addition to rememberSplitPaneState(0.3f), something like rememberSplitPaneFirstSizeState(240.dp) can be introduced. In case of our app side when the "first" half is the navigation, it's expected that it has a persistent size during whole app resizes but a changeable size when the user wants to resize it manually.

Also, we have too big minimum sizes for first and second halves (240 and 640 dp), so it often happens that the app is smaller, and the splitter can't be moved at all. Looks like a bug, but it isn't in fact.

However, would be cool to somehow show the user that it's not a bug. For example, avoid applying the pointerHoverIcon(PointerIcon(Cursor(Cursor.E_RESIZE_CURSOR))) modifier that we apply now unconditionally. Can we somehow determine that the splitter is now in the fixed state? This way, we can add a condition for the hover cursor.

okushnikov commented 2 weeks ago

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.