Issue 123276 - layer visibility status change after page switch and then are not correctly shown in lower tab
Summary: layer visibility status change after page switch and then are not correctly s...
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: 4.0.0
Hardware: PC All
: P3 Major (vote)
Target Milestone: 4.1.0
Assignee: Andre
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-17 15:52 UTC by efa
Modified: 2014-02-10 09:32 UTC (History)
3 users (show)

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


Attachments
Draw example with objects on layers (18.77 KB, application/vnd.oasis.opendocument.graphics)
2013-09-17 15:52 UTC, efa
no flags Details
simplest example (10.72 KB, application/vnd.oasis.opendocument.graphics)
2013-10-01 15:11 UTC, efa
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description efa 2013-09-17 15:52:13 UTC
1) open attached Draw document with 2 pages and some objects on every layers of page 1.
2) disable layers "Controls" and "Dimension lines" using SHIFT+left click on lower tab
 ==> (some object disappear and layer names become blue in lower tab)
3) change to page 2
4) back to page 1
 ==> now all objects are shows again, but lower tab names remain in blue
From now on, layer status shown in lower tab is wrong.

Clicking again on lower tab seems synchronize real status with shown status, but with this bug become impossible to know if each layer is really on or off, without activating each every time.
Comment 1 efa 2013-09-17 15:52:53 UTC
Created attachment 81561 [details]
Draw example with objects on layers
Comment 2 efa 2013-09-17 19:18:40 UTC
I forgot to mention, it is a regression, this effect was not present on 3.4.1
Comment 3 Armin Le Grand 2013-09-20 17:30:17 UTC
ALG: I checked with AOO341. The logic is to keep the state of the LayerTabBar, but to use their setting when page is changed.
Example: New draw, one object on each layer (activate layer, draw object). Second page, same (I colored the objects to make them easier to distinguish).
When switching pages the state of the Layers stays in the LayerTabBar, but is resetted on the newly shown page.
Thus the error is: PageChange in draw/impress does not set the current LayerState correctly at the newly shown page.
Checking...
Comment 4 Armin Le Grand 2013-09-20 18:20:57 UTC
ALG: With my testfile it works exactly the same in AOO400 and AOO341. Also works the described way in OOO330 and OOO320 (in OOO220 the controls layer is not shown, but else the same).
In AOO341 your example file works, in AOO400 not. It works when I do the following: in AOO400 load testfile, change to 2nd page, draw an object on each layer, all switching (layer on/off, pages) works well.
Something strange is going on (maybe in the file? How was it created?). When following the description and switching (step 3) a short flicker repaint shows all objects already...
Comment 5 efa 2013-09-20 22:17:21 UTC
I got the bad behavior on many different drawings, not only in the attached one, that is simply an extract.
I will look for a drawing in my archive that do not show this behavior

Maybe there is same interaction with some user settings that activate the bad behavior. Apart grid settings, my profile is quite new created by 4.0 installer.
Comment 6 Andrea Pescetti 2013-09-21 21:28:23 UTC
Confirmed on Linux 64 bit too (OpenOffice 4.0.1 RC1); same behavior as Armin described. I didn't test with older versions.
Comment 7 Armin Le Grand 2013-09-23 09:27:30 UTC
ALG: Looks as if with the page change a DrawViewShell::ReadFrameViewData is somehow triggered for the shell change which deletes the layers set, need to check deeper.
@efa: Thanks for the additional infos!
Comment 8 Armin Le Grand 2013-09-23 10:05:23 UTC
ALG: DrawViewShell::Deactivate was changed in drviews1, thus there will be no deactivate and thus the values will not be saved. The following activate will then use the wrong values, as it seems. Need to find out why this was changed...
Comment 9 Armin Le Grand 2013-09-23 10:14:32 UTC
ALG: Done by af with r1486578, as fix for task 122332 as it seems. Af knows better about this context switches, thus I will note him about this sideeffect of the former fix.

@af: The missing call to DrawViewShell::Deactivate leads to problems when switching to the 2nd page in the example: DrawViewShell::ReadFrameViewData is called in activate without a former call to DrawViewShell::WriteFrameViewData since deactivate is missing. In this example the changed visible layers is lost, but in principle any changed setting in a FrameView will be lost this way. Please have a look.
Comment 10 Ariel Constenla-Haile 2013-09-23 11:04:07 UTC
(In reply to Armin Le Grand from comment #9)
> ALG: Done by af with r1486578, as fix for task 122332 as it seems. Af knows
> better about this context switches, thus I will note him about this
> sideeffect of the former fix.
> 
> @af: The missing call to DrawViewShell::Deactivate leads to problems when
> switching to the 2nd page in the example: DrawViewShell::ReadFrameViewData
> is called in activate without a former call to
> DrawViewShell::WriteFrameViewData since deactivate is missing. In this
> example the changed visible layers is lost, but in principle any changed
> setting in a FrameView will be lost this way. Please have a look.

While at it, please look at bug 121863 comment 19
Comment 11 Andre 2013-10-01 13:39:21 UTC
Looks like there is a little more work necessary than just not forwarding the Deactivate() call from DrawViewShell to ViewShell.  In fact, the purpose of the change was to omit the call to BroadcastContextForActivation() in SfxShell::Deactivate(), where SfxShell is the base class of ViewShell.  Fixing this should be straightforward.  The only question is, how to do it in a way, that does not look like a hack.

At the moment I am thinking about adding a flag to the context change broadcaster (the one that has the BroadcastContextForActivation() method) that would deactivate it temporarily, and deactivate it from inside DrawViewShell::Deactivate().  But that does look a bit like a hack.
Comment 12 efa 2013-10-01 15:10:55 UTC
happen about with all drawings, also simples one like the new attached
Comment 13 efa 2013-10-01 15:11:49 UTC
Created attachment 81685 [details]
simplest example
Comment 14 SVN Robot 2013-10-02 08:52:10 UTC
"af" committed SVN revision 1528376 into trunk:
123276: Properly forward Deactivate() call and still don't broadcast context ...
Comment 15 Andre 2013-10-02 08:53:20 UTC
Added a flag to the ContextChangeBroadcaster in sfx2/source/sidebar that allows DrawViewShell::Deactivate() to temporarily deactivate context change broadcasting and still forward the Deactivate() call to its base class.
Comment 16 Armin Le Grand 2013-10-08 09:16:10 UTC
ALG: Checked, works again, closing.