Community
Participate
Working Groups
The zoom contributions provided by ZoomManager to fit zoom level to height/width/page should take the minimum zoom level into account. Currently they only restrict by the maximum. for example: if a very tall figure is on the page, and zoom is set to 'Page', then the zoom might actually get set to below the minimum zoom level such that it actually fits on the page (in my particular case, 8%). Then, when the user selects the zoom dropdown combo, the zoom is automatically updated to the actual minimum (default is 50%).
(In reply to comment #0) > The zoom contributions provided by ZoomManager to fit zoom level to > height/width/page should take the minimum zoom level into account. Currently > they only restrict by the maximum. > > for example: if a very tall figure is on the page, and zoom is set to 'Page', > then the zoom might actually get set to below the minimum zoom level such that > it actually fits on the page (in my particular case, 8%). Then, when the user > selects the zoom dropdown combo, the zoom is automatically updated to the > actual minimum (default is 50%). Chris, while it has been quite some time since you reported this issue, may I ask what you mean with "is automatically updated". Looking at the logic example, the zoom behavior seems to be quite natural and consistent.
(In reply to comment #1) > (In reply to comment #0) > > The zoom contributions provided by ZoomManager to fit zoom level to > > height/width/page should take the minimum zoom level into account. Currently > > they only restrict by the maximum. > > > > for example: if a very tall figure is on the page, and zoom is set to 'Page', > > then the zoom might actually get set to below the minimum zoom level such that > > it actually fits on the page (in my particular case, 8%). Then, when the user > > selects the zoom dropdown combo, the zoom is automatically updated to the > > actual minimum (default is 50%). > > Chris, while it has been quite some time since you reported this issue, may I > ask what you mean with "is automatically updated". Looking at the logic > example, the zoom behavior seems to be quite natural and consistent. Using Eclipse 3.4.1 (because that's what I have handy - I suspect it's still reproducible in 3.6, since this was originally submitted against 3.1), here's my repro steps: 1. Create a new logic example (emptyModel1.logic) 2. Change the zoom level to 50% 3. Add some various objects and arrange them such that you need to scroll both horizontally and vertically at this zoom level to see them (ie: one in the upper left, one in the lower right). 4. Change the zoom level to "Page" - zoom level changes to show a percentage < 50% 5. Click on the zoom combo box - without actually selecting a new value, zoom is automatically changed to 50%, and the page re-renders. Try repeating these steps with only one object - in step 4, selecting "Page" changes the zoom level to 400%, and step 5 does not change the zoom level.
To be clear - step 4/5 is where the inconsistency is - if zoom to "Page" is below the minimum zoom level, it should choose the minimum. If this is not the case, then selecting the zoom combo box (and not selecting a new value) should not cause the zoom level to change and page to re-render.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > The zoom contributions provided by ZoomManager to fit zoom level to > > > height/width/page should take the minimum zoom level into account. Currently > > > they only restrict by the maximum. > > > > > > for example: if a very tall figure is on the page, and zoom is set to 'Page', > > > then the zoom might actually get set to below the minimum zoom level such that > > > it actually fits on the page (in my particular case, 8%). Then, when the user > > > selects the zoom dropdown combo, the zoom is automatically updated to the > > > actual minimum (default is 50%). > > > > Chris, while it has been quite some time since you reported this issue, may I > > ask what you mean with "is automatically updated". Looking at the logic > > example, the zoom behavior seems to be quite natural and consistent. > > Using Eclipse 3.4.1 (because that's what I have handy - I suspect it's still > reproducible in 3.6, since this was originally submitted against 3.1), here's > my repro steps: > 1. Create a new logic example (emptyModel1.logic) > 2. Change the zoom level to 50% > 3. Add some various objects and arrange them such that you need to scroll both > horizontally and vertically at this zoom level to see them (ie: one in the > upper left, one in the lower right). > 4. Change the zoom level to "Page" - zoom level changes to show a percentage < > 50% > 5. Click on the zoom combo box - without actually selecting a new value, zoom > is automatically changed to 50%, and the page re-renders. > > Try repeating these steps with only one object - in step 4, selecting "Page" > changes the zoom level to 400%, and step 5 does not change the zoom level. With the current cvs HEAD (where nothing related to zooming has actually changed compared to 3.6.1), I cannot reproduce what you describe in step 5 (I am working on a Mac), that is nothing gets zoomed by simply clicking the combo. Could you try to reproduce it with the 3.6.1 version of the logic example? What I can reproduce (with a single element) is that the zooming to page is restricted by the maximum zoom level of 400%, while the minimum zoom level is (of course) not restricted by 50%. Do you think that to be inconsistent as well?
(In reply to comment #4) > With the current cvs HEAD (where nothing related to zooming has actually > changed compared to 3.6.1), I cannot reproduce what you describe in step 5 (I > am working on a Mac), that is nothing gets zoomed by simply clicking the combo. > Could you try to reproduce it with the 3.6.1 version of the logic example? > > What I can reproduce (with a single element) is that the zooming to page is > restricted by the maximum zoom level of 400%, while the minimum zoom level is > (of course) not restricted by 50%. Do you think that to be inconsistent as > well? It is an inconsistency, but it's a less important issue. To be honest, it would take some time for me to validate using 3.6.1 on Windows, and we've long ago overridden ZoomManager in our applications, so this is rather low on my priority list. If you're able to verify this with HEAD or 3.6.1 on Windows*, I'm ok to mark this bug as WORKSFORME or something. Thanks Chris (*I have noticed several things that often work one way on Windows and another way on Mac, often due to slightly different ordering of events from SWT, so since this bug was found on Windows, it should be validated on Windows...)
(In reply to comment #5) > (In reply to comment #4) > > With the current cvs HEAD (where nothing related to zooming has actually > > changed compared to 3.6.1), I cannot reproduce what you describe in step 5 (I > > am working on a Mac), that is nothing gets zoomed by simply clicking the combo. > > Could you try to reproduce it with the 3.6.1 version of the logic example? > > > > What I can reproduce (with a single element) is that the zooming to page is > > restricted by the maximum zoom level of 400%, while the minimum zoom level is > > (of course) not restricted by 50%. Do you think that to be inconsistent as > > well? > > It is an inconsistency, but it's a less important issue. To be honest, it > would take some time for me to validate using 3.6.1 on Windows, and we've long > ago overridden ZoomManager in our applications, so this is rather low on my > priority list. > > If you're able to verify this with HEAD or 3.6.1 on Windows*, I'm ok to mark > this bug as WORKSFORME or something. > > Thanks > Chris > > (*I have noticed several things that often work one way on Windows and another > way on Mac, often due to slightly different ordering of events from SWT, so > since this bug was found on Windows, it should be validated on Windows...) Chris, on Windows XP I can reproduce step 5) with GEF 3.6.1 and the logic example so this still seems to be an issue.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > With the current cvs HEAD (where nothing related to zooming has actually > > > changed compared to 3.6.1), I cannot reproduce what you describe in step 5 (I > > > am working on a Mac), that is nothing gets zoomed by simply clicking the combo. > > > Could you try to reproduce it with the 3.6.1 version of the logic example? > > > > > > What I can reproduce (with a single element) is that the zooming to page is > > > restricted by the maximum zoom level of 400%, while the minimum zoom level is > > > (of course) not restricted by 50%. Do you think that to be inconsistent as > > > well? > > > > It is an inconsistency, but it's a less important issue. To be honest, it > > would take some time for me to validate using 3.6.1 on Windows, and we've long > > ago overridden ZoomManager in our applications, so this is rather low on my > > priority list. > > > > If you're able to verify this with HEAD or 3.6.1 on Windows*, I'm ok to mark > > this bug as WORKSFORME or something. > > > > Thanks > > Chris > > > > (*I have noticed several things that often work one way on Windows and another > > way on Mac, often due to slightly different ordering of events from SWT, so > > since this bug was found on Windows, it should be validated on Windows...) > > Chris, on Windows XP I can reproduce step 5) with GEF 3.6.1 and the logic > example so this still seems to be an issue. The same holds for Windows 7, where I could as well reproduce it.
