Community
Participate
Working Groups
To reproduce: - Create a GEF logic example. - Add a LED. - Grab the LED in the center, drag the shape to the right side of the viewport, and hover near the very edge of the viewport. Notice that autoscrolling will occur. - Now repeat, but grab the LED close to the right edge of the LED instead. In this scenario, autoscrolling does not occur. I did some investigation into this issue. If you grab the shape in the middle, when you get close to the edge, the viewport scrolls a bit which makes the viewport bigger to the right (i.e. you could scroll further right). In the ViewportAutoexposeHelper.step() method, the call to port.setViewLocation(loc) at the bottom, then causes the viewport to move further to the right and this starts off the autoscrolling. If you grab the shape on the right side (or use the accessibility handles to move the shape), the viewport does not scroll when you get to the autoscroll trigger area because the shape is fully exposed. So then in the ViewportAutoexposeHelper.step() method, the call to port.setViewLocation(loc) does not change the horizontal range model value because the code in DefaultRangeModel.setValue() does not let you scroll past he maximum value. I think what needs to be done is that the DefaultRangeModel's maximum value needs to be changed. I played with changing the bounds of the viewport content's, but I couldn't get this to work.
The solution here is to use some margin on the feedback layer that stretches that layer beyond the minimum rectangle needed to show the feedback.
Randy your solution is a work-around or some suggestions for a patch? I could try to create a patch, but I would need some more information, where to look at.
My suggestion was to just grab the feedback layer, and set the border to a margin border.
Created attachment 98054 [details] Suggested fix I added a MarginBorder of 10 to the FeedbackLayer. Randy, do you know of any side-effects with this fix?
> I added a MarginBorder of 10 to the FeedbackLayer. Randy, do you know of any > side-effects with this fix? Perhaps. If you have a shape that is less than 10 pixels from the left(in the case of a freeform layer) or right edge of the diagram, and you resize it vertically, then the horizontal scrollbar would appear/enable and then disappear/disable after you're done resizing. Typically a GEF application should configure its primary layer to have some amount of margin/insets on it. Whatever that amount is would also be used for the feedback. I think the logic example uses 5.
Hmmm, if there isn't a margin border on the primary layer, but just on the feedback layer then the scrollbars appear then disappear as you indicated when resizing a shape close to the edge. However, if there IS a margin border on the primary layer as well then the scroll bars stay when the shape is resized to be close to the edge although they don't need to show at all. I'm not sure what the best solution is.
(In reply to comment #6) > Hmmm, if there isn't a margin border on the primary layer, but just on the > feedback layer then the scrollbars appear then disappear as you indicated when > resizing a shape close to the edge. However, if there IS a margin border on > the primary layer as well then the scroll bars stay when the shape is resized > to be close to the edge although they don't need to show at all. That was sort of my point. We can't arbitrarily choose 10 on the feedback layer, unless we are going to choose the margin for the primary layer so that it is the same. It's best to leave it up to the client to decide what is right for them. We don't even know if the client's diagram has scrollbars at all.
