pwa-centering Page work area should be centered

[deyan]

Page work area should be centered as it was before. If this is a requirement of another task, please link it here.

[deyan]

For the full behaviour, see BOOK_WINDOW_R1

[deyan]

Batch update from file report_1.csv

[tanya]

• New LayoutManager created - CustomLayout - the idea
  • We create CustomLayout(LayoutManager2 lm) - lm is for example BorderLayout. We can add objects with constraints CustomLayout.CUSTOM. If we add objects with different constraint, then we call the method add of the other manager - lm (BorderLayout for example). This layout can be used with JLayerPane for example, then we can can have different objects on different layers and on layer JLayeredPane.DEFAULT_LAYER to have BorderLayout (or something else), but on JLayeredPane.PALETTE_LAYER to have null layout. - tests available in the implementation.
• We change the layout of the JDesktopPane - the swingComponent of the PageWorkArea to be with CustomLayout - this way the work area will be with BorderLayout - CENTERed, but the halos will be with null layout.
• To center the page - actual view rectangle in BaseSceneVisual is created this way, that the page is centered in the actualViewRect(). After that, when actualViewRect is drawn over the ScenePanel, the actualViewRect is centered in the panel. This will make problems with the halos (the second centering), so translationPoint is added to be calculated with how much the halos should be translated. The translationPoint is taken into consideration in sceneToSwing and swingToScene method.

[meddle]

I think, I get the idea, but the design is hard to understand:

• If you've added your code till now, it would've been clearer.
• The tests must be provided on de-fi, not im-fi
• But this is something like a bugfix so make it im-fi and we will try it out :)

3.5p

[meddle]

The task will fail:

• The task is not about the way the Page Work Area is resizing, it is about centering, when you move frames outside the page bound to the left, the area is resizing in both the directions -> left and right, that is not the right behavior in the analysands view.
• There is strange bug, when you resize the Page and sometimes the it is bigger then the area the scroll bars are providing. That is fixed when you click on the page... Sometimes frames are lost because of that...
• Don't live "// TODO Auto-generated method stub " in the implementation.

You should score the analysis of the BUG when you pick it... If the analysis is not full you can fail it and make the analysands reanalyse...

[tanya]

• Do not know what "Page work area should be centered as it was before." means.

[deyan]

Changed 4 months ago by deyan ¶

For the full behaviour, see BOOK_WINDOW_R1

[tanya]

The way the Page Work Area will be centered:

The rectangle Z of the scene that will be visible for the user will be the union of:

• Rectangle X with width equal to the width of the panel provided by the book window and height equal to the height of the panel provided by the book window.
• Rectangle Y - the bounding rectangle.
• The center of rectangle X will be the same as the center of rectangle Y.

The scrollbars should be moved to the most right point when frame is moved so much to right that the rectangle Z is resized.
The scrollbars should be moved to the most left point when frame is moved so much to left that the rectangle Z is resized.
When rectangle Z is not resized, then the scrollbars will remain on the same positions.

[pap]

Patch with changes made in the implementation review

[pap]

• Misbehavior - the desktop book has scrollbars remaining even when the the document windows fit without scrollbars
• The getParent().getParent().... thing seems quite bad. Also the first parent JScrollPane is at different depth for the BookDocViews in windows and in the desktop book. A little improvement in the im-re patch.
• I think that the issue with the desktop scrolls has alot in common with the previous non-pro-lib size tracking.
• The paddings were too big - corrected a little in the patch
• There is some bad visual experience with scrollbars when sizing windows down

[stefan]

The main idea of the design is preserved. All of the points from the implementation review are considered/fixed:

1. This problem was due to wrong use of getParent().getParent() (in order to get JScrollPane parent class - i.e. the desktop book has JScrollPane parent on a different level than ordinary book has.
2. The little improvement is the actual fix for the misbehavior described above, and it is moved as a public method (see BaseSceneVisual class).
3. This is explained in my previous two points.
4. Implementor is thankful for that :).
5. This was due to bad calculating of a preferred size of the ScenePanel. It should have been the bounds of the scene, not the actual size of the panel. The fix is in the patch.

Implementation: 1968_im_fi_ stefan.patch.

[pap]

• There are two issues that occur with the book desktop
  • When Sophie is started and no books are opened if you insert frame and try to drag it to the right the frame hides behind the flap.
  • On the other hand if you create/open book and move its window to the left, when there is frame on the book desktop if you try to move it to the right at some point it disappears.
• When the flaps are hidden, the scrollbars of the book desktop don't appear at all.
• Write yourself as an implementation owner in the appropriate field.

[stefan]

Two issues are resolved, although I don't like at all the the solution of the hiding flaps problem (see PageWorkArea's swing component). I has constants dependent padding, which I don't prefer at all, but I can't see no other solutions. If the integrators have another alternative solutions, I would be very thankful.

"When the flaps are hidden, the scrollbars of the book desktop don't appear at all." - this, I couldn't reproduce at all - maybe it is resolved with the previous two issues.

Implementation code - 1968_im_fi_ stefan_2.patch

[meddle]

Closing all the tickets before M Y1