I'm not sure what the root cause of the problem was (maybe invalid initial selection in folder view),
but what seems to be definitely wrong is passing "scroll to rect" event
from *invisible* folder views up to accordion control, which is what I've fixed.

- Added signal to LLFloater that is emitted on minimize.

- Set minimize callback for appearance tab floater in LLSideTrayTab::undock. Method from LLSidePanelAppearance that handles camera issues
is called on minimization of floater.

- Added missing column to the xml of the scroll list

- Adjusted columns width to show all columns

make ctrl-f work from the script search box itself.

change to better / more consistent naming

let some LLViews handle shortcut keys if they want.
reviewed with ambroff

-Increased space between bottom of the floater and bottom of the web browser (inside floater), so that 'Loading / Done' text
 between bottom of the web browser and bottom of the floater won't be cropped

- Increased overall floater width.
- Increased permissions columns width.
- Increased 'Check All' and 'Clear' buttons width.
- Applied text wrapping to permissions labels.
- Removed 'NextOwnerLabel' dimensions overrides for German.
- Removed 'Check All' and 'Clear' buttons dimensions overrides for Polish.

fix for SH-173/VWR-22868: Development Viewer freezes just after startup / greedy with file handles / 'WARNING: ll_apr_warn_status: APR: Too many open files'
(transplanted from a9aefa70c029eb9dddec3833d0ce22ef4b4421b5)

- Some checkboxes moved in DE locale and EN xml file.
- Removed floater width override for ES locale.

Submitting on behalf of Thickbrick Sleaford.

One of the LLSelectNode constructors has a leak where it does "new LLPermisions()" twice, thus leaking the address of the first object created.

This constructor is called every time you interact (click, hover, select, possibly other) with an object, once for each prim in the object. Since sizeof(LLPermissions) is 92 bytes, this can be a significant amount after a while.

I think this might explain VWR-18528 (leaking LLpemissions instances), at least partially.

This was fixed in snowglobe 1.x as part of SNOW-267.

- Deleted gear button as unnecessary. There is no functionality for it.

Detached SP now has a slightly reduced height not to make it flush with the bottom bar.

(transplanted from f71072a1532b3fa3de98197dd0ceeb3071ac6856)

* Added new icon artwork.
* Reordered the icons so that the most common ones are to the right, so that they change position as little as possible.
* Removed old 1.23 icons.
(transplanted from 5ed5fa607e2ce3eaabc8f9716bd4a6ef5933aa64)

We were using a NULL pointer after checking it. Did some logic juggling to
ensure that we only use the pointer if it is non-null

Code reviewed by Seraph
(transplanted from a90fe10ddac9545249c6f218af438a36bcbc3162)

Patch by Merov ported and reviewed by Tofu, from SG2.

The crash was introduced by my previous fix of this ticket in changeset 8ceebd3612f0.
The problem was that, suprisingly, even invisible (faded) toasts were destroyed when you hit Ctrl_Shift+W,
however they were still referenced by the toast pool, so the references were invalidated.

The easiest fix would be to remove all references to the toast being destroyed, no matter is it visible or not.
However, then we'd have to search for each destroyed toast in the pool, which is slow.
Besides, removing toasts from the pool compromises the whole idea of pooling (which was introduced to speed up creation of new toasts).

Another possible fix is not to destroy any nearby chat toasts when user hits Ctrl+Shift+W.
That would save us from any crashes at a price of changing existing behaviour (the toasts will remain visible).

So I went for a third option: when closing all floaters, skip invisible ones.
Then there won't be attempts to destroy invisible (pooled) toasts, so the crash won't happen,
and we don't seem to change any existing behavior.
However I'm not 100% sure of the latter statement, so the fix requires extensive testing.