Issue 122406 - [sidebar] Switching panels disposes the UI element
Summary: [sidebar] Switching panels disposes the UI element
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 4.0.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: SidebarEnhancement
  Show dependency tree
 
Reported: 2013-05-29 08:29 UTC by Ariel Constenla-Haile
Modified: 2013-05-29 12:49 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
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.
trunk/main/sfx2/source/sidebar/Panel.cxx

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.