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.

Bug 129169 - Setting individual zoom levels for X and Y axis
Summary: Setting individual zoom levels for X and Y axis
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Graph (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@platform
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-04 17:01 UTC by maxnitribitt
Modified: 2008-03-11 08:47 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
patch for issue 129169 (38.62 KB, text/plain)
2008-03-04 17:03 UTC, maxnitribitt
Details
2nd version patch for 129169 XYZoom (40.01 KB, text/plain)
2008-03-07 09:14 UTC, maxnitribitt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description maxnitribitt 2008-03-04 17:01:06 UTC
Change API to allow setting individual zoomlevels for X and Y axis. Currently the Scene can only be scaled by a single
zoomFactor that is applied to both X and Y Axis. Some users want to scale by horizontal or vertical axis only. One
example from the vislib mailinglist is a waveform editor with independent horizontal and vertical zoom. My own usecase
is a Genome Browser for visualizing whole chromosomes ( upcoming version of http://www.chipinspector.com ). The only
workaround would be to change size and position of all widgets at once, which is a bad solution when working with large
scenes. Therefore it would be good to add methods for setting zoomFactor for X and Y axis separately.

Proposed Patch:

Currently Scene has a zoomFactor property that is used for both X and Y axis. The attached patch replaces zoomFactor by
zoomFactorX and zoomFactorY including setters and getters. API method setZoomFactor( double zoomFactor ) is changed to
set both zoomFactorX and zoomFactor. Method calls in SceneComponent are changed to use the new getters when scaling the
Graphics2D object. Method calls in ComponentWidget are also changed to use the new getters. 

The only problem is method getZoomFactor. When setting different values for zoomFactorX and zoomFactorY it wouldn't work
correctly. Therefore it is deprecated in the attached patch. The deprecated getZoomFactor method returns zoomFactorX
which is backward compatible. 

Classes still using the deprecated getZoomFactor action: ZoomAction, CenteredZoomAction, MouseCenteredZoomAction,
LevelOfDetailsWidget, TextFieldInplaceEditorProvider

This is my first try to submit a patch, so if something is missing please let me know.

When accepted the patch can be used under the Common Development and Distribution License (CDDL) v1.0 and the GNU
General Public License (GPL) v2 as part of the IDE's code.
Comment 1 maxnitribitt 2008-03-04 17:03:03 UTC
Created attachment 57749 [details]
patch for issue 129169
Comment 2 maxnitribitt 2008-03-07 09:09:51 UTC
I have tested the patch and updated it so it fits in better with less API changes. You can now set zoommode on the scene:

public enum ZoomMode {
        ZOOM_MODE_VERTICAL_ONLY, ZOOM_MODE_HORIZONTAL_ONLY, ZOOM_MODE_BOTH
    }

I think this is the way most users would like to use it. This also works with existing zoomactions and zoomanimators and
 getZoomfactor() and setZoomFactor() work without problems. 

SatelliteComponent also uses the correct Zoomfactors now.

I have also introduced maxZoomFactor and minZoomfactor properties, so zooming can be limited.
Comment 3 maxnitribitt 2008-03-07 09:14:09 UTC
Created attachment 57956 [details]
2nd version patch for 129169  XYZoom
Comment 4 David Kaspar 2008-03-10 15:42:16 UTC
I think it is not necessary to have min-zoom and max-zoom since it would introduce tons-of-methods in Scene class.
Instead I would just introduce a ZoomStrategy that would allow to limit zooming at the user-action level. This would be
enough since the developer has control over the zoom factor when he/she sets it using Scene.setZoomFactor.
Additionally I think it is not necessary to have ZoomModes since all the modes are just combination of zoomfactorx and
zoomfactory.
For accepting the patch, it has to contains additional information e.g. updated spec. version, api-change description,
test, ...
I will try to update the patch as soon as possible when i would have time.
Thanks for patch.
Comment 5 maxnitribitt 2008-03-11 08:47:18 UTC
Thanks for considering the change and for the feedback. 

min and max zoom should not really have been part of this patch and should have been treated separately. I had
introduced them since I needed a solution that works with your ZoomAction. I should have removed them before submitting
the patch. Nevertheless great to hear that you're thinking about a different solution for the problem!

I understand your point about ZoomMode, but it also has some advantages. Of the solutions I was trying, this one is best
in terms of backward compatibility. getZoomFactor and setZoomFactor would still be the single points of access for a
user in most cases. getZoomFactorX and getZoomFactorY are only exposed in the patch to allow access through
SatelliteComponent and maybe could be removed (if ZoomModes were exclusive). API changes could then be kept to a minimum
(only the additional setZoomMode() method and the enum). In addition the patch as is works perfectly with your default
implementations. All other solutions I could imagine would involve more changes for the library and the user. With the
patch as is the only thing a user needs to do is setZoomMode(ZoomMode.ZOOM_MODE_HORIZONTAL_ONLY) and he can use e.g.
createZoomAction() without any further changes to his or your code. 

If I can help writing tests or API change proposals let me know.