Community
Participate
Working Groups
Once we have bug fixed, we need a command that gives users an easy way to reset font size, e.g. Ctrl+0 like in Firefox.
(In reply to Dani Megert from comment #0) > Once we have bug fixed, Bug 476037.
Just to be clear about the meaning of reset: 1. Resetting font which is currently set to default would reset default font (and family) 2. Resetting a font that is currently overrides the default (may this default be the default value or an overriden one) would reset the selected font to the current value of the default font. I'm checking because the Preference Page doesn't allow to "reset" a font that is inheriting default (even if the default font is not "reset" per se, ie it has a different value than its "factory" setting).
(In reply to Mickael Istria from comment #2) > Just to be clear about the meaning of reset: > 1. Resetting font which is currently set to default would reset default font > (and family) > 2. Resetting a font that is currently overrides the default (may this > default be the default value or an overriden one) would reset the selected > font to the current value of the default font. > I'm checking because the Preference Page doesn't allow to "reset" a font > that is inheriting default (even if the default font is not "reset" per se, > ie it has a different value than its "factory" setting). Can you try to be more precise? I have trouble to understand what you try to ask e.g. > 1. Resetting font which is currently set to default would reset default font > (and family) If it is already default, then nothing needs to be done, so, no clue what you mean. Similar to other items.
Let's try to be more concrete: * Scenario 1: Set Text Font to size 24, this cascades to most other fonts, including Java. Then, Ctrl+0 on Java editor would restore Text Font and family to its default (10)? * Scenario 2: Set Text Font to size 24, set Java Font to size 36. Ctrl+0 on Java editor would restore Java Font and family to size 24? If so, the general rule would be: 1. Identify the "root font" which is identical (for scenario 1 it would be text font, in scenario 2 Java font) 2. Restore this root font to default value (for scenario 1, it would be the factory 10pts font set as default for the Text Font; for scenrio 2, it would be the 24pts font which is the value of the "defaultsTo" font for the Java font. 3. Apply change to root and cascade to children. Does this seem right?
It should just work like in Firefox: 1. User can configure a Text Font (e.g. Lucida Console 8) 2. User can press Ctrl++ and Ctrl+- to Zoom In/Out 3. When done with the presentation, user can use Zoom Restore (Ctrl+0) to restore the configured Text Font (Lucida Console 8) As a user, I would not expect a Zoom command to touch my preferences (i.e. the current implementation in 4.6 M4 is already problematic). If that's too hard to implement, then I would at least expect the above scenario to work. The Zoom commands can store the cumulative difference from the user's configured font. Zoom Restore use the cumulative difference to restore the font to the size that was used before any Zoom command was used. If the font size preference gets changed by other means (e.g. via the Preferences dialog), the cumulative difference should be set to 0. The default default font size should not be the reset target.
There is no doubt that a "reset zoom" would be useful. (In reply to Markus Keller from comment #5) > As a user, I would not expect a Zoom command to touch my preferences (i.e. > the current implementation in 4.6 M4 is already problematic). Daniel was willing the Ctrl+/- to behave like editing a font in the preference page. I agree that this is the most consistent approach for users since: 1. it allows a "unified" experience of usual preference page vs zoom, both manipulating the same single settings 2. if user needs a font to be changed for readability (in presentation or in day to day development), they most likely prefer the change to be propagated to relevant fonts everywhen in the IDE. Firefox isn't "just" a text editor, in many cases, pages have multiple objects (text, images), of different sizes and styles. The content of different sites are so different that we cannot assume that the wish to zoom on one page is good to be propagated on other pages. Because of this major difference, we cannot assume the have zoom in text editors mimicking Firefox.
Mickael, any plans to provide this for M5 (next week)?
(In reply to Dani Megert from comment #7) > Mickael, any plans to provide this for M5 (next week)? No sorry. I'll try that for M6.
(In reply to Mickael Istria from comment #8) > No sorry. I'll try that for M6. By the way, if anyone else wants to implement it before I do, that would be welcome.
New Gerrit change created: https://git.eclipse.org/r/68289
I don't know how to retrieve the correct "last" default value. Just check my comments in change 68289.
I agree with Markus Keller, that the Ctrl-0 command should *not* reset the font size to the default default. Example scenario: 1. Default default: Font X, size 10 2. User chooses personal font size: Font Y, size 11 3. User wants to present something and therefore temporarily wants to zoom in to ~200% -> Ctrl++ 5 times -> font size 21. 4. User wants to reset the font size to *their* default, size 11. This is not possible. With the current implementation the result would be size 10. And even worse, since the step size is 2, a Ctrl++ afterwards would only help to get to 12, but never to 11, so they'd have to go to the preferences to set the size to 11 again manually. I personally would prefer the following implementation over the current M4 implementation: * Ctrl++/- set a *temporary* offset for the related workspace preference (respecting the same inheritance relationship). * Ctrl+0 resets that offset to 0. * These offsets would not appear anywhere in the preference pages, but of course could possibly be persisted, to survive IDE restarts. As a visual indicator I'd like something like a magnifying glass in the corner of the active editor, for example. This would satisfy all use cases alike: * For those who never touched the default font size in the preferences, the behavior would be the same as in the current implementation. * For those that did, it would behave like expected in the scenario described above.
(In reply to Sebastian Ratz from comment #12) > I personally would prefer the following implementation over the current M4 > implementation: > * Ctrl++/- set a *temporary* offset for the related workspace preference > (respecting the same inheritance relationship). > * Ctrl+0 resets that offset to 0. > * These offsets would not appear anywhere in the preference pages, but of > course could possibly be persisted, to survive IDE restarts. As a visual > indicator I'd like something like a magnifying glass in the corner of the > active editor, for example. The issue with this idea of offset is that it's yet-another-concept for the user to understand and remind about. On the opposite, the cool thing with the current approach of relying fully on preferences/font-registry is that it isn't manipulating or creating something new for the user to understand, it's changing the font size, exactly like the preference page does. It's then quite simple to grok and consistent with all other font related experiences in the IDE. I have the impression that adding such offset and/or having one more indicator somewhere on the screen would break simplicity and consistency. About the user story, I believe there are already good ways to achieve a font reset that make it not worth introducing complexity. Those are just shortcuts to change font size after all, and even if there is no Reset, it's pretty easy to get back to initial state by Ctrl+/- or via preferences. Let's not make it over-complicated for a problem that already has acceptable solutions. (just realized that this is somehow redundant to comment 6)
Users don't have to learn about the Zoom Reset command if they don't want to use it. Sebastian and I gave real use cases that require such a command. I don't think the current zoom level needs to be shown anywhere. (In reply to Felix Otto from comment #11) > I don't know how to retrieve the correct "last" default value. Just check my > comments in change 68289. I've already outlined one possible way to implement this in comment 5. The best solution is probably too hard to implement, since editors expect to just see the font size in the preferences. The workaround is that YOU have to store the correct "last" value before you modify the font size in the Zoom In/Out commands. The added complication is that the user can change the font size on the preference page or in other ways that modify preferences (e.g. via Import, or via a third-party plug-in). Once the Zoom commands have been used, you need to listen to preference changes and reset the offset to 0 if the value in the preferences gets changed by other means. To make this work across restarts, you probably have to store both the original size and the zoomed size. That way, you can implement the Zoom Reset command correctly without having to actually listen to preference changes.
To be honest, given the complexity of this issue (resetting font doing much more than expected) and the fact that restoring font is only a matter of reducing it to the desired size with simple shortcuts, this will most likely not be a top-priority to me so I cannot really commit in having something that work as expected by M7.
Question is: should I remove myself as assignee and/or remove target milestone?
(In reply to Mickael Istria from comment #16) > Question is: should I remove myself as assignee and/or remove target > milestone? That depends on your ambition. You started the feature and I would expect not to run away when it gets complicated, but that's but to you.
(In reply to Dani Megert from comment #17) > (In reply to Mickael Istria from comment #16) > > Question is: should I remove myself as assignee and/or remove target > > milestone? > > That depends on your ambition. You started the feature and I would expect > not to run away when it gets complicated, but that's but to you. It's not really a matter of running away nor ambition, more a matter of initial motivation: I started the zoom feature with the scope I believe is enough for users (In-Out), then you opened this ticket since you think a zoom reset is necessary. I still think it's a nice-to-have but not really something necessary, and my feeling of the ratio of effort vs user-value makes it far from being a priority. I'm not saying I'll never do it, and actually, I'd even like to give it a deeper try one day. But what I just want now is to make clear I do not commit to it for any timeframe at the moment, and that if someone else wants to work on it in the meantime, I'm totally fine with it. That's why I thought about removing me as assignee for the moment.
(In reply to Mickael Istria from comment #18) > (In reply to Dani Megert from comment #17) > > (In reply to Mickael Istria from comment #16) > > > Question is: should I remove myself as assignee and/or remove target > > > milestone? > > > > That depends on your ambition. You started the feature and I would expect > > not to run away when it gets complicated, but that's but to you. > > It's not really a matter of running away nor ambition, more a matter of > initial motivation: I started the zoom feature with the scope I believe is > enough for users (In-Out), then you opened this ticket since you think a > zoom reset is necessary. I still think it's a nice-to-have but not really > something necessary, and my feeling of the ratio of effort vs user-value > makes it far from being a priority. > I'm not saying I'll never do it, and actually, I'd even like to give it a > deeper try one day. But what I just want now is to make clear I do not > commit to it for any timeframe at the moment, and that if someone else wants > to work on it in the meantime, I'm totally fine with it. That's why I > thought about removing me as assignee for the moment. Well, I expect that if you provide a feature you should have the ego to finish it, at least that's my attitude. That is not the case here. From my POV you delivered a partial feature. Anyway, it is what it is. Removing it from your responsibility.
(In reply to Dani Megert from comment #19) > (In reply to Mickael Istria from comment #18) > Well, I expect that if you provide a feature you should have the ego to > finish it, at least that's my attitude. That is not the case here. From my > POV you delivered a partial feature. As explained earlier, I don't prioritize my tasks by my ego, but more by value delivered to users. > Anyway, it is what it is. Removing it from your responsibility. Thank you.
(In reply to Mickael Istria from comment #20) > (In reply to Dani Megert from comment #19) > > (In reply to Mickael Istria from comment #18) > > Well, I expect that if you provide a feature you should have the ego to > > finish it, at least that's my attitude. That is not the case here. From my > > POV you delivered a partial feature. > > As explained earlier, I don't prioritize my tasks by my ego, but more by > value delivered to users. Perfect. What's the data that tells you that this feature is not important? I'm all ears!
(In reply to Dani Megert from comment #21) > Perfect. What's the data that tells you that this feature is not important? > I'm all ears! I've used Zoom In/Out in Firefox for years, and Zoom In/Out in Eclipse IDE for months (since I wrote the first patch), and I never felt the strong need for a reset. Zooming back after a zoom out is reactive and simple enough to not even make me think about a reset. But I know it's only a 1-man metric. What about yours :P ?
(In reply to Mickael Istria from comment #22) > (In reply to Dani Megert from comment #21) > > Perfect. What's the data that tells you that this feature is not important? > > I'm all ears! > > I've used Zoom In/Out in Firefox for years, and Zoom In/Out in Eclipse IDE > for months (since I wrote the first patch), and I never felt the strong need > for a reset. Zooming back after a zoom out is reactive and simple enough to > not even make me think about a reset. > But I know it's only a 1-man metric. What about yours :P ? As you could imagine, I use Ctrl+0 (Reset) a lot.
(In reply to Dani Megert from comment #23) > > I've used Zoom In/Out in Firefox for years, and Zoom In/Out in Eclipse IDE > > for months (since I wrote the first patch), and I never felt the strong need > > for a reset. Zooming back after a zoom out is reactive and simple enough to > > not even make me think about a reset. > > But I know it's only a 1-man metric. What about yours :P ? > > As you could imagine, I use Ctrl+0 (Reset) a lot. Thinking of this again, I must admit that I use this when I accidentally zoomed (scrolled mouse while Ctrl still/already pressed). And to be honest, I did not use zoom in Eclipse so far and hence did not miss Reset there at all. I still believe that it should be there to complete the zoom feature, but on the other hand I must also agree that there are more important bugs among the 250 bugs still marked for 4.6. Mickael, apologies if my previous comments sounded a bit harsh.
Before this bug I did not even know that browsers have Ctrl+0, and I never use it so far. I'm not saying this command will not be important to some users, but I think we have more important issues that we should focus our attention to. The zoom-in and zoon-out was very important to make Eclipse look better during conference presentations, especially compared to other IDE's.
We have to realize we are only simulating zoom here and by that effect cannot really offer a 'reset' better than restoring back to default settings. I for one would love Ctrl+0 to at least go back to do factory settings as a best-compromise fallback. 2nd option would be the temporary offset but that would also have problems if users change their font sizes manually - then the temporary offset will be skewed.
(In reply to Max Rydahl Andersen from comment #26) Comment 14 already answers all of this.
(In reply to Markus Keller from comment #27) > (In reply to Max Rydahl Andersen from comment #26) > Comment 14 already answers all of this. Yes, but we are also running out of time hence why I suggest Ctrl+0 should restore back to default settings and then the more full complete solution outlined in Comment 14 could be added in update 1 or 2.
*** Bug 509109 has been marked as a duplicate of this bug. ***
*** Bug 513303 has been marked as a duplicate of this bug. ***
Hello there, I started 513303 which is now a duplicate of this issue. Before eclipse integrated the "zoom feature" I had written my own simply plugin to do zooming. I was very happy that eclipse has an own implementation and throwed away my quick and dirty approach. But I am missing CTRL + 0 because it's very convenient. Even a CTRL + SHIFT +0 would be cool (video projector quick mode...) When did my implementation I also was simply changing the preferences for default font size - as a quick and dirty way (it worked for me). But when I thought about the use cases I was not convinced about using preferences any more because: - when user wants to change the font size for all he/she will do this inside preferences by her/his own. - when user wants zoom feature he/she wants it NOW for a special use case. (Firefox and Chrome do it the same way: Open a new browser tab and do a CTRL + "+" multiple times and do a "CTRL + t" to open new tab: the new tab has 100% again) So I would prefer an implementation -e.g. inside AbstractTextEditor (its already a GOD class...) - which does this temporary on current editor and gives the editor always 3-4 zoom actions (zoom in, zoom out, zoom back to default, [zoom to video projection mode]) So editor can simply use the preference data for "100%" of its font - without any considerations about font hierarchy etc. At a presentation of code - e.g. on a conference - you will show some files. Okay, you would do zoom every file but I t hink this is okay. When you look at other IDEs - e.g. IntellIJ- they do exactly the same way as I described. Each editor has its own temporary zoom factor. Other editors are not influenced. I think this a very easy and simple approach (KISS) and would be better.
(In reply to Albert Tregnaghi from comment #31) > - when user wants zoom feature he/she wants it NOW for a special use case. > (Firefox and Chrome do it the same way: Open a new browser tab and do a > CTRL + "+" multiple times and do a "CTRL + t" to open new tab: the new > tab has 100% again) Typical use-cases of increasing font size are for presentations or tired readers who want bigger size to ease readability. If a font of size 10 is referenced in multiple places and users grows it to 12, it's most likely because they want this font to be more readable for them, in all contexts. > So I would prefer an implementation -e.g. inside AbstractTextEditor (its > already a GOD class...) - which does this temporary on current editor and > gives the editor always 3-4 zoom actions (zoom in, zoom out, zoom back to > default, [zoom to video projection mode]) > So editor can simply use the preference data for "100%" of its font - > without any considerations about font hierarchy etc. If you introduce a zoom level per editor, it introduces a new concept for users to understand in order to clearly manipulate their font size. Eclipse IDE is often criticized for it's complexity, adding a "rendering ratio" concept to font size isn't making things simpler to apprehend for user. > At a presentation of code - e.g. on a conference - you will show some files. > Okay, you would do zoom every file but I t hink this is okay. I disagree on that, when I increase code with Ctrl+, it means I want bigger text everywhere it can apply. > When you look at other IDEs - e.g. IntellIJ- they do exactly the same way > as I described. Each editor has its own temporary zoom factor. Other editors > are not influenced. I think this a very easy and simple approach (KISS) and > would be better. Once again I disagree ;) Introducing a zoom factor is overkill and isn't simpler. It's the opposite of KISS. What are you use-cases for "Reset font size" which aren't conveniently covered by a few Ctrl- ? As I read your usage reports, it seems like you're basically going to require people to type Ctrl+ much more often (6 times by editor in case of presentation, 1 time per editor when I'm tired by the end of the day) just to support a "Reset" command that is basically available as a Ctrl--- shortcut ? I believe the root of the issue is in the "Zoom" name. It should be "increase/decrease font size". A "zoom" implies there is a ratio, which requires things to have a natural size (explicit in HTML as there are images and CSS setting sizes, or in Office suites as there is the paper size). A text doesn't include information about its size, there is no "100%" on a text, it just has a size, no ratio. The comparison with a Web browser or with Word is not adapted. It should rather compare to VIM or Gedit or whatever *Text Editor*, not *Document Renderer*. And even so, why does it really matter to a user to get back to *the* default font size? One can just decrease font size until they like the size. The default font size isn't better than any other one (as opposed to HTML or Word again for which default size has a strong meaning). To me, a "reset" font size in a text editor is conceptually an overrated feature which in practice doesn't happen to be that valuable. Just to be clear, anyone who really wants the text size to be relying on a ratio shouldn't expect me to work on it; but would be welcome to provide patches. However, if we can agree on the behavior of a "reset" command that doesn't involve introducing a zoom ratio, I'd be glad to code it and close this issue.
(In reply to Mickael Istria from comment #32) > Typical use-cases of increasing font size are for presentations or tired > readers who want bigger size to ease readability. If a font of size 10 is > referenced in multiple places and users grows it to 12, it's most likely > because they want this font to be more readable for them, in all contexts. Hmm.. People are different. I don't use it such way. By the way: Eclipse neon.2 got a presentation mode (ALT+F11). Maybe it would be nice to have a preference (base) font size for this this mode, so it could be used easily on presentations (or when tired;-) ) But maybe this would be a complete other feature. > If you introduce a zoom level per editor, it introduces a new concept for > users to understand in order to clearly manipulate their font size. Eclipse > IDE is often criticized for it's complexity, adding a "rendering ratio" > concept to font size isn't making things simpler to apprehend for user. > As you, I am convinced that "zoom" is not the correct word for the feature - I also would prefer a "increase/decrease font size" as naming. But a simple increase/decrease of current editor font size cannot be a complex situation for somebody who is able to use eclipse. > I disagree on that, when I increase code with Ctrl+, it means I want bigger > text everywhere it can apply. Hmm.. currently I only got the changing font size in: - text editors - console with text output But nowhere else. Not in "package explorer", not in views like Debug, Problems etc. > Once again I disagree ;) Introducing a zoom factor is overkill and isn't > simpler. It's the opposite of KISS. > I just thought about storing initial font size (integer) in every editor instance on createPart(..) time and provide increase/decrease font size and back to initial value - that sounds easy for me and was the reason for mentioning "KISS". > What are you use-cases for "Reset font size" which aren't conveniently > covered by a few Ctrl- ? > As I read your usage reports, it seems like you're basically going to > require people to type Ctrl+ much more often (6 times by editor in case of > presentation, 1 time per editor when I'm tired by the end of the day) just > to support a "Reset" command that is basically available as a Ctrl--- > shortcut ? > I believe the root of the issue is in the "Zoom" name. It should be > "increase/decrease font size". A "zoom" implies there is a ratio, which > requires things to have a natural size (explicit in HTML as there are images > and CSS setting sizes, or in Office suites as there is the paper size). A > text doesn't include information about its size, there is no "100%" on a > text, it just has a size, no ratio. The comparison with a Web browser or > with Word is not adapted. It should rather compare to VIM or Gedit or > whatever *Text Editor*, not *Document Renderer*. I absolutely aggree with you :-) > And even so, why does it really matter to a user to get back to *the* > default font size? One can just decrease font size until they like the size. > The default font size isn't better than any other one (as opposed to HTML or I am just a lazy guy - I want to press a "button" and the default font sizes shall be back again e.g. when - I finished my presentation and do coding again. > Word again for which default size has a strong meaning). > To me, a "reset" font size in a text editor is conceptually an overrated > feature which in practice doesn't happen to be that valuable. > I am often not very happy with the font output when I just press "CTRL + " once. So I have to press "CTRL +" multiple times until being satisfied with font settings. > Just to be clear, anyone who really wants the text size to be relying on a > ratio shouldn't expect me to work on it; but would be welcome to provide > patches. > However, if we can agree on the behavior of a "reset" command that doesn't > involve introducing a zoom ratio, I'd be glad to code it and close this > issue. As you I think a "ratio" is absolutely overkill - to say it very simple: it's a text editor for developers not an SVG viewer...
Just to add more info where it might not be needed... I didn't even realize Eclipse had a zoom feature, and I've been a user for over 10 years. I zoomed by accident from some keystroke, and was surprised there was no reset zoom in the menus, or in the list of keys to get me back to my normal setting. It also seemed that even using the zoom in and out didn't get me to my setting. I think it was skipping over my original font size. I think it is a valuable feature to reset to the configured size. Resetting to some other size (like a default of 10) does not add enough value to implement in my opinion.
I too would LOVE some sort of "reset" to the state before I (or my crazy friend that was driving during our recent presentation) zoomed in a lot. I had no idea how to get back to the default settings, other that interactively go back and forth and try to remember what on earth the original settings were. Terminating and restarting eclipse doesn't seem to help. Perhaps uninstalling and reinstalling would do it that that seems extremely tedious. What secret am I overlooking? CTRL-0 seems to have no effect what so ever.
This is a design bug: When there is “zoom” then there needs to be a reset to default font size – what else would be the meaning of “default” then?! Ridiculous that it has not been added when the zoom feature was initially implemented. No need for broad justification.
My two cents to support this feature: As a full-time developer advocate, I do presentations frequently. When I'm presenting something in the browser, I know I can Cmd++ to zoom in. Later, I want to reset the zoom to a comfortable level. Sure, I can Cmd+- until it feels comfortable, but I know Cmd+0 is comfortable. I don't have to think. I just hit the shortcut and I'm ready. I'd like to be able to do the same in the IDE.
