Fixing a regression introduced in tier 1: not displaying the bottom tray buttons
added when bottom tray was not wide enough display them, even after increasing
the width to show all visible buttons.
The fix is to mark such buttons as auto-hidden so that they appear
as soon as we have enough free space.
When user manually toggles a button (via context menu),
show it regardless of whether it has been auto-hidden.
Tech note:
Added showButton() method which does the same as processShowButton() did
but the check for the button being auto-hidden.
* When there is some free space and all auto-hidden buttons have been already shown,
first extend the Speak button, then the others (was: vice versa).
* Made the Speak button always have fixed width.
- To decrease code duplication:
* Added RS_BUTTON_SPEAK to the button->panel mapping (mStateProcessedObjectMap).
* Replaces all lookups in mStateProcessedObjectMap with calls to getButtonPanel().
- Added some comments.
Cumulative diff of changes made by Wolfpup, Richard and me.
Description:
* Ability to hide the Speak button with the bottom tray context menu.
* Made the chat input resize handle visible, so that the feature is easily discoverable.
* Applied Richard's fix to layout panel resizing logic.
Bug was caused by counting only width added by last resize as usable for Speak button extending, so widening viewer window by few pixels many times when Speak is shrink would never let it expand regardless of available space.
- Added check for possible chiclet panel shrinking width- cause spare space goes to it when extending. If there is enough space to give from chiclets to Speak, Speak is extended.
The bug was caused by moving nearby chat bar into panel inside layout panel instead of being layout panel itself in changeset 741eb25e921c without modifying get_panel_min_width() call which used that layout panel. This broke behaviour of LLBottomTray::processWidthDecreased().
- Fixed it by using this new nearby chat container layout panel in this call.
The bug was caused by moving nearby chat bar into panel inside layout panel instead of being layout panel itself without modifying code in LLBottomTray::loadButtonsOrder() which used that layout panel.
- Fixed it by using this new nearby chat container layout panel in this method.
The bug reproduced not only for opening/closing sidetray, but also when viewer window was resized.
The chatbar's width was set to default on width increase, it was also shrunk even when there was enough space for it, and buttons could be shrunk instead.
Also, width to which user resized it manually, was not used in resizes. Gave priority on resizes to nearby chat - i.e.:
Before this fix priorities were- buttons are visible -> buttons are as wide as possible -> nearby is stretched.
After this fix priorities are- buttons are visible -> nearby is stretched -> buttons are as wide as possible.
- Added new member which stores width of nearbychat(either value that was recorded after user's manual resize of chatbar or default). Used it as a value to which chatbar tries to be resized on resizes.
- Implemented the change of priorities described above in processWidthIncreased() and processWidthDecreased() methods.
Don Kjer