Description

I've been noticing an odd issue involving the media preferences window when navigating through it. When switching through the available options and tabs, the height of the window will begin to increase; in some cases by small increments, in other cases, large onces. This may not sound like much of an issue, but you can't resize the window once it's started resizing itself. I've noticed that closing and then reopening the window allows you to reduce the height by roughly one centimeter, and if you spend at least ten minutes doing this non-stop, you will be able to reduce the window to its original size. Alternatively, I've also noticed that if you begin to randomly click around the window's options, it will (eventually) stop resizing on its own and allow you to resize it to whatever height you wish.

The title is also correct in that the window's managed to stretch itself to roughly one yard in height. Don't ask.

This issue has been occuring on Haiku R1, Alpha 2 and Revision 38153. This has also been happening on essentially every revision in between.

Perhaps a hint: Some BViews report their *current* size in GetPreferredSize(). The default implementation of MinSize() uses GetPreferredSize(). So if you have a view in the hierarchy which is not properly layout friendly, you get this "window can never shrink" behavior.

Perhaps a hint: Some BViews report their *current* size in GetPreferredSize(). The default implementation of MinSize() uses GetPreferredSize(). So if you have a view in the hierarchy which is not properly layout friendly, you get this "window can never shrink" behavior.

Yeah, that is what I was thinking too, it might be that when the view is not layout friendly, we ought to use GetPreferredSize() in MaxSize() as well, so that we at least avoid this behaviour (currently it composes the explicit max with B_SIZE_UNLIMITED).

That being said, there also appears to be something funky in the preflet itself, killing media_server produces a large white block in Audio and Video settings. Switching between tabs in either of those settings causes the window to slowly creep in size as well.. :(

It's certainly not healthy when some views don't report stable Min/MaxSize() without invalidating the layout inbetween. I anticipate the problem to go away when all embedded views use layouting properly. Some of it is generated by the BMediaTheme stuff.

This is mostly fixed now (hrev40127), at least you can resize the window much more easily, the problem seems to be coming from the custom TabView used by the default media theme. Once I can confirm this, I will open a blocking ticket for that issue.