You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow the user to change font sizes with the text pane of turtledemo #66132
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2014-09-05.01:02:05.446>created_at=<Date2014-07-07.15:18:15.486>labels= ['type-bug']
title='Allow the user to change font sizes with the text pane of turtledemo'updated_at=<Date2014-09-05.01:02:05.445>user='https://bugs.python.org/LitaCho'
Currently, the turtledemo doesn't allow you to change font sizes of the demo code, and the default font size is really small.
I can work on creating a patch to fix this. Best option be to have control-mousewheel change size, as is standard in browsers, as well as Ctrl + and Ctrl - to change sizes (since laptops don't have a mousewheel).
If tk has a problem with that, a second choice would be a menu entry "Font size with choices such as the current size (9?), 10, 12, 14.
Also, update the Help Text of this new feature.
LitaCho commented on Jul 22, 2014
LitaChomannequin
MannequinAuthor
More actions
I have a version of this working with Ctrl-plus and Ctrl-minus. However, there is a bug with Tk 8.5.9 where binding to MouseWheel crashes Tkinter for Macs (bpo-10731), which I am running into. I need to update Tkinter to see if this works.
LitaCho commented on Jul 22, 2014
LitaChomannequin
MannequinAuthor
More actions
Here is a patch for changing the font size using the scroll wheel. I also added the shortcuts "Ctrl-plus" to increase the font size and "Ctrl-minus" to decrease the font size.
However, since the MouseWheel is now bound to changing the font
size, the canvas won't scroll. I can try to fix this so that the mousewheel only changes the font size if the text pane is highlighted. But that might not be intuitive. Thoughts?
Note, this patch also includes the window sash (bpo-21597). They are sort of dependent since I am also redefining the onResize method, so I clumped all the bindings to one method. But if you want that to be separate, I can try to make it into two separate patches.
MOUSEWHEEL should continue to scroll.
CONTROL+MOUSEWHEEL should change font size, as you said at the beginning.
At least on Windows, this seems pretty standard: Internet Explorer, Firefox, Notepad++, LibreOffice (and, I imagin, OpenOffice, and Word), Thunderbird. The only exception I can find that has a font size setting but ignores ^wheel is Command Prompt, which breaks multiple UI rules. Notepad does not allow font resizing.
Get ^wheel to work right and I would like to add it to Idle, where ^wheel scrolls along with wheel.
^+ and ^- are pretty standard also, though LibreOffice does not recognize them. Perhaps this is because it is explicit cross platform.
We can conditionally not bind wheel events on Mac setups where it fails. Does bpo-10731 have enough info to do that? In not... I have not yet looked into generating key/mouse events from code, but perhaps it would be possible to generate a wheel event inside try: except and unbind if there is an exception.
LitaCho commented on Jul 22, 2014
LitaChomannequin
MannequinAuthor
More actions
Sounds good. I can wait till the sash code gets incorporated in order to
add in the font code.
I would have to generate a MOUSEWHEEL event and see if it fails. I have
generated mouse clicks before. I'll try to see if I can generate a
MOUSEWHEEL event and if it errors, not bind to it. Although it might be
hard for me to test, as I just updated my tcl/tk.
I will also try to figure out how to bind to Ctrl+MOUSEWHEEL and not just
MOUSEWHEEL.
MOUSEWHEEL should continue to scroll.
CONTROL+MOUSEWHEEL should change font size, as you said at the beginning.
At least on Windows, this seems pretty standard: Internet Explorer,
Firefox, Notepad++, LibreOffice (and, I imagin, OpenOffice, and Word),
Thunderbird. The only exception I can find that has a font size setting
but ignores ^wheel is Command Prompt, which breaks multiple UI rules.
Notepad does not allow font resizing.
Get ^wheel to work right and I would like to add it to Idle, where ^wheel
scrolls along with wheel.
^+ and ^- are pretty standard also, though LibreOffice does not recognize
them. Perhaps this is because it is explicit cross platform.
We can conditionally not bind wheel events on Mac setups where it fails.
Does bpo-10731 have enough info to do that? In not... I have not yet looked
into generating key/mouse events from code, but perhaps it would be
possible to generate a wheel event inside try: except and unbind if there
is an exception.
Lita, I tried the patch. From the perspective of an OS X user, while I might expect that using the zoom gesture on a mousepad or using a mousewheel (the equivalent) to increase or decrease the font size, I would even more expect scrolling to work especially if scrollbars are present. Clearly, scrolling is more important so, if it is not possible to bind Tk mousewheel events without affecting scrolling, I would abandon the mousewheel. On OS X, the standard way to provide size adjustment (of fonts or images) is to provide "Bigger" or "Smaller" menu items with the standard keyboard shortcuts of Command-Shift-Equal (and Command-Equal) which is displayed as "Command +" (so the user on a US keyboard just presses the Command key and the =/+ key) and Command-Hyphen ("Command -"). The Apple OS X Human Interface Guidelines go into more detail and you can see these shortcuts in action in many standard OS X applications (TextEdit, Mail, Safari, etc). As it stands today, turtledemo does not use the standard OS X menu bar where these commands would normally be placed. And that's a bit of a separate problem because since turtledemo doesn't change the root menu it defaults to a Tk-provided one which includes things "Run Widget Demo" under the file menu. To be a proper OS X app, turtledemo should customize the menu, at least removing the widget demo item and then it could add the Bigger and Smaller menu items to a Format menu. Actually, the turtledemo Examples and Help pulldown options would ideally also be available in the standard menu hierarchy. I'm not suggesting that is a requirement but that's what I think an OS X user would expect and what the Apple HIG would require.
I completely agree about the mousewheel. However, would it make sense for
OS X to combine command with mousewheel? I have never seen that before. I
am not sure if I can bind the zoom gesture with tkinter, but I can find
out.
I also think the shortcuts are not intuitive as an OS X user, as command
should be used instead of Ctrl.
What I can do check the operating system and define the font shortcuts
accordingly. I am not sure about redefining the Menu shortcuts as that
seems like a separate issue.
Lita, I tried the patch. From the perspective of an OS X user, while I
might expect that using the zoom gesture on a mousepad or using a
mousewheel (the equivalent) to increase or decrease the font size, I would
even more expect scrolling to work especially if scrollbars are present.
Clearly, scrolling is more important so, if it is not possible to bind Tk
mousewheel events without affecting scrolling, I would abandon the
mousewheel. On OS X, the standard way to provide size adjustment (of fonts
or images) is to provide "Bigger" or "Smaller" menu items with the standard
keyboard shortcuts of Command-Shift-Equal (and Command-Equal) which is
displayed as "Command +" (so the user on a US keyboard just presses the
Command key and the =/+ key) and Command-Hyphen ("Command -"). The Apple
OS X Human Interface Guidelines go into more detail and you can see these
shortcuts in action in many standard OS X applications (TextEdit, Mail,
Safari, etc). As it stands today, turtledemo does not use the standard OS
X menu bar where these commands would normally be placed. And that's a bit
of a separate problem because since turtledemo doesn't change the root menu
it defaults to a Tk-provided one which includes things "Run Widget Demo"
under the file menu. To be a proper OS X app, turtledemo should customize
the menu, at least removing the widget demo item and then it could add the
Bigger and Smaller menu items to a Format menu. Actually, the turtledemo
Examples and Help pulldown options would ideally also be available in the
standard menu hierarchy. I'm not suggesting that is a requirement but
that's what I think an OS X user would expect and what the Apple HIG would
require.
On OS X, the actions associated with trackpad gestures are controlled by the Trackpad panel of System Preferences. The default settings map the "pinch with two fingers" gesture to "Zoom in or out" which Tk apps see as Mousewheel events: no programming needed!
LitaCho commented on Jul 22, 2014
LitaChomannequin
MannequinAuthor
More actions
What really? That is so awesome! I will check that out!
However, I figure I still need to create separate bindings for Linux,
Windows and Mac, right? Or does Tkinter unify all the mousewheel events?
On OS X, the actions associated with trackpad gestures are controlled by
the Trackpad panel of System Preferences. The default settings map the
"pinch with two fingers" gesture to "Zoom in or out" which Tk apps see as
Mousewheel events: no programming needed!
Oh I see. And then pinch on the trackpad just generates a overall MouseWheel event, not a specific zoom-in event. For some reason, I thought there was a different event depending on operating systems. Before, Linux would trigger <Button-4> and <Button-5> events and not MouseWheel.
I've added it so that if the OS is Mac, it will use Command-minus and Command-=. If it is on Windows, it uses Ctrl-minus and Ctrl-= (I wasn't sure if Windows uses shift sa well, but I don't think it does.)
When I tried the "pinch" movement in Mac, the MouseWheel event didn't trigger at all. It is only when I did the scroll (for me two fingers moving downward or upward) movement is when that event triggered.
I currently have it so that when Control+MouseWheel makes the font size move. Let me know what you think.
I can also try adding a widget so that the user can change the font through the GUI.
On windows, new patch gives this:
Traceback (most recent call last):
File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 295, in <module>
demo = DemoWindow()
File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 73, in __init__
graph_frame =self.makeGraphFrame(pane)
File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 115, in makeGraphFrameself._makeBindings(turtle._Screen._canvas._rootwindow)
File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 130, in _makeBindings
root_window.bind_all('<%s-minus>'% shortcut, self._decreaseFont)
File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 1049, in bind_allreturnself._bind(('bind', 'all'), sequence, func, add, 0)
File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 992, in _bindself.tk.call(what + (sequence, cmd))
_tkinter.TclError: bad event type or keysym "Ctrl"
/Ctrl/Control in "shortcut = 'Control" and demo runs.
^- shrinks on -_ key and num keypad.
&+ enlarges on =+ key but not num keypad. Fix by adding
root_window.bind_all('<%s-plus>' % shortcut, self._increaseFont)
^wheel either way maked giant type -- evt.delta on my machine is +-120!
self.txtfont['size'] += evt.delta // 120
works like expected. And please spell out 'event'.
Out general policy is one patch per issue. The one for bpo-21587 already fixes two issues. After we finish that (see questions), produce a small patch for this.
LitaCho commented on Jul 23, 2014
LitaChomannequin
MannequinAuthor
More actions
Sounds good. I will wait till bpo-21587 and create a small patch afterwards.
Thanks!
>
> Terry J. Reedy added the comment:
>
> On windows, new patch gives this:
> Traceback (most recent call last):
> File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 295, in
> <module>
> demo = DemoWindow()
> File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 73, in
> __init__
> graph_frame = self.makeGraphFrame(pane)
> File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 115, in
> makeGraphFrame
> self._makeBindings(turtle._Screen._canvas._rootwindow)
> File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 130, in
> _makeBindings
> root_window.bind_all('<%s-minus>' % shortcut, self._decreaseFont)
> File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 1049, in
> bind_all
> return self._bind(('bind', 'all'), sequence, func, add, 0)
> File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 992, in _bind
> self.tk.call(what + (sequence, cmd))
> _tkinter.TclError: bad event type or keysym "Ctrl"
>
> /Ctrl/Control in "shortcut = 'Control" and demo runs.
>
> root_window.bind_all('<%s-minus>' % shortcut, self._decreaseFont)
> root_window.bind_all('<%s-=>' % shortcut, self._increaseFont)
>
> ^- shrinks on -_ key and num keypad.
> &+ enlarges on =+ key but not num keypad. Fix by adding
> root_window.bind_all('<%s-plus>' % shortcut, self._increaseFont)
>
> ^wheel either way maked giant type -- evt.delta on my machine is +-120!
> self.txtfont['size'] += evt.delta // 120
> works like expected. And please spell out 'event'.
>
> Out general policy is one patch per issue. The one for python/cpython#65786 already
> fixes two issues. After we finish that (see questions), produce a small
> patch for this.
>
>
I am working on backporting the bpo-10291 patch and re-synchronizing 3.4 and 3.5 so revised version of this patch, including help change, and of bpo-22065 patch can merge forward properly.
I refactored the callbacks to eliminate duplication. I had to redo the menu addition to work with the new menu. This works great on Windows. I am confident I did not change the logic, but it would still be good if someone tried font changing again on linux and mac.
I am not going to backport this to the 2.7 Demo version, as backporting has always been a nuisance and now the help and menu redesigns have also not been backported.
Lita, thank you for sticking with this. bpo-17642 is about doing something similar for Idle. The issue is necessarily more complicated, but what we learned here about system difference and tk behavior oddities will be needed for Idle too. I am making 'what we learned' comments there.
I am aware of this because the Windows has the same behavior. As I noted in my post to bpo-17642, I consider this behavior a tolerable glitch rather than a patch-blocking bug for turtledemo because the text is relatively short and read only, so there is no issue of needing to keep a cursor in place and visible. The issue would be different for Idle if indeed this is a tk rather than turtle problem. Also, people would typically only move a few clicks up or down, and scrolling up when already at the top of the file has no effect. So I do not regard this as a bug for this issue and regard this as still closed unless you happen to have thought of a workaround.
If you don't have a fix now, you could open a separate issue to investigate whether the linkage is a tk, tkinter, or turtle bug.
As part of bpo-17535, I discovered that when a Text widgets change the font size, they scroll up, down too far (or down and up too far), and back to where they should be. This is not visible with small files like the turtle examples, but is with 3000-line files like idlelib/EditorWindow.py, especially when line numbers are enabled. My test script attached to bpo-17535 shows that Text indeed calls scrollbar.set 3 times. I regard this as a tk bug. My point here is that Text widget font size changes are a bit flaky even without the mousewheel issue.
Great. That works better on Windows too. Attached is an augmented patch to also move the other size bindings to text (I verified that 'bind_all' is needed), move the resize binding back to where it was, delete the now-empty binding function, and add a not to the docstring that the mousewheel only resizes when the mouse is over the text. Please verify that this also works for non-windows.
Activity
LitaCho commentedon Jul 7, 2014
Currently, the turtledemo doesn't allow you to change font sizes of the demo code, and the default font size is really small.
I can work on creating a patch to fix this. Best option be to have control-mousewheel change size, as is standard in browsers, as well as Ctrl + and Ctrl - to change sizes (since laptops don't have a mousewheel).
If tk has a problem with that, a second choice would be a menu entry "Font size with choices such as the current size (9?), 10, 12, 14.
Also, update the Help Text of this new feature.
LitaCho commentedon Jul 22, 2014
I have a version of this working with Ctrl-plus and Ctrl-minus. However, there is a bug with Tk 8.5.9 where binding to MouseWheel crashes Tkinter for Macs (bpo-10731), which I am running into. I need to update Tkinter to see if this works.
LitaCho commentedon Jul 22, 2014
Here is a patch for changing the font size using the scroll wheel. I also added the shortcuts "Ctrl-plus" to increase the font size and "Ctrl-minus" to decrease the font size.
However, since the MouseWheel is now bound to changing the font
size, the canvas won't scroll. I can try to fix this so that the mousewheel only changes the font size if the text pane is highlighted. But that might not be intuitive. Thoughts?
Note, this patch also includes the window sash (bpo-21597). They are sort of dependent since I am also redefining the onResize method, so I clumped all the bindings to one method. But if you want that to be separate, I can try to make it into two separate patches.
terryjreedy commentedon Jul 22, 2014
I plan to commit the sash patch before reviewing this. I would wait until then to do a separate patch.
terryjreedy commentedon Jul 22, 2014
MOUSEWHEEL should continue to scroll.
CONTROL+MOUSEWHEEL should change font size, as you said at the beginning.
At least on Windows, this seems pretty standard: Internet Explorer, Firefox, Notepad++, LibreOffice (and, I imagin, OpenOffice, and Word), Thunderbird. The only exception I can find that has a font size setting but ignores ^wheel is Command Prompt, which breaks multiple UI rules. Notepad does not allow font resizing.
Get ^wheel to work right and I would like to add it to Idle, where ^wheel scrolls along with wheel.
^+ and ^- are pretty standard also, though LibreOffice does not recognize them. Perhaps this is because it is explicit cross platform.
We can conditionally not bind wheel events on Mac setups where it fails. Does bpo-10731 have enough info to do that? In not... I have not yet looked into generating key/mouse events from code, but perhaps it would be possible to generate a wheel event inside try: except and unbind if there is an exception.
LitaCho commentedon Jul 22, 2014
Sounds good. I can wait till the sash code gets incorporated in order to
add in the font code.
I would have to generate a MOUSEWHEEL event and see if it fails. I have
generated mouse clicks before. I'll try to see if I can generate a
MOUSEWHEEL event and if it errors, not bind to it. Although it might be
hard for me to test, as I just updated my tcl/tk.
I will also try to figure out how to bind to Ctrl+MOUSEWHEEL and not just
MOUSEWHEEL.
Lita
On Mon, Jul 21, 2014 at 11:35 PM, Terry J. Reedy <report@bugs.python.org>
wrote:
ned-deily commentedon Jul 22, 2014
Lita, I tried the patch. From the perspective of an OS X user, while I might expect that using the zoom gesture on a mousepad or using a mousewheel (the equivalent) to increase or decrease the font size, I would even more expect scrolling to work especially if scrollbars are present. Clearly, scrolling is more important so, if it is not possible to bind Tk mousewheel events without affecting scrolling, I would abandon the mousewheel. On OS X, the standard way to provide size adjustment (of fonts or images) is to provide "Bigger" or "Smaller" menu items with the standard keyboard shortcuts of Command-Shift-Equal (and Command-Equal) which is displayed as "Command +" (so the user on a US keyboard just presses the Command key and the =/+ key) and Command-Hyphen ("Command -"). The Apple OS X Human Interface Guidelines go into more detail and you can see these shortcuts in action in many standard OS X applications (TextEdit, Mail, Safari, etc). As it stands today, turtledemo does not use the standard OS X menu bar where these commands would normally be placed. And that's a bit of a separate problem because since turtledemo doesn't change the root menu it defaults to a Tk-provided one which includes things "Run Widget Demo" under the file menu. To be a proper OS X app, turtledemo should customize the menu, at least removing the widget demo item and then it could add the Bigger and Smaller menu items to a Format menu. Actually, the turtledemo Examples and Help pulldown options would ideally also be available in the standard menu hierarchy. I'm not suggesting that is a requirement but that's what I think an OS X user would expect and what the Apple HIG would require.
https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/KeyboardShortcuts/KeyboardShortcuts.html
https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Menus/Menus.html
LitaCho commentedon Jul 22, 2014
I completely agree about the mousewheel. However, would it make sense for
OS X to combine command with mousewheel? I have never seen that before. I
am not sure if I can bind the zoom gesture with tkinter, but I can find
out.
I also think the shortcuts are not intuitive as an OS X user, as command
should be used instead of Ctrl.
What I can do check the operating system and define the font shortcuts
accordingly. I am not sure about redefining the Menu shortcuts as that
seems like a separate issue.
On Mon, Jul 21, 2014 at 11:52 PM, Ned Deily <report@bugs.python.org> wrote:
ned-deily commentedon Jul 22, 2014
On OS X, the actions associated with trackpad gestures are controlled by the Trackpad panel of System Preferences. The default settings map the "pinch with two fingers" gesture to "Zoom in or out" which Tk apps see as Mousewheel events: no programming needed!
LitaCho commentedon Jul 22, 2014
What really? That is so awesome! I will check that out!
However, I figure I still need to create separate bindings for Linux,
Windows and Mac, right? Or does Tkinter unify all the mousewheel events?
Lita
On Tue, Jul 22, 2014 at 12:18 AM, Ned Deily <report@bugs.python.org> wrote:
ned-deily commentedon Jul 22, 2014
"However, I figure I still need to create separate bindings for Linux,
"Windows and Mac, right? Or does Tkinter unify all the mousewheel events?
I'm not sure I understand: I think that Tk only provides one MouseWheel event binding. Keyboard or menu items might differ, yes, e.g. Cmd-+ vs Ctrl-+.
http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M9
LitaCho commentedon Jul 22, 2014
Oh I see. And then pinch on the trackpad just generates a overall MouseWheel event, not a specific zoom-in event. For some reason, I thought there was a different event depending on operating systems. Before, Linux would trigger <Button-4> and <Button-5> events and not MouseWheel.
On Jul 22, 2014, at 12:35 AM, Ned Deily <report@bugs.python.org> wrote:
LitaCho commentedon Jul 23, 2014
I've added it so that if the OS is Mac, it will use Command-minus and Command-=. If it is on Windows, it uses Ctrl-minus and Ctrl-= (I wasn't sure if Windows uses shift sa well, but I don't think it does.)
When I tried the "pinch" movement in Mac, the MouseWheel event didn't trigger at all. It is only when I did the scroll (for me two fingers moving downward or upward) movement is when that event triggered.
I currently have it so that when Control+MouseWheel makes the font size move. Let me know what you think.
I can also try adding a widget so that the user can change the font through the GUI.
terryjreedy commentedon Jul 23, 2014
/Ctrl/Control in "shortcut = 'Control" and demo runs.
^- shrinks on -_ key and num keypad.
&+ enlarges on =+ key but not num keypad. Fix by adding
root_window.bind_all('<%s-plus>' % shortcut, self._increaseFont)
^wheel either way maked giant type -- evt.delta on my machine is +-120!
self.txtfont['size'] += evt.delta // 120
works like expected. And please spell out 'event'.
Out general policy is one patch per issue. The one for bpo-21587 already fixes two issues. After we finish that (see questions), produce a small patch for this.
LitaCho commentedon Jul 23, 2014
Sounds good. I will wait till bpo-21587 and create a small patch afterwards.
Thanks!
On Tue, Jul 22, 2014 at 9:33 PM, Terry J. Reedy <report@bugs.python.org>
wrote:
> > Terry J. Reedy added the comment: > > On windows, new patch gives this: > Traceback (most recent call last): > File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 295, in > <module> > demo = DemoWindow() > File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 73, in > __init__ > graph_frame = self.makeGraphFrame(pane) > File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 115, in > makeGraphFrame > self._makeBindings(turtle._Screen._canvas._rootwindow) > File "F:\Python\dev\4\py34\Lib\turtledemo\__main__.py", line 130, in > _makeBindings > root_window.bind_all('<%s-minus>' % shortcut, self._decreaseFont) > File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 1049, in > bind_all > return self._bind(('bind', 'all'), sequence, func, add, 0) > File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 992, in _bind > self.tk.call(what + (sequence, cmd)) > _tkinter.TclError: bad event type or keysym "Ctrl" > > /Ctrl/Control in "shortcut = 'Control" and demo runs. > > root_window.bind_all('<%s-minus>' % shortcut, self._decreaseFont) > root_window.bind_all('<%s-=>' % shortcut, self._increaseFont) > > ^- shrinks on -_ key and num keypad. > &+ enlarges on =+ key but not num keypad. Fix by adding > root_window.bind_all('<%s-plus>' % shortcut, self._increaseFont) > > ^wheel either way maked giant type -- evt.delta on my machine is +-120! > self.txtfont['size'] += evt.delta // 120 > works like expected. And please spell out 'event'. > > Out general policy is one patch per issue. The one for python/cpython#65786 already > fixes two issues. After we finish that (see questions), produce a small > patch for this. > >11 remaining items
LitaCho commentedon Aug 14, 2014
ping!
terryjreedy commentedon Aug 15, 2014
I am working on backporting the bpo-10291 patch and re-synchronizing 3.4 and 3.5 so revised version of this patch, including help change, and of bpo-22065 patch can merge forward properly.
python-dev commentedon Sep 3, 2014
New changeset ce14092430b6 by Terry Jan Reedy in branch '3.4':
Issue bpo-21933: Users can now change the font size for example code.
http://hg.python.org/cpython/rev/ce14092430b6
New changeset e2e0c9f90a81 by Terry Jan Reedy in branch 'default':
Issue bpo-21933: Merge with 3.4
http://hg.python.org/cpython/rev/e2e0c9f90a81
terryjreedy commentedon Sep 3, 2014
I refactored the callbacks to eliminate duplication. I had to redo the menu addition to work with the new menu. This works great on Windows. I am confident I did not change the logic, but it would still be good if someone tried font changing again on linux and mac.
I am not going to backport this to the 2.7 Demo version, as backporting has always been a nuisance and now the help and menu redesigns have also not been backported.
terryjreedy commentedon Sep 3, 2014
Lita, thank you for sticking with this. bpo-17642 is about doing something similar for Idle. The issue is necessarily more complicated, but what we learned here about system difference and tk behavior oddities will be needed for Idle too. I am making 'what we learned' comments there.
serhiy-storchaka commentedon Sep 4, 2014
Unfortunately the bug on X11 is still here. Ctrl+mouse wheel not only changes font, but scrolls a text.
terryjreedy commentedon Sep 4, 2014
I am aware of this because the Windows has the same behavior. As I noted in my post to bpo-17642, I consider this behavior a tolerable glitch rather than a patch-blocking bug for turtledemo because the text is relatively short and read only, so there is no issue of needing to keep a cursor in place and visible. The issue would be different for Idle if indeed this is a tk rather than turtle problem. Also, people would typically only move a few clicks up or down, and scrolling up when already at the top of the file has no effect. So I do not regard this as a bug for this issue and regard this as still closed unless you happen to have thought of a workaround.
If you don't have a fix now, you could open a separate issue to investigate whether the linkage is a tk, tkinter, or turtle bug.
As part of bpo-17535, I discovered that when a Text widgets change the font size, they scroll up, down too far (or down and up too far), and back to where they should be. This is not visible with small files like the turtle examples, but is with 3000-line files like idlelib/EditorWindow.py, especially when line numbers are enabled. My test script attached to bpo-17535 shows that Text indeed calls scrollbar.set 3 times. I regard this as a tk bug. My point here is that Text widget font size changes are a bit flaky even without the mousewheel issue.
serhiy-storchaka commentedon Sep 4, 2014
Here is a patch which should fix this bug. In additional it fixes a bug on MacOS: mouse wheel only increased font size.
terryjreedy commentedon Sep 4, 2014
Great. That works better on Windows too. Attached is an augmented patch to also move the other size bindings to text (I verified that 'bind_all' is needed), move the resize binding back to where it was, delete the now-empty binding function, and add a not to the docstring that the mousewheel only resizes when the mouse is over the text. Please verify that this also works for non-windows.
serhiy-storchaka commentedon Sep 4, 2014
This works on X11 (Linux).
Actually it doesn't matter for what widget you call bind_all(). It works globally.
python-dev commentedon Sep 5, 2014
New changeset ecc98ea50bc3 by Terry Jan Reedy in branch '3.4':
Issue bpo-21933: Make Control-Mousewhell only change font size and not also scroll.
http://hg.python.org/cpython/rev/ecc98ea50bc3