Community
Participate
Working Groups
Zooming in and out is a general issue for editors and viewers. It would be good to have Platform UI providing the relevant command definition and shortcuts, and have editors implementing a handler for it.
+1 Contributions welcome
New Gerrit change created: https://git.eclipse.org/r/49998
New Gerrit change created: https://git.eclipse.org/r/50042
With the 2 suggested Gerrit changes, there is introduction of general zoom in/out commands + some basic and dirty handlers that validate it for text editors. I believe the part about commands can be merged right now, whereas some help on how to use better API in handlers would be welcome.
Note that since ideally GEF (and maybe some other projects) would adopt this command, it's better to merge its definition early after Mars to leave time to such projects to adopt it.
I think this is a great idea, Mikael, and I love that you've added example implementations for the general fonts. I started to comment on the approach but those got lost in a browser crash or something. But I think the command definitions need a bit more thinking. Most apps with Zoom In/Out also have a Restore Zoom (1:1), and other apps provide absolute zooms and relative zooms. If we're going to solve this, our solution should flexible enough to provide some way to encode all of these. From what I've seen, apps tend to offer: * Incremental zooms in and out — such as what you've got in your current proposal * Restore Zoom / Actual Size (often bound to M1+0) * Fit to Window, Fit to Window Width and Fit to Window Height * Percentags relative to original size (50%, 150%, 200%, 400%, 800%) * Zoom to Selection (magnify currently selected objects) So it would seem to be good to have at least one (possibly optional?) command parameter. And might it make sense to combine these into a single command (e.g., org.eclipse.ui.zoom) where zooming in and out are represented by positive or negative numbers? Perhaps we could add three optional command parameters * level: either an absolute number (0 = actual size, other numbers are app-dependent), or a positive or negative integer to serve as an increment. Generally additive, so zoom:+1 zoom:+1 zoom:+1 followed by zoom:-2 = zoom:+1. * percentage: a positive integer where 100 = 100% (actual size); so < 100 = smaller, > 100 = bigger * relativeTo: a string. Pre-defined include "selection", "fit", "fitWidth", "fitHeight" I'm not sure this is flexible enough though. Thinking about your font-size implementations, I could see having absolute sizes useful (e.g., "Zoom Text to 16px"); perhaps that's specialized enough to warrant a separate command?
(In reply to Brian de Alwis from comment #6) > From what I've seen, apps tend to offer: > * Incremental zooms in and out — such as what you've got in your current > proposal > * Restore Zoom / Actual Size (often bound to M1+0) > * Fit to Window, Fit to Window Width and Fit to Window Height > * Percentags relative to original size (50%, 150%, 200%, 400%, 800%) > * Zoom to Selection (magnify currently selected objects) For my usage of Eclipse IDE, and comparing on how I use zoom on Firefox, the only very useful one to me is the incremental zoom in/out. I believe most diagram framework (GEF and family) already have commands or actions for pecentage-based zooms and fit to windows. Since those mostly make sense for diagrams, it seems fair to just leave them to GEF. Zoom to selection isn't really a zoom thing, it's a navigation one, just like "open declaration" or "Drill down"
(In reply to Mickael Istria from comment #7) > For my usage of Eclipse IDE, and comparing on how I use zoom on Firefox, the > only very useful one to me is the incremental zoom in/out. If these are IDE-specific then we should retitle the bug and rename the commands. Because then we're not trying to provide general commands. And that's ok But the point of commands were to embody the user intention and to allow the implementations to vary. > Zoom to selection isn't really a zoom thing, it's a navigation one, just > like "open declaration" or "Drill down" Zoom to Selection is Fit to Selected Object's Width and Height.
What's better with a single parameterized command than with multiple ones? Since we have several differenct operations associated to zoom, we could prefix commands with org.eclipse.ui.zoom, so that would be: * org.eclipse.ui.zoom.in (or org.eclpse.ui.zoom.zoomIn) * org.eclipse.ui.zoom.out (or org.eclpse.ui.zoom.zoomOut) * org.eclipse.ui.zoom.restore * org.eclipse.ui.zoom.setPercentage * org.eclipse.ui.zoom.fitToWindow * org.eclipse.ui.zoom.fitToSelection
(In reply to Mickael Istria from comment #9) > What's better with a single parameterized command than with multiple ones? > Since we have several differenct operations associated to zoom, we could > prefix commands with org.eclipse.ui.zoom, so that would be: > * org.eclipse.ui.zoom.in (or org.eclpse.ui.zoom.zoomIn) > * org.eclipse.ui.zoom.out (or org.eclpse.ui.zoom.zoomOut) > * org.eclipse.ui.zoom.restore > * org.eclipse.ui.zoom.setPercentage > * org.eclipse.ui.zoom.fitToWindow > * org.eclipse.ui.zoom.fitToSelection I also would think a single parameterized command is better. Multiple feel like overdesign
(In reply to Lars Vogel from comment #10) > I also would think a single parameterized command is better. Multiple feel > like overdesign A single command that does everything feel like too coarse-grained to me. Also, let's imagine a user types "zoom" in the quick fix, what would be the result of single command vs multiple commands?
(In reply to Mickael Istria from comment #11) > (In reply to Lars Vogel from comment #10) > > I also would think a single parameterized command is better. Multiple feel > > like overdesign > > A single command that does everything feel like too coarse-grained to me. > Also, let's imagine a user types "zoom" in the quick fix, what would be the > result of single command vs multiple commands? Maybe a combination of both approaches? For example a zoon out command with an option parameter, which could be used to define a fixed value or percentage. If not specified, a fixed increase is used.
(In reply to Lars Vogel from comment #12) > Maybe a combination of both approaches? For example a zoon out command with > an option parameter, which could be used to define a fixed value or > percentage. If not specified, a fixed increase is used. In general, percentage are actually absolute. One does not zoom out of X%, but instead set zoom level to X%. If you look at how firefox, gimp and family work, there never seems to be a parameter for the zoom in and out command (from user POV). I don't believe Eclipse would need one. In order to avoid overdesign, could we proceed with some iterative approach? First, get functional zoom in and out commands, that work on both text and diagrams; and then see whether the need for a fitToWindow and others actually pops up in the platform.
(In reply to Mickael Istria from comment #9) > What's better with a single parameterized command than with multiple ones? > Since we have several differenct operations associated to zoom, we could > prefix commands with org.eclipse.ui.zoom, so that would be: The problem with multiple commands is that a plugin can't be certain that they've covered off all zoom possibilities: they can only cover the zooms that they know of at development time. Each new zoom command increases the probability of a mismatch between the plugin's custom zoom handlers and any other handler implementations that may have been found. Consider these GEF-based diagram editors. They have an existing set of zoom commands. We'll be adding your new zoom handlers. Now there are two sets of "Zoom" likely to be found in the menus when their diagram editor is found. Say now we add "Zoom to Fit Window". It would make sense for this diagram editor to provide an implementation. But they don't have (and couldn't have) an implementation. If they are lucky, there is no other applicable handler and so the command will is greyed out and inaccessible from the Quick Access. But if there is another handler (e.g., perhaps the workbench provides a handler to zoom the current part) then we now a mis-fit between the diagram editor's other zoom handlers and the workbench's handler. This is important as these zoom commands may subsequently be bound in the UI (and are certainly available from the Quick Access).
The user-story here: provide zoom in and zoom out commands for text editors. Should I retitle this issue or create a newer one? I wouldn't mind having new org.eclipse.text.zoomIn and org.eclipse.text.zoomOut commands as a first iteration,and than, if it still seems interesting enough, refactor that before Neon release to align Text and Graphical zooms.
(In reply to Mickael Istria from comment #13) > In order to avoid overdesign, could we proceed with some iterative approach? Onderdesign is an equally bad problem. (In reply to Mickael Istria from comment #11) > Also, let's imagine a user types "zoom" in the quick fix, what would be the > result of single command vs multiple commands? I missed this comment: my take would be to pop up a dialog that offered the available options. There's some app I use that does this, but I can't remember off hand.
(In reply to Brian de Alwis from comment #16) > (In reply to Mickael Istria from comment #13) > > In order to avoid overdesign, could we proceed with some iterative approach? > > Onderdesign is an equally bad problem. Making a 1st working iteration that would already deliver value to users doesn't prevent to improve design in next iterations. What I'm afraid of is that because of the time it takes to agree on something, the zoom in/out on text just get delayed very late, putting it at risk for Neon. I'm mot saying that other kinds of zoom are useless, but I believe they don't deliver as much value to users compared to current state (GEF already offers most of them when it makes sense, and I can't imagine a user story for restore/zoom to percentage/fir to selection in case of Text or Form editors), so I don't believe we should let them slow down delivery of zoom in/out on text editors.
(In reply to Brian de Alwis from comment #8) > (In reply to Mickael Istria from comment #7) > > For my usage of Eclipse IDE, and comparing on how I use zoom on Firefox, the > > only very useful one to me is the incremental zoom in/out. > > If these are IDE-specific then we should retitle the bug and rename the > commands. Because then we're not trying to provide general commands. And > that's ok +1 I think we should rename the commands. Zoom seems to trigger a controversal discussion. What about if we relabel the commands to "Increase font size" and "Decrease font size"?
(In reply to Lars Vogel from comment #18) > +1 I think we should rename the commands. Zoom seems to trigger a > controversal discussion. What about if we relabel the commands to "Increase > font size" and "Decrease font size"? What about image/viewport related zooms like in diagram editors etc? "Font" names will not fit.
(In reply to Andrey Loskutov from comment #19) > (In reply to Lars Vogel from comment #18) > > +1 I think we should rename the commands. Zoom seems to trigger a > > controversal discussion. What about if we relabel the commands to "Increase > > font size" and "Decrease font size"? > > What about image/viewport related zooms like in diagram editors etc? "Font" > names will not fit. The renamed commands should have a very narrow focus, only allow to change the font size.
I created bug 476037 to focus on having a good implementation for Text editors. So we can keep this bug for standardization of the Zoom (for diagrams, text and maybe others) commands later.
Dani, please try to review for M3.
(In reply to Lars Vogel from comment #22) > Dani, please try to review for M3. Dani already committed to review patch for bug 476037. The patch I suggested initially for the current bug has been more or less vetoed by Brian. As of now, I don't commit on providing a patch that fits Brian request by M3. So unless someone else want to commit in fixing it for M3, it seems more realistic to unset the target version.
(In reply to Mickael Istria from comment #23) > (In reply to Lars Vogel from comment #22) > > Dani, please try to review for M3. > > Dani already committed to review patch for bug 476037. Sorry, my comment was planned for Bug 476037.
So what's the status of this request / contribution ? On Windows, there's more or less a standard for zooming - Ctrl+Mousewheel works nicely in Chrome, Firefox, Windows Explorer, Notepad++ and many other programs. That's essentially what I'd love to see in Eclipse too. The use-case is Code Reviews or Beamer Presentations where somebody wants to (perhaps temporarily) show editor contents in a larger font. I see less of a demand for zooming other views. That said, what's missing for making this happen based on Mickael's proposal ? CQ:WIND00-WB4-6179
(In reply to Martin Oberhuber from comment #25) > So what's the status of this request / contribution ? A patch to implement Zooms on Text Editors is being polished to get in M3 in best case. See bug 476037 and related pull request. The shortcuts assigned to those zooms are Ctrl+ and Ctrl-. The "generification" of zoom is something we can consider later, once we have GEF zoom and Text zoom (and maybe others) implemented. It will be easier to find out what's generic and what's not. > On Windows, there's more or less a standard for zooming - Ctrl+Mousewheel > works nicely in Chrome, Firefox, Windows Explorer, Notepad++ and many other > programs. That's essentially what I'd love to see in Eclipse too. Yes, I agree. However, there are some issues: * It's not easy to do a shortcut involving MouseWheel in Eclipse AFAIK * The Ctrl+MouseWheel is already taken for a "big/fast scroll" As I mentioned earlier, I'd be in favor of moving the fast scroll to Shift+MouseWheel (I believe it matches correctly the semantic of Shift key modifier) and to leave the Ctrl+MouseWheel to zoom. I don't know how possible/easy/difficult it would be to change that. I personally don't plan to work on it right now, at least not until the patch for text editors isn't finalized and merged. > That said, what's missing for making this happen based on Mickael's proposal > ? There is some progress happening on bug 476037.
(In reply to Mickael Istria from comment #26) > (In reply to Martin Oberhuber from comment #25) > > So what's the status of this request / contribution ? > > The "generification" of zoom is something we can consider later, once we > have GEF zoom and Text zoom (and maybe others) implemented. It will be > easier to find out what's generic and what's not. +1.
So new we actually have at least 2 distinct sets of commands providing zoom: * one in Platform Text, that increase/decrease font size * one in GEF to change the scale or ratio (I don't know the exact name). We can already see some "collision" in the Key Binding preference page. It seems to be the right time to consider some unified commands, that we could reuse for unified shortcuts and menus (see bug 483465). What would be the right host to define those commands? org.eclipse.ui.workbench? And would some simple org.eclipse.ui.workbench.zoomIn and org.eclipse.ui.workbench.zoomOut fit?
(In reply to Mickael Istria from comment #28) > So new we actually have at least 2 distinct sets of commands providing zoom: > * one in Platform Text, that increase/decrease font size > * one in GEF to change the scale or ratio (I don't know the exact name). > We can already see some "collision" in the Key Binding preference page. > > It seems to be the right time to consider some unified commands, that we > could reuse for unified shortcuts and menus (see bug 483465). > What would be the right host to define those commands? > org.eclipse.ui.workbench? > And would some simple org.eclipse.ui.workbench.zoomIn and > org.eclipse.ui.workbench.zoomOut fit? From GEF's point of view, zoom-in and zoom-out actions would be sufficient, as these are the only ones currently implemented. In addition, however, there is also a zoom contribution item that adds zoom shortcuts (per combo box) for different zoom levels (50%, 75%, 100%, 150%, 200%, 250%, 300%, 400%, Page, Width, Height). However, as we do not want to break API, GEF 3.x would probably not benefit from adding additional actions for some of these shortcuts (and they are harmless, as they don't interfere with other actions). Taking the GEF4 viewpoint, I could think of additional zoom actions like "zoom-to-fit", "zoom-to-original-size", or "zoom-to-selection", which in the best place would already be defined in some generic place. W.r.t. the right host, why not add them to org.eclipse.ui.actions.ActionFactory?
*** Bug 507660 has been marked as a duplicate of this bug. ***
*** Bug 528217 has been marked as a duplicate of this bug. ***
