Repository navigation
IDLE: Right Click Context Menu #42008
Description
| BPO | 1207589 |
|---|---|
| Nosy | @birkenfeld, @rhettinger, @terryjreedy, @kbkaiser, @taleinat, @ned-deily, @serwy, @bitdancer, @voidspace, @asvetlov, @rovitotv |
| Files |
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 = None
closed_at = <Date 2012-11-01.20:48:13.341>
created_at = <Date 2005-05-24.08:31:45.000>
labels = ['expert-IDLE', 'type-feature']
title = 'IDLE: Right Click Context Menu'
updated_at = <Date 2013-04-08.00:05:29.904>
user = 'https://github.com/voidspace'bugs.python.org fields:
activity = <Date 2013-04-08.00:05:29.904>
actor = 'Todd.Rovito'
assignee = 'none'
closed = True
closed_date = <Date 2012-11-01.20:48:13.341>
closer = 'asvetlov'
components = ['IDLE']
creation = <Date 2005-05-24.08:31:45.000>
creator = 'michael.foord'
dependencies = []
files = ['14685', '18089', '18090', '27644', '27645', '27847']
hgrepos = []
issue_num = 1207589
keywords = ['patch']
message_count = 34.0
messages = ['54525', '54526', '54527', '54528', '59661', '91457', '91458', '110901', '168845', '173305', '173306', '173308', '173309', '173427', '173428', '174474', '174475', '174490', '174502', '174504', '174506', '174518', '174538', '174539', '174543', '174575', '174592', '174596', '174601', '174602', '186228', '186254', '186255', '186256']
nosy_count = 14.0
nosy_names = ['georg.brandl', 'rhettinger', 'terry.reedy', 'kbk', 'taleinat', 'Nashev', 'gpolo', 'ned.deily', 'roger.serwy', 'r.david.murray', 'michael.foord', 'asvetlov', 'Todd.Rovito', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1207589'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']
Activity
voidspace commentedon May 24, 2005
It would be useful if the right click context menu had the
usual 'cut/paste/copy' options - as in most other IDEs.
I regularly lose my selection because IDLE doesn't
behave the same way as most other editors in this
regard.
rhettinger commentedon May 26, 2005
Logged In: YES
user_id=80475
+0
Control-X, Control-C, and Control-V work fine for me.
Still, the OP's suggestion is a standard way of doing things.
voidspace commentedon May 26, 2005
Logged In: YES
user_id=1123892
It's a standard way of doing things (and so an ingrained habit
for at least windoze users) - and also if you're using the
mouse to make a selection and then change focus to another
window to paste into it; it's easier to be able to do the whole
operation with the mouse than change to the keyboard and
back again.
kbkaiser commentedon May 26, 2005
Logged In: YES
user_id=149084
This came up on idle-dev, as I remember.
Seems like a reasonable suggestion to me.
Maybe OP could write a patch? All the pertinent code
should be in EditorWindow.py.
Nashev commentedon Jan 10, 2008
a) remove selection-killer command on popup
b) add ability to make separators in popup menu
done...
And now I can't find easy way to next two desired features:
exists in main menu too)
gpolo commentedon Aug 10, 2009
What do you think about adding a third element for each tuple in
rmenu_specs ? This new element would be a string determining the name of
a function that would be called to define the state of each entry in the
right menu. If None is used in place of a string, then it is assumed
that the entry doesn't require such thing.
Attaching a patch that does that. It also adds cut/copy/paste to the
right menu in IDLE shell.
gpolo commentedon Aug 10, 2009
Is that really necessary ? I've looked for that on some applications I
use most and none of them include hot keys in right menus.
taleinat commentedon Jul 20, 2010
I agree with Guilherme: shortcuts don't need to appear in the context menu.
Guilherme's patch looks pretty good overall, but I have a few remarks:
Pasting should be disabled in the Shell window when the cursor is before the I/O mark. (the behavior for cutting is correct)
Code relevant to the Shell window should be in PyShell, not in EditorWindow with a getattr(self, 'interp', None) check.
Tk.Text.compare can receive names of tags to compare (don't have to do Tk.Text.index('<tag name>'))
So I made these changes. Attached are patches against current trunk (2.x) and py3k branch.
My testing on Windows7 with both 2.7 and 3.1.2 showed this change works well. This should be tested on OSX and Linux since it interacts with the clipboard, which works differently on these platforms.
Nashev commentedon Aug 22, 2012
display assigned hot keys in popup menu is must-have feature, that allow users to teach them while using commands by menu or by context menu. For examples look Delphi IDE
[-]Right Click Context Menu[/-][+]IDLE: Right Click Context Menu[/+][-]Right Click Context Menu[/-][+]IDLE: Right Click Context Menu[/+]13 remaining items
bitdancer commentedon Nov 2, 2012
The reason for our "no new features" policy is that if a program works with version x.y, it should work for all x versions (modulo failing on an earlier version because of a bug...and conversely if it works on x.y, it should work on all later versions of x, which is why we also sometimes don't fix certain bugs in maintenance releases).
In this case, if I understand correctly, there are no *programs* that can depend on the feature, just humans. So I think putting this in to bugfix releases is more analogous to the fixes-that-look-like-enhancements we occasionally put into the build infrastructure for Python itself (as opposed to distutils, which is governed by the normal backward compatibility rules).
So, it's a judgment call and other developers might not agree with me, but I think it is OK.
terryjreedy commentedon Nov 2, 2012
It it not a new library feature that anyone would use in other code. I have been meaning to raise this issue on pydev to see what others think. There are advantages to keeping the *human* interaction with IDLE consistent between releases.
serwy commentedon Nov 2, 2012
In a strict sense, the patch does break backward compatibility for third-party IDLE extensions that modify the rmenu_specs contents. It is not a "private" value since it lacks an initial underscore in its name. But given how undocumented IDLE is, especially its extension facility, I don't think poses any problems.
(For what it's worth, I'm the developer of IdleX and I already released a trivial workaround for this change. I welcome this improvement to IDLE, especially when it deprecates an existing IdleX extension.)
While keeping UI consistency may be desirable, keeping it crippled is not. Even Window's Notepad has a decent right-click menu.
bitdancer commentedon Nov 2, 2012
Ah. Well, we prefer to err on the side of strictness for backward compatibility, so I think we should treat this as an enhancement, then.
ned-deily commentedon Nov 2, 2012
I think it is clear that this is an enhancement. So then the question is: is there a good reason to make an exception here to the "no new features in maintenance releases" policy? David mentioned some considerations. I would add testing and documentation. Testing is a *big* concern with IDLE since IDLE is so dependent on Tk and we know from long experience that there can be differences among the various platform-specific Tk implementations (we currently support at least 4 different Tk varieties) and we have no standard automated tests for IDLE. So that increases the risk that we could break something in a maintenance release which we try really hard not to do. On the other hand, there is something to be said about maintaining compatibility as best as possible across IDLE version.
I'm not fundamentally opposed to including this enhancement in maintenance releases. But I think it is important to recognize that it is an exception to policy and to have this discussion about it. Personally, I'm +0 on the whole feature - it's not something I would use - so I don't really have a stake in it. I do have a bit of a stake in the testing part and for that reason I'm -0 on the backports. I'm glad to see Todd tested on Linux and OS X - presumably someone has tested on Windows. If the backports remain, the feature should at least be smoke-tested at some point on all four of the branches and with all of the major Tk versions (Windows, X11, OS X Cocoa Tk 8.5, OS X Carbon Tk 8.4). Since he has the most experience in this area, I'm willing to defer to Roger's judgement call on the impact of this change with regard to IDLE extensions.
terryjreedy commentedon Nov 2, 2012
On pydev, I explained why I think the bug-enhancement policy does not necessarily apply to IDLE, starting the the fact that IDLE was treated as exceptional and not considered bound to normal policy when it was considered for deletion and ending with the fact that exclusionary dichotomous classification is inherently ambiguous in the absence of specification.
Leaving that aside, the right-click context menu is not mentioned in the brief Library manual chapter on IDLE. It is a GUI matter. I suspect that the docs also do not specify the right-click behavior of the standard interpreter either.
The apparent external GUI standard, at least on Windows, is that context menus have copy, cut, and paste entries as appropriate. I am pretty sure that this could be found in an MS document entitled something like Human Useability Guidelines. By that standard, it was a bug for those to be missing. I know Apple has interface standards docs also, but I don't know what the standard is.
For instance, Firefox has Cut Copy and Paste within this edit box, with the first two activated when a selection is made. Outside the edit box, only Cut appears, when a selection is active.
I think one could reasonably say that this feature is both a bug fix and an enhancement. After all, all bug fixes are enhancements and all enhancements fix the bug of their absence. We use documented intention to tip the scale one way or the other, but that is completely missing for this feature and mostly missing, except for existence and the common, non-Python-specific meaning of words like 'search box', for everything else.
asvetlov commentedon Nov 2, 2012
I guess the schema: keep the current state a while.
Please test context menu for all configurations you have.
If you will have any problem — commits will be reverted.
If anybody will report about backward incompatibility problems — I'll revert changes.
Modifying IDLE extensions is not big deal if somebody need it.
ned-deily commentedon Nov 3, 2012
"Leaving that aside, the right-click context menu is not mentioned in the brief Library manual chapter on IDLE."
FTR, as I pointed out on python-dev, this is no longer true. The IDLE section of the Standard Library documentation, as well as the IDLE help file, were updated by the changes for bpo-10405. The changes committed for this issue (bpo-1207589) further updated those to document this new feature. See for instance:
http://docs.python.org/2/library/idle.html#edit-context-menu
serwy commentedon Nov 3, 2012
On IDLE Extensions: The public ecosystem of IDLE extensions is small, and even smaller are those that modify rmenu_specs. Changing it is trivial. However, existing users of the Squeezer extension under 2.7 will experience bugs, like triggering bpo-13582 on Windows.
It is possible to make the code in make_rmenu backwards compatible. The attached patch against 2.7 (and 3.4) does it.
asvetlov commentedon Nov 3, 2012
LGTM
python-dev commentedon Apr 7, 2013
New changeset 3fad938e9d4e by Roger Serwy in branch '2.7':
bpo-1207589: Backwards-compatibility patch for right-click menu in IDLE.
http://hg.python.org/cpython/rev/3fad938e9d4e
New changeset c26ec5897c5a by Roger Serwy in branch '3.3':
bpo-1207589: Backwards-compatibility patch for right-click menu in IDLE.
http://hg.python.org/cpython/rev/c26ec5897c5a
New changeset 5219c1271156 by Roger Serwy in branch 'default':
bpo-1207589: merge with 3.3.
http://hg.python.org/cpython/rev/5219c1271156
rovitotv commentedon Apr 7, 2013
Very strange but I noticed the right click menu is not working on Mac OS X. Before and after Roger's latest backwards_compat.patch. I must be losing my mind but I thought this was working on OS X. The right click activation I am trying is control-click and I am running 10.8.3.
Should I file a separate bug report for this issue?
serwy commentedon Apr 7, 2013
Please do open a separate issue. We'll resolve it there.
rovitotv commentedon Apr 8, 2013
No problem I will open a separate issue. Hopefully it is a mistake on my end and I have something dorked up.