holoviz / panel

Panel: The powerful data exploration & web app framework for Python
https://panel.holoviz.org
BSD 3-Clause "New" or "Revised" License
4.72k stars 514 forks source link

Dynamically Adjusting Spacing in Panel MultiChoice Widget #7107

Open singharpit94 opened 2 months ago

singharpit94 commented 2 months ago

I am using panel 1.4.3 and bokeh 3.4.1 and found that in MultiChoice widget the resizing of the box is inconsistent, check attached gif multi-choice-bug

If I have Pear as the last item selected and clear it, the selection box does not reduce its height while it does work as expected for other options.

Can you please check and provide a fix for this?

singharpit94 commented 1 month ago

Hi, any updates on the fix here?

ahuang11 commented 1 month ago

I think Panel MultiChoice inherits from Bokeh, so you might want to raise an issue there to have it fixed upstream.

Alternatively, you might be able to find a workaround by setting a fixed height.

bryevdv commented 1 month ago

There is nothing to fix, this is just how the underlying choices.js functions. Whenever there is no longer enough room for the input cursor (and presumably a nominal amount of padding) a new line is added to accommodate it. The difference above is due the difference in the amount of space "Pear" takes up compared to "Strawberry". The Bokeh issue has been closed as upstream (toss-up with working as intended)

mattpap commented 1 month ago

There is nothing to fix, this is just how the underlying choices.js functions.

Closing the issue as upstream was premature, because there's ongoing work to replace all existing widgets, that use external libraries, with "in-house" implementations. Thus in a relatively short term bokeh won't be bound by choices.js' behavior, limitations and bugs. Instead it would have been beneficial to discuss what the expected behavior should be (barring the obvious lack of contraction when removing certain items).

bryevdv commented 1 month ago

As I said the behavior (making space for something that requires space) seems perfectly reasonable, certainly not unexpected to me. I am not even sure what else could be expected, really.

I also think replacing a perfectly good widget backed by a popular and well used library would make a very low priority. But in any case requirements for that should be discussed in a dedicated issue.