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.
The settings are now stored to settings_per_account.xml.
This change affects all floaters having save_rect/save_visibility/save_dock_state params set to "true",
not just detached sidebar tabs as the ticket requests.
Cursor didn't change to "resize" state, because handlehover of bottomtray wasn't working correctly. It happened
because LLPanel::handleHover() wasn't called in LLBottomtray::handleHover().
- There was no good reason to override habdleHover() in LLBottomTray so new method onDraggableButtonHover() was introduced to be called
from bottomtray buttons(as it was already done for mouse up and down).
-> see http://redmine.catznip.com/issues/2
- fixed : "Build" menu option under "Build" should visually disable when both @edit=n and @rez=n restricted
--HG--
branch : RLVa
- Added methods responsible for saving and loading order of buttons to bottomtray. Order is saved after each drag'n'drop to
ensure user's customization of bottomtray is not lost because of crash.
- Added additional argument to layoutstack movePanel() method which tells it to move panel to the beginning of mPanels vector
without requiring a pointer to panel before which it should be inserted.
Reviewed by Vadim Savchuk.
- Though visually user drags buttons, layout panels are really moved. To move one panel before other, new method movePanelBeforeOther() was added to layout stack.
- When drag'n'drop is finished, order of panels in layout stack mToolbarStack is changed, and also order vectors are updated in bottomtray.These are vectors mButtonsProcessOrder and mButtonsOrder. mButtonsOrder was introduced in this changeset to store order of all bottomtray buttons that may change place via drag'n'drop and should save and load it between sessions. mButtonsProcessOrder is not enough for it because it contains only buttons that may be hidden(and for example Speak button is not included in it).
- To pass mouse events from buttons to bottomtray, new class LLBottomtrayButton was added (and new widget bottomtray_button for it).
Reviewed by Vadim Savchuk.
Arrehn