Repository navigation
IDLE - Add an extension configuration dialog #47318
Description
| BPO | 3068 |
|---|---|
| Nosy | @terryjreedy, @kbkaiser, @taleinat, @ned-deily |
| 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 = 'https://github.com/terryjreedy'
closed_at = <Date 2014-12-04.06:27:53.295>
created_at = <Date 2008-06-09.18:10:31.464>
labels = ['expert-IDLE', 'type-feature']
title = 'IDLE - Add an extension configuration dialog'
updated_at = <Date 2014-12-04.06:27:53.294>
user = 'https://github.com/taleinat'bugs.python.org fields:
activity = <Date 2014-12-04.06:27:53.294>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2014-12-04.06:27:53.295>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2008-06-09.18:10:31.464>
creator = 'taleinat'
dependencies = []
files = ['10561', '34014', '35559', '36840', '36904', '36921', '36928', '36931', '36932']
hgrepos = []
issue_num = 3068
keywords = ['patch']
message_count = 38.0
messages = ['67872', '67873', '210214', '210269', '210274', '210281', '210295', '210305', '210649', '210758', '210773', '210775', '210780', '220194', '220259', '223314', '223315', '223325', '228825', '228826', '228830', '228831', '228890', '229268', '229290', '229301', '229315', '229323', '229340', '229367', '229384', '229397', '229412', '229414', '229844', '229850', '229982', '232106']
nosy_count = 8.0
nosy_names = ['terry.reedy', 'kbk', 'taleinat', 'gpolo', 'ned.deily', 'weeble', 'python-dev', 'Saimadhav.Heblikar']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue3068'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']
Activity
taleinat commentedon Feb 9, 2014
I'm glad that adding features to IDLE is being considered! However, I really think that new features should be chosen with extreme care. Adding advanced features aimed mostly at "power" users should be avoided unless really necessary, IMO.
The reason I'm pushing this extension is because it is straight-forward to use and make things using IDLE easier and less frustrating, especially for novice users.
taleinat commentedon Feb 9, 2014
Here's an updated patch. As requested, the patch is against the current 3.3 branch and applies cleanly to default.
I tested with both Python 3.3.4 RC1 and 3.4.0 beta 3, while overriding their idlelib with the one from the repo with these changes.
I also removed from this patch the moving of the line width setting for the FormatParagraph extension from the base config dialog to the extensions config. See separate patch for this in bpo-20577.
ned-deily commentedon Jun 10, 2014
I did a very quick test on OS X. Comments:
diff --git a/Lib/idlelib/macosxSupport.py b/Lib/idlelib/macosxSupport.py
--- a/Lib/idlelib/macosxSupport.py
+++ b/Lib/idlelib/macosxSupport.py
@@ -141,9 +141,9 @@
# menu
del Bindings.menudefs[-1][1][0:2]
The buttons on the Extensions Configuration aren't wide enough for the default Cocoa Tk 8.5 text on them (Ok, Apply, Cancel) so they overflow to two lines. In contrast, the similar buttons on the IDLE Preferences window display correctly.
On the ParenMatch configuration tab, there is a text box for "style" (with the default value of "expression"). There is no clue to what this means or what values are valid. Could this be some other widget if there is a known set of value?
If the enabled setting for CallTips are changed while edit windows are open, the existing windows are not affected. New edit windows do observe the new setting. (I didn't try this with other extensions.)
The appearance of the boolean options on the extensions panels vary among the various Tk's supported on OS X and none of the result are totally satisfactory; see the images in the zipfile upload. I think the main problem is that the widgets are centered in the frame. For Cocoa Tk, this results in a check box towards the left and the label centered in the remaining space. For the other two (Carbon 8.4 and X11, it results in a very wide toggle button.
It would probably be a good idea for someone who uses IDLE to do a more thorough review of all of the options on all of the Tk variants we support (e.g. Windows, Linux X11, OS X Cocoa, OS X Carbon, OS X X11). As this quick look shows, there are almost always differences (subtle and not so subtle) among them.
taleinat commentedon Jun 11, 2014
Ned, many thanks for the review and detailed feedback!
Here are responses to your comments
Thanks for the code suggestion regarding the menudefs! That's a good catch. I have an OSX box for such testing.
I'll check this out. Could you perhaps explain or point me to resources regarding how to run IDLE with various Tk implementations on OSX?
Unfortunately, IDLE's config mechanism doesn't have special support for options with only several valid values, as would have been ideal for ParenMatch's "style" parameter. As it is, these are just considered strings, and no explicit error occurs if an invalid value is specified. Without upgrading the config mechanism itself, the config dialog has no way of supplying the valid values and/or validating user input of such values. This could be useful, but should be considered a separate issue IMO. I would be happy to add relevant support to the dialog once the underlying support is implemented.
Regarding having thing updated only on new windows or after restart, AFAIK that is currently the case with many options in the existing config dialog. Ideally the behavior would be consistent for all config options, and even more ideally all config changes would take effect immediately. However, that would require major changes to IDLE. Again, I think this is outside the scope of this issue.
I completely agree that the button for boolean options looks horrible. Suggestions for a better Tk widget to use are welcome!
Finally, regarding
taleinat commentedon Jul 17, 2014
Bah, my original message was truncated!
I could use some help figuring out how to test with various Tk versions. I have a Mac with OSX 10.8, and I've found the "IDLE and tkinter with Tcl/Tk on Mac OS X" page[1], but I'm still not sure how to actually go about installing and running IDLE with the different versions.
ned-deily commentedon Jul 17, 2014
Tal, I'm working on something to make that easier.
taleinat commentedon Jul 17, 2014
@ned: Great! Please keep me posted.
python-dev commentedon Oct 9, 2014
New changeset 3f10b8009060 by Terry Jan Reedy in branch '2.7':
bpo-3068: Move idlelib.configDialog action button creation into a separate
https://hg.python.org/cpython/rev/3f10b8009060
New changeset f0e06514d67f by Terry Jan Reedy in branch '3.4':
bpo-3068: Move idlelib.configDialog action button creation into a separate
https://hg.python.org/cpython/rev/f0e06514d67f
terryjreedy commentedon Oct 9, 2014
Pushing a usable extension editor is my current Idle priority since the lack of one more or less blocks several other issues. The two big problems with the Feb 2014 patch are the actions buttons at the bottom and the true/false options.
I moved the cureent, apparently working ConfigDialog action button code into a new method that I believe can be re-used in ConfigExtensionDialog with
create_action_button = ConfigDialog.create_action_button
I nect incorporate this into the patch. (I pushed the change already because it makes the existing code clearer and easier to modify, by disentangling page code from button code.)
For binary options, I will use radiobutton pairs, as with ConfigDialog, if I cannot easily get a single button to look nice and work correctly.
terryjreedy commentedon Oct 9, 2014
Pending review on non-Windows systems, I believe the attached patch patch is about ready to commit (after re-enabling all tests). As for Ned's 5 points:
macosxSupport.py changes are incorporated.
Buttons should work with re-use of the ConfigDialog code. I altered create-action-buttons to incorporate the padding above the buttons.
The boolean option buttons were stretched because of 'sticky=NSEW'. Changing that to 'sticky=W' moves leaves them sized as specified and left-justified. Removing 'sticky=W' leaves them centered, but I think I prefer them to the left.
---
We could establish more option name conventions (as we already have for section names and 'enable..'). For instance, if we did not externally specify that 'enable' was bool, the file could have 'enable-type=bool'. For parenmatch, 'style-vals=expression, ...' would indicate the allowed values. If not too many (only 2 in this case, I think), radiobuttons could be generated. fg/bgcolor should have a color selector. Lets make this a followup issue.
It would be nice if ConfigDialog indicated somehow which. If nothing else, this could be part of the missing Help (especially if specific to the current page). Changes for the current window only should be only done by specific entries on the Option menu -- see below.
I think the proper answer depends on the option. AutoComplete popupwait should take effect immediately. Ditto for bgcolor, etc, for CodeContext.
On the other hand, CodeContext enable (for edit windows) should only affect new windows. On the line-number issue bpo-17535, I believe, we discussed the fact that the checkmark beside CodeContext on the Option menu has no relation to the current window and only refers to what will happen new windows. My understanding of the consensus is that Option/Context should toggle and indicate the current window while the default for future windows should be changes by changing .cfg (with this editor).
terryjreedy commentedon Oct 9, 2014
Saimadhav, can you review on linux? This is the blocker for line numbers.
A note on style: there is no need for leading underscores, so I removed them.
terryjreedy commentedon Oct 9, 2014
I think we should give each extension with options other than 'enablexx' a single 'option-help' option that gives the 'signature' of the extension. I suggest 'option-help', rather than just 'help', as the new 'reserved' option name as being more descriptive and less likely to already be in use in 3rd-party extension. Example (that indicates my ignorance of what the options mean ;-):
option-help=ParenMatch options
bell->bool: Ring bell on failure(??)
flash-delay->int: Milliseconds delay before ??
style->choice: expression, statement??
Parse by splitting on '\n', ':', and '->'.
->bool would cause the current value to be read as a bool and True/False button to be displayed.
->int would cause current value to be read as int and entered value to be checked as int
->choice would cause radiobuttons to be displayed.
->float should also be recognized
The Help button at the bottom should display information about enablexx options.
terryjreedy commentedon Oct 13, 2014
Saimadhav could not apply cfg-ext-34.diff, so uploading again, also with line-end whitespace removed. OSX test still needed.
SaimadhavHeblikar commentedon Oct 14, 2014
Can we have more padding at the right end of the text widget? For me, it appears attached to the scrollbar.
Shortcut key for Configure extensions should be different from Configure Extensions. By this I mean, with the Options menu open, there is no way to open "Configure Extensions" using the keyboard.(Also see sidenote 1).
Is there a need for "..." after Configure Extensions? I am asking this as don't know why it was there for "Configure IDLE..." in the first place.
User extension config files are created even if extension config settings are not dirty. Clicking OK or Apply without changing anything creates them.
Even if I change the setting for only 1 extension, extension config for all extensions are written to disk. This is unlike the behavior of "Configure IDLE" dialog.
There are a couple of places where Ok and Cancel are used. If I have understood PEP-8 correctly, aren't they not following it? Should they be ok and cancel instead?
Is there a reason to comment out the unittest and Htest in configDialog.py?(Other than "application has been destroyed .." messages?)
Sidenote 1 : Options menu unreachable via keyboard shortcut because both format and options have "O" as the keyboard shortcut.
Sidenote 2: I am writing the review comments here as review tool does not detect all the files affected by this patch. Please confirm, so that I will post this issue to the developer list.
--
Regards
Saimadhav Heblikar
taleinat commentedon Oct 14, 2014
I'll test on OSX tomorrow or during the weekend at the latest.
However, on OSX there are three different versions of Tk available, and I'm still not sure how to test with all of them. I'll try with one, at least, and see if I can figure out how to try the others.
terryjreedy commentedon Oct 14, 2014
Saimadhav, since you did not mention a problem with the appearance of the True/False button or the action buttons, which were issues before, I presume they are okay.
S1. For Shell, which does not have Format, alt-O opens Options. The hot key for Format should be changed to 't' so its addition does not diable O_ptions. I will do this in a separate patch.
S2. For my first patch, I see all 5 files. For -2, I only see entry for Binding.py. Odd since the only difference is the better line endings (and date stamps). When I uploaded this, it took about 10 minutes for 'review' to be added. I don't know if that is normal as I never paid attention before. Please post query.
I see the problem with the text entry boxes. I will look for a fix.
I have always been bothered by 'Options' -> 'Configure' -> 'Preferences'. Hotkeys should be 'I' and 'E'. I think 'Idle' and 'Extensions' might be enough, without 'Configure'.
I agree and will delete ... both places.
I have not actually looked at the file written, as Ned's review and my edits focused on glitches in the appearance of the dialog itself. I agree that if nothing is changed, nothing need be written. If anything is changed, the entire file has to be written. But I agree that for default extensions in config-extensions.def, only writing the delta, as done with config-main.cfg versus config-main.def, would be good. This requires noticing which extensions *are* in config-extensions.def. Sections for extensions only in the user file must be written back in full. I will look at how saving deltas works for config-main.cfg, but I may want to make this a followup patch.
I reused the names from the existing dialogs (config and others), which match the button label and handler name. These are the capitalized method names I find least bad. I would also be happy to change them just here or everywhere. I don't want this to hold up this patch if there is disagreement.
Commenting out is temporary, purely for development.
terryjreedy commentedon Oct 14, 2014
S1. The top menu bar hot keys are set in EditorWindow.menu_specs. 'Options' *can* be opened, at least on Windows, with alt O O <enter> (and Format with alt O <enter>). Conflicts are definitely Not Good. Any strong opinions on marking 'm' veras 't'?
terryjreedy commentedon Oct 14, 2014
Referring to previous item numbers, this new patch, relative to -2,
adds padx to gridding of entry widgets. (Note, editor text area runs against scroll bar in same way as these did, but without breaks, it looks fine.) Padding border looks better to me.
changes shortcuts to _I and _E.
deletes '...'.
---
With respect to
Save_all_changed_configs is supposed to only save if 'changes', and set_user_value is supposed to removed 'changes' same as default. I want to review these functions after uploading the changes above, along with addition of title and use of _htest in .__init__.
Reuse of create_action_buttons requires that action handlers have matching names in both dialogs. Since this does not affect dialog behavior, I want to defer this.
I intend to uncomment before pushing, but this does not affect dialog use.
python-dev commentedon Oct 14, 2014
New changeset 7ba47bbfe38d by Terry Jan Reedy in branch '2.7':
Issue bpo-3068: Change 0/1 to False/True so that extension configure dialog can
https://hg.python.org/cpython/rev/7ba47bbfe38d
New changeset 94f8d65371b7 by Terry Jan Reedy in branch '3.4':
Issue bpo-3068: Change 0/1 to False/True so that extension configure dialog can
https://hg.python.org/cpython/rev/94f8d65371b7
New changeset 111d535b52e8 by Terry Jan Reedy in branch 'default':
Merge with 3.4 bpo-3068
https://hg.python.org/cpython/rev/111d535b52e8
terryjreedy commentedon Oct 14, 2014
The reason for the apparent writing of unchanged values is that '0' != 'False' and '1' !- 'True'. With all booleans writen as 'False' or 'True', non-enable boolean items can be recognized and non-changes not seen as changes. I will next revise the patch and retest.
terryjreedy commentedon Oct 15, 2014
cfg-ext-34-4.diff: In this patch, default values are classified as bool, int, on other. An invalid user bool or int value is replaced by the corresponding default (which had to be a valid bool or int for the type to be set) and the invalid value is either removed or replaced by a valid value. To this extent, this dialog will repair a corrupted config-extensions.cfg. Int values get an entry box with validation.
The validation allows blank strings for int entries (which, of course are also allowed for 'other'. All non-key options for default extensions must have a value. So in set_user_value, if there is a default, a blank value is treated the same as if it were the default, and the user config line removed if there is one. So blanking an entry is a way to set is to the default value.
I think this is about ready to commit. It should first be tested with an added section in the user config for an added extension. I also think set_user_value should be able to use the already fetched and saved default value.
S2: For patch 3, Rietveld shows all 5 files. It momentarily showed 5 for patch 2, then reverted to just 1.
terryjreedy commentedon Oct 15, 2014
This version only allows configuration of default configuration. Added sections (for added extensions) are ignored. That will be a future enhancement.
Patch 5 makes changes in load_extensions and set_user_value so that var strings are compared to saved default strings. Before doing that, the value is stripped and if blank replaced with the default. The var is set to the adjusted value. After Apply, the user can see what the current config values are and if not default, what was written to the user config file.
terryjreedy commentedon Oct 15, 2014
Patch 5 was missing the last change. Ignore it unless here is a problem with 5a
python-dev commentedon Oct 23, 2014
New changeset 1d708436831a by Terry Jan Reedy in branch '2.7':
Issue bpo-3068: Add Idle extension configuration dialog to Options menu.
https://hg.python.org/cpython/rev/1d708436831a
New changeset d2a045855c4e by Terry Jan Reedy in branch '3.4':
Issue bpo-3068: Add Idle extension configuration dialog to Options menu.
https://hg.python.org/cpython/rev/d2a045855c4e
New changeset d70b70a661c6 by Terry Jan Reedy in branch 'default':
Merge with 3.4 bpo-3068
https://hg.python.org/cpython/rev/d70b70a661c6
terryjreedy commentedon Oct 23, 2014
Tal, thank you updating and submitting your patch. It fills a real hole in Idle customization. I am already using it to tweek the completion popup delay to find the best value for me.
I opened these followup issues.
bpo-22703 fix the behavior of Options / Code Context
bpo-22704 rethink 'enable_xyz' system and use consistently
bpo-22705 add 'option-help' option for doc and entry checking
bpo-22706 write [x] and [x_config...] sections together in user .cfg
bpo-22707 makes changes take effect immediately or indicate if not
I will later review this issue to see if I missed anything else.
I am leaving this open until I add a user-oriented news item and edit the Idle doc.
terryjreedy commentedon Oct 25, 2014
bpo-22726 Add help to both dialogs
python-dev commentedon Dec 4, 2014
New changeset 395673aac686 by Terry Jan Reedy in branch '2.7':
Issue bpo-3068: Document the new Configure Extensions dialog and menu entry.
https://hg.python.org/cpython/rev/395673aac686
New changeset b099cc290ae9 by Terry Jan Reedy in branch '3.4':
Issue bpo-3068: Document the new Configure Extensions dialog and menu entry.
https://hg.python.org/cpython/rev/b099cc290ae9