Issue 122406

Summary: [sidebar] Switching panels disposes the UI element
Product: General Reporter: Ariel Constenla-Haile <arielch>
Component: uiAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Normal    
Priority: P3 CC: awf.aoo, issues
Version: 4.0.0-dev   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 122257    

Description Ariel Constenla-Haile 2013-05-29 08:29:48 UTC
- New Writer document
- Activate the gallery panel in the sidebar
- select a different image from the one that is already selected
- switch to the navigator panel, select "Hyperlinks"
- Switch back to the gallery: the image you have selected is no longer selected
- Switch back to the navigator: "Hyperlinks" is no longer selected

From the user perspective, this might be not user-friendly.
From the "technical" aspect, this is a waste of resources, the UI element is recreated every time the user switches panels; as side effect, unless the panel implementation stores its state, the panel state is lost having the effect described above.

The root cause is that sfx2::sidebar::Panel::Dispose() disposed the UI element.

While later initialization of the UI element when the respective deck is activated is good for performance, destroying the panels is not.
Comment 1 Andre 2013-05-29 08:51:31 UTC
I am changing the issue type to enhancement.  I agree that a form of caching might improve usability in a few cases but the state of most panels is defined by items which belong to the document and therefore is already persistent.

Adding caching will open its own can of worms.  I did not implement caching of panels because:

- No premature optimization.

- In the beginning the Impress panels where still tied to view shells.  Caching them would have been a major undertaking.

- We don't have a performance problem (to my knowledge).

- Panels in the cache still need some parent window.  Changing parents of controls that are not designed for that may or may not work.

- Caching panels of unknown implementation and complexity may require a good caching strategy to avoid allocating too many resources.

- Most panels are not designed to be dormant for an extended period of time.  They may have listeners and might react to events which can lead to unexpected results.