This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||Need ability to enlarge scene area without widget moving|
|Product:||platform||Reporter:||Sergey Petrov <sj-nb>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||101523|
|Bug Blocks:||105060, 131682, 153585, 153804|
Description Sergey Petrov 2007-06-03 07:12:44 UTC
It's hard to create big scene now, for example if I have widget on right border and want to place new one righter I have to place it over existing and drag it, In most cases it's much easier to scroll(if scroll exists or even if not exists with "horizontal" wheel) righter to get some free area out of existed "busy" area and continue drawing here. It's good if I will be able to disable auto collapsing of scene to non-empty area only. It's just another use case, if I drag rightest widget to left to place something on it's place I'll not get free space I'll get collapsing scene. Overview still can use non-free area as view border (or full scrollable area, don't see a problem either way). In current logic just wonder why scene doesn't collapse over (0,0) point, for example I can workaround current limitation by dragging some widget to (-1000,-1000) and have a lot of free not collapsed space.
Comment 1 David Kaspar 2007-06-03 14:05:56 UTC
When you use LayerWidget, then it is always resolved at [0,0] point and therefore this points is always at the scene. I think that for your use case you can use scene border. E.g.: Scene.setBorder (BorderFactory.createOpaqueBorder (50, 50, 50, 50); Using this the scene will always have an empty border which should be sensitive to any mouse input. Please, could you check whether it works for you? Thanks.
Comment 2 Sergey Petrov 2007-06-03 16:26:43 UTC
Yes, I have at least some free space now, but got strange behavior on left border (may be the same on top, didn't check yet), or may be starnge difference between left and right borders with widget moved to right border selection works without jumps but on left border even with visible free space righter my widget jumps rigth after resize border addition
Comment 3 David Kaspar 2007-06-04 13:10:02 UTC
The issue with jumping widget is very similar to issue #105009. The problem is that by shrinking a top-left-most widget in negative coordinates, you are making a scene to be smaller. This has an impact on resolving of mouse-location while an AWT events are processed. This should be automatically resolved when issue #101523 is fixed.
Comment 4 David Kaspar 2007-06-05 10:17:54 UTC
Settings as fixed since the issue #101523 has been fixed. Please, could you verify it with tomorrow's build. If the problem still remains, reopen the issue. Thanks.
Comment 5 Sergey Petrov 2007-06-05 19:50:03 UTC
Not sure why you have marked the issue(enhancement) as resolved, some comments are about additional issues, but main idea is located in Summary "Margin" only helps a bit here
Comment 6 David Kaspar 2007-06-07 13:01:51 UTC
Sergey, could you check the latest behaviour of the movement in tomorrow's build? The logic has been reimplemented. Still the top-left and bottom-right borders are shrinking in necessary. There is a new "package-default" method (not in public API) that allows to disable this scene shrinking behaviour. Could you try behaviour of your application while you have a scene with "myScene.setExtendSceneOnly (true);" call? Thanks.
Comment 7 Sergey Petrov 2007-06-19 10:13:12 UTC
the method has package visibility, I can't use it
Comment 8 David Kaspar 2007-06-19 10:42:38 UTC
Yes, the Scene.setExtendSceneOnly method has package visibility since it is not included in the public API. I have not added it to the API since I do not know whether it is useful. Please, could you change the modify the method in your sources and try it? Or you can use Java reflection to change access-level to "public". P.S.: There is also another solution. Drawing applications are often using predefined infinite canvas e.g. with boundary=[-10000,-10000,20000,20000]. Then the canvas is big enough for regular work and you do not have this expansion problem since the visualization is mostly done in the center of the canvas. This solution would require to set a minimum boundary of a scene (new Scene.setMinimumBounds(Rectangle):void API method).
Comment 9 Sergey Petrov 2007-06-19 11:35:20 UTC
tried with public setExtendSceneOnly, In my opinion I got more usual/natural feedback on my drag actions, i.e. on drag away from border widget is moved away from border so I can have some space between border and the widget the only high visible issue is satellite view which uses scene full border instead of "buzy/filled" scene border
Comment 10 Sergey Petrov 2007-06-19 14:19:47 UTC
And one more possible issue(didn't try yet), in my opinion expanded scene border shouldn't be serialized in xml or in any other way (i.e. after scene reopening scene border should cover widgets and nothing more), but of cause I can set preferred border to null after loading
Comment 11 David Kaspar 2007-06-19 15:17:35 UTC
Re: Satellite view: Yes, you are right - it is because the satellite view is showing whole scene. This has to be solved even when the "Scene.setMinimumBounds" method is introduced. I will try to implement the patch for the issue after the M10. The patch will contain both Scene.setExpandSceneOnly and Scene.setMinimumBounds methods.
Comment 12 Sergey Petrov 2007-07-03 14:21:17 UTC
got bug with the feature, if zoom out scene don't resize and remains "big", it's visible with overview and also possible to scroll far right-bottom