Ticket #1968 (closed bug: obsolete)

Opened 10 years ago

Last modified 8 years ago

pwa-centering Page work area should be centered

Reported by: deyan Owned by: stefan
Priority: critical Milestone: M12_RELEASE
Component: uncategorized Version: 2.0
Keywords: Cc:
Category: unknown Effort:
Importance: 80 Ticket_group:
Estimated Number of Hours: 0 Add Hours to Ticket: 0
Billable?: yes Total Hours: 0
Analysis_owners: deyan, tanya Design_owners: tanya
Imp._owners: tanya, stefan Test_owners:
Analysis_reviewers: tanya Changelog: Changelog
Design_reviewers: meddle Imp._reviewers: deyan, meddle, deyan, pap, pap
Test_reviewers: Analysis_score: 2
Design_score: 3.5 Imp._score: 2
Test_score: 0

Description

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

Attachments

pwa-centering-Page-work-area-should-be-centered.patch (28.1 KB) - added by tanya 10 years ago.
centered_pwa.patch (44.5 KB) - added by tanya 10 years ago.
pwa-centering-imre.patch (46.7 KB) - added by pap 10 years ago.
Patch with changes made in the implementation review
1968_im_fi_ stefan.patch (47.1 KB) - added by stefan 9 years ago.
1968_im_fi_ stefan_2.patch (49.2 KB) - added by stefan 9 years ago.
pwa-centering-deni.patch (23.4 KB) - added by deni 9 years ago.

Change History

comment:1 Changed 10 years ago by deyan

  • Status changed from new to s1b_analysis_finished

comment:2 Changed 10 years ago by deyan

For the full behaviour, see BOOK_WINDOW_R1

comment:3 Changed 10 years ago by deyan

  • Priority changed from major to critical

comment:4 Changed 10 years ago by deyan

  • Importance set to 80
  • Summary changed from Page work area should be centered to pwa-centering Page work area should be centered

Batch update from file report_1.csv

comment:5 Changed 10 years ago by tanya

  • Design_owners set to tanya
  • Status changed from s1b_analysis_finished to s2a_design_started
  • Imp._owners set to tanya

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by tanya

  • Status changed from s2a_design_started to s2b_design_finished

comment:8 Changed 10 years ago by meddle

  • Status changed from s2b_design_finished to s2c_design_ok
  • Design_score changed from 0 to 3.5
  • Design_reviewers set to 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

comment:9 Changed 10 years ago by tanya

  • Owner set to tanya
  • Status changed from s2c_design_ok to s3a_implementation_started

comment:10 Changed 10 years ago by tanya

  • Status changed from s3a_implementation_started to s3b_implementation_finished

comment:11 Changed 10 years ago by meddle

  • Status changed from s3b_implementation_finished to s2c_design_ok
  • Imp._score changed from 0 to 2
  • Analysis_reviewers set to tanya
  • Imp._reviewers set to deyan, 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...

comment:12 Changed 10 years ago by tanya

  • Status changed from s2c_design_ok to new
  • Do not know what "Page work area should be centered as it was before." means.

comment:13 Changed 10 years ago by tanya

  • Analysis_score changed from 0 to 2

comment:14 Changed 10 years ago by deyan

  • Status changed from new to s1b_analysis_finished

Changed 4 months ago by deyan ¶

For the full behaviour, see BOOK_WINDOW_R1

comment:15 Changed 10 years ago by tanya

  • Status changed from s1b_analysis_finished to new

comment:16 Changed 10 years ago by tanya

  • Status changed from new to s1b_analysis_finished
  • Analysis_owners changed from deyan to deyan, 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.

comment:17 Changed 10 years ago by tanya

  • Status changed from s1b_analysis_finished to s2a_design_started

Changed 10 years ago by tanya

comment:18 Changed 10 years ago by tanya

  • Status changed from s2a_design_started to s3b_implementation_finished

Changed 10 years ago by pap

Patch with changes made in the implementation review

comment:19 Changed 10 years ago by pap

  • Status changed from s3b_implementation_finished to s2c_design_ok
  • Imp._reviewers changed from deyan, meddle to deyan, meddle, deyan, 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

comment:20 Changed 9 years ago by stefan

  • Owner changed from tanya to stefan
  • Status changed from s2c_design_ok to s3a_implementation_started
  • Changelog set to [wiki:Changelog]

Changed 9 years ago by stefan

comment:21 Changed 9 years ago by stefan

  • Status changed from s3a_implementation_started to s3b_implementation_finished

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.

comment:22 Changed 9 years ago by pap

  • Status changed from s3b_implementation_finished to s2c_design_ok
  • Imp._owners changed from tanya to tanya, stefan
  • Imp._reviewers changed from deyan, meddle, deyan, pap to deyan, meddle, deyan, pap, 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.

Changed 9 years ago by stefan

comment:23 Changed 9 years ago by stefan

  • Status changed from s2c_design_ok to s3a_implementation_started

comment:24 Changed 9 years ago by stefan

  • Status changed from s3a_implementation_started to s3b_implementation_finished

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

Changed 9 years ago by deni

comment:25 Changed 8 years ago by meddle

  • Status changed from s3b_implementation_finished to closed
  • Resolution set to obsolete

Closing all the tickets before M Y1

Note: See TracTickets for help on using tickets.