[issue27603] Migrate IDLE context menu items to shell extension

Change by Terry J. Reedy : -- assignee: terry.reedy -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27603] Migrate IDLE context menu items to shell extension

Change by Terry J. Reedy : -- assignee: -> terry.reedy components: +Installation ___ Python tracker ___ ___ Python-bugs-list

[issue27603] Migrate IDLE context menu items to shell extension

Terry J. Reedy added the comment: Steve, is this out of date or still something that could be done in the code we control? Would you review and possibly merge a patch is submitted? (I don't know what 'shell extension' means.) -- versions: +Python 3.10 -Python 3.6

[issue27603] Migrate IDLE context menu items to shell extension

Shane Smith added the comment: Since you're a developer, I'm sure you need a lot of versions installed so you can check for backwards combatibility (spelling intentional). But until recently, only the most recent IDLE was in the context menu, so I'm guessing your workflow for that checking

[issue27603] Migrate IDLE context menu items to shell extension

Steve Dower added the comment: The last time I saw collected data on usage (based on Visual Studio users), there was no clear majority of "number of interpreter versions", but 3 was the most common (2 and 4 were roughly equal, 5 and 6 were more popular than 1). The nesting also makes it

[issue27603] Migrate IDLE context menu items to shell extension

Shane Smith added the comment: I'm fine with a single implementation, so long as the implementation is what's best for the majority of users. Not my intent to increase the burden of work. So, let me ask the question alluded to in my first post: when is a nested menu actually desirable? I

[issue27603] Migrate IDLE context menu items to shell extension

Steve Dower added the comment: More user choice here is actually an incredibly huge burden. Managing file associations across a range of versions, many of which can no longer be updated, is hard enough without offering options. Not to mention the extra user interface required. Personally,

[issue27603] Migrate IDLE context menu items to shell extension

Shane Smith added the comment: Hi Vedran, that seems to now be the default behavior, regardless of previous installs (my 3.6 was a clean install, and it's still nested). Kind of a pain if you want to edit with IDLE frequently. While we wait for a more integrated solution, the hackish way to

[issue27603] Migrate IDLE context menu items to shell extension

Vedran Čačić added the comment: Even worse: I had both 3.5 and 3.6 installed, and then uninstalled 3.5 when 3.6 was final (I suppose I'm not the only one). Now I have the nested menu with only one item, Open with IDLE 3.6. :-\ -- nosy: +veky ___

[issue27603] Migrate IDLE context menu items to shell extension

Changes by Terry J. Reedy : -- assignee: terry.reedy -> ___ Python tracker ___ ___

[issue27603] Migrate IDLE context menu items to shell extension

Shane Smith added the comment: Would it be possible to allow the user to select whether they'd prefer a nested or flat context menu at install? I believe it went to nested as a result of issue23546. Unless there are a large number of installations (arbitrarily... perhaps 4 or more), the

[issue27603] Migrate IDLE context menu items to shell extension

New submission from Steve Dower: Currently (on Windows) we register a set of subcommands in order to display an expanding list of versions of IDLE when users right-click a .py file. With issue27469, a proper shell extension was added, which means we can now use IContextMenu to implement the

[issue27603] Migrate IDLE context menu items to shell extension

Steve Dower added the comment: Another idea: we can also provide extra ("extended") commands when the user holds Shift and right-clicks a file. We could use this to add items to do "-r file.py" with IDLE, which would run the file with IDLE and leave the Shell open. --