-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use SourceFigure for ScrollableThumbnail handling #236
Conversation
I tested it in Archi and it's not working properly if the diagram is zoomed less than or greater than 100% and a diagram object has negative co-ordinates (we use a For example in
Therefore this isn't going to work in this case. |
@Phillipus this is interesting I can not reproduce the behavior in 4diac IDE. I guess our incremental growing drawing canvas with the border is behaving differently. That means I have to duplicate the code for 4diac IDE, because I don't see a clear strategy in making the ScrollableThumbnail more adaptable. |
@azoitl I'm seeing an incorrect size and position for the selection figure (the blue rectangle) if the source diagram is at zoom level > 100%. |
Add the following to And ensure the zoom level > 100%.
You can then see that The viewport handles different zoom levels and negative co-ordinates whereas the source figure does not. |
@Phillipus in 4diac IDE for both my uses cases it behaves correct. Seems we are doing something special. So this fix is doomed to day. Would you be ok if I would make the three methods in question:
protected? This would greatly reduce my need to duplicate code and I would not break any other application. |
I don't know what. Our diagrams use a
I can't see a problem with that. |
We use an extended ScalableFrefromRootEditPart but with a special root figure that gives more the look and file as you have i with Draw.io. Where you have a clear border and an incremental growing canvas. I have on my todo list to bring this to GEF Classic but haven't found the time yet.
Then I will change my PR to that. |
I think I know why this is. At the point where we create the Viewport vp = (Viewport)editPart.getFigure();
ScrollableThumbnail thumbnail = new ScrollableThumbnail(vp);
thumbnail.setSource(editPart.getLayer(LayerConstants.PRINTABLE_LAYERS)); If I do this, your code works: Viewport vp = (Viewport)editPart.getFigure();
ScrollableThumbnail thumbnail = new ScrollableThumbnail(vp);
thumbnail.setSource(vp.getContents()); But we prefer to set the source figure to the printable layer (and a Google search shows this is how others do it) |
Thx for checking and spending so much time on it. This really helped me to better understand this. In the end introducing the change only on 4diac IDE side seems the much better option. |
I agree. At the very least we can consider that the viewport contents figure may be different than the source figure. |
The SourceFigure in the ScrollableThumbnail may be different then the viewport's content used. In that cases for determining the size and position of the Selector different calculations may be required.
11205ed
to
24385a3
Compare
I think with the latest update I addressed that nicely. @Phillipus I now also know why we are not using the printable layers: If you use the whole viewport contents also selection feedback and dragging is shown in the outline. This can help some users to orient themselves. You may want to give it a try. |
That's why I don't use it, because I don't like that. ;-) Maybe I'll change my mind one day. Edit: I tried it again and I see flashing black artefacts in the thumbnail when an object is dragged. |
That is the advantage of the new approach, we can have both our ways.
With the none printable layers? My fix shouldn't have any change on that, or? Do you think we can merge it? |
Sorry, I wasn't clear - I mean I tried your suggestion of "If you use the whole viewport contents also selection feedback and dragging is shown in the outline"
I checked it, and it's only code tidy, protected methods, and a new protected method in |
I expected that. But wanted to be sure that I'm accidentally breaking stuff again.
Great. Then I merge and wait for the build to create the M2 release later today. |
The SourceFigure in the ScrollableThumbnail may be different then the viewport's content used. In that cases the size and position of the Selector was not handled correctly.
If the SourceFigure is the content of the viewport then it behaves as before.
@Phillipus @ptziegler what do you think. For me it behaves now more correct and opens a nice use case for 4diac IDE, where I otherwise would need to copy the whole class, which I found not as nice.
With all the automatic clean-ups, the interesting lines are: 200, 204, 235, & 236.