Mark Roseman added the comment:
Ok, do you want to add the dark theme in then? I'll add some code to the ttk
based preferences dialog (for when that gets in) to give the user the option of
applying the new background color to all the other elements which had the same
original background
Mark Roseman added the comment:
Have added the 'apply changes to other elements with same background?' feature
in my private copy. To save constantly uploading new versions on every tweak,
when we're ready to evaluate/integrate, I'll pass it along
Mark Roseman added the comment:
Doing some testing using "-n". Various close/quit scenarios are either
disallowed or broken as it turns out. I found that removing the "interacting"
check on close improved the matter quite substantially, so that I could quit
when the
Mark Roseman added the comment:
Looks good to me!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24820>
___
___
Python-bugs-list
Mark Roseman added the comment:
Have attached find-dialogs.patch, which does some cosmetic tweaks to the
existing dialogs, as per the previous screenshot. It uses ttk widgets if
available, and standard Tk widgets if not.
Relies on the ui.py module (not attached, as it is changing often
Mark Roseman added the comment:
Have attached help-indent-fix.patch. Basically the parser is very fragile when
it comes to combining tags, so the handling of the 'span .pre' was stomping on
the indent tag. Separated out handling of character level tags (e.g. italic)
from block level tags (e.g
Mark Roseman added the comment:
I'd suggest that there is no reason to include the list of what elements can be
coloured, as it's there in the dialog for anyone who wants to muck with it.
Just the first paragraph (two sentences) would be sufficient I think. Even
dropping it from the document
Mark Roseman added the comment:
I wrote a short utility that parses TextMate XML-based theme files (which are
also used by Sublime) and converts them into something IDLE can use. It's not a
perfect match, because IDLE's themes are more restrictive, but it's not bad.
I'm attaching the output
Mark Roseman added the comment:
Like #15347 and #15348, this was also caused by nested event loops, though the
exact problem is slightly different. I've attached fix-mainloop2.patch which
has a lengthy comment explaining the problem and how the patch solves it.
This patch also includes
Mark Roseman added the comment:
See #24455 for a patch that includes the changes from this one as well as some
additional changes that fixes that bug.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Mark Roseman added the comment:
Figured out the cause of this hang, it was to do with the nested event loops.
It turns out that mainloop() really should just be for the mainloop. Or at
least quit() should only be used to quit the outer loop, as it relies on
setting a static variable, so
Mark Roseman added the comment:
Have attached debugger-ui.patch, which greatly updates the user interface for
the existing debugger.
This also relies on some images that should be downloaded and unpacked into the
'Icons' directory: http://www.tkdocs.com/images/debugicons.zip
Summary
Mark Roseman added the comment:
Frighteningly, your wild idea is close to how it actually works now, as per the
ASCII art at the top of RemoteDebugger.py. :-)
The authors of RemoteDebugger and rpc.py went to fantastic lengths to make this
transparent so that everything looks local. If in my
Mark Roseman added the comment:
Regarding the nested loops, what's happening is:
- IDLE tells interpreter to run program
- Interpreter now has control and is running program, start to end
- Because execution is being traced, before every statement we get a callback
If we didn't use the nested
Mark Roseman added the comment:
Ok, I lied. The program runs through start to finish regardless, and all the
'stopping' and breakpoints is really just very selectively deciding which
subset of execution tracing events to pass back to the debugger. So you really
do need to 'block' in those
Mark Roseman added the comment:
I think both master and parent are needed, for the likely rare case when you
don't want a dialog attached to any window, but it needs a Tk window handle to
build the dialog from.
Ran across that in SearchEngine, which has a root window just for the purpose
Mark Roseman added the comment:
Attached masterparent27.patch, same thing for 2.7 branch
--
Added file: http://bugs.python.org/file40518/masterparent27.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Mark Roseman:
Follow-on to #25173, any regex errors are displayed by SearchEngine but they
should be shown by the dialog where the user is typing the error. Either as a
modal tkMessageBox attached to the dialog, or as an inline error in the dialog
itself
Mark Roseman added the comment:
No comment on state of Tkinter documentation. ;-)
I'll have a go through the uses of 'master' in IDLE and see which others should
be changed, and put together a patch. Plus double-check with all the other
dialogs in lib/tkinter to see if there are any other
New submission from Mark Roseman:
The confirmation, file, etc. common dialogs in tkinter accept both a 'master'
and a 'parent' argument. Master is not required (it will use parent if not
provided). Parent is used to associate the dialog with a given window. On Mac
OS X, using parent further
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1350>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20827>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21674>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21647>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8231>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21588>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14111>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24455>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20580>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5594>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21973>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2704>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22354>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15191>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17060>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11229>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18064>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14440>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15308>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18444>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18318>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1080387>
___
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12913>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20579>
___
_
New submission from Mark Roseman:
(This touches a bit on things mentioned in #14111)
I'm looking through the debugger code in IDLE, and now understand that it's
essentially trying to make a GUI program act like a command line program. Hence
the nested call to mainloop(), when we receive
Mark Roseman added the comment:
Thanks Raymond. As an 'outsider' I rely on people like you to provide feedback
based on your experience to some of the proposals I'm floating here.
On a more specific note...
This one came about mainly as I was looking at the class (module) browser. I
New submission from Mark Roseman:
Proposal for an alternative or perhaps replacement of both the code context
extension, as well as the class browser (rooted at a particular file, not the
path browser).
I'll direct your attention to the attached browser.png. On the right is IDLE's
class
Mark Roseman added the comment:
The new 'component' infrastructure provides the mechanism for passing these
kinds of notifications around. Allowing extensions (in whatever form they'll
exist with the new stuff) to take part in this notification mechanism would be
a small (and sensible
Mark Roseman added the comment:
FYI, I've gone past this point in my own playground, to the point of having a
working tabbed editor implementation. It's not that much further actually.
Here are the next steps:
1. Change so that Container is passed to Components on creation, rather than
Mark Roseman added the comment:
Debugger.py has a nested call to mainloop() ... which is almost always a bad
idea. I'm betting the close is being handled in this mainloop, and there are no
more events being generated, meaning the real mainloop towards the bottom of
PyShell (which checks
Mark Roseman added the comment:
Ok. In case you're curious or might find it useful elsewhere, I've attached
sphinxview.py, which renders the HTML into a text widget (with formatting, it's
not converted to plain text).
--
Added file: http://bugs.python.org/file40405/sphinxview.py
New submission from Mark Roseman:
A necessary prerequisite of tabbed windows, editor and shell in same window
etc. as per #24826, is that editors stop thinking they are in their own
toplevel window.
The attached component.patch is unfortunately long, but this was necessary due
to the highly
New submission from Mark Roseman:
This is a placeholder for what will be a series of patches to the FileList to
generalize and enhance it.
This is part of generalizing pieces of IDLE to be more flexible, including
things like editors not necessarily being in toplevel windows, dialogs
Mark Roseman added the comment:
This first patch is a straight refactoring so that other modules do not touch
the FileList internals.
This is done in two steps. First, we remove references to inversedict etc. from
outside FileList.
Second, we run all notifications through FileList. So
Mark Roseman added the comment:
Have attached about.patch, which changes the about dialog to no longer be
modal, as well as does a substantial redesign, where the various help texts are
displayed within the dialog itself, rather than launching (further modal) new
windows.
Note: this new
Mark Roseman added the comment:
See #24972 for fix
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22179>
___
___
Python-bugs-
Mark Roseman added the comment:
See #24972 for fix
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18590>
___
___
Python-bugs-
New submission from Mark Roseman:
Right now the menubar is slightly different for the shell (has Debug) and the
editor windows (has Format and Run). I'd like to suggest the same menubar be
used for all windows.
Rationale:
1. Easier to use, especially for systems that share a single menubar
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23551>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18590>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22179>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22460>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13586>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16893>
___
_
Mark Roseman added the comment:
See inactiveselection.patch. This addresses the original bug of the debugger
not highlighting the correct line, and also various issues with the find
windows not highlighting the selection they have found, e.g. #22179, #18590
--
keywords: +patch
Added
Mark Roseman added the comment:
Terry, the new code I've proposed includes a "tkextras" module that is a good
place for these sort of little convenience functions.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
New submission from Mark Roseman:
In the debugger, the values for the variables shown in the locals/globals panes
are editable (i.e. using Entry widget) but I don't see any mechanism to have
those changes affect anything. If I'm not missing something, why Entry and not
Label
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15348>
___
_
Changes by Mark Roseman <m...@markroseman.com>:
--
nosy: +markroseman
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15347>
___
_
Mark Roseman added the comment:
Thanks Terry, sorry I missed your previous mention of this. From what I recall
the treeview doesn't allow editable items, but what I've done in similar
circumstances before (editing text items on a canvas in drawing type programs)
was 'place' an entry widget
New submission from Mark Roseman:
Right menu button to invoke context menu (as well as alternative control-click)
not set up correctly for Mac in the debugger. Patch attached.
--
components: IDLE
files: debug-mac-context-menu.patch
keywords: patch
messages: 249582
nosy: kbk
New submission from Mark Roseman:
This is a followup to #14146
I don't think this is actually a Tk bug. The text widget supports an
"inactiveselectbackground" option which controls the background color of the
selection when the window is not active. On Win32, this is defined as e
Mark Roseman added the comment:
I'm not against generality, though don't think there are many places this
actually comes up (the cloned menus shouldn't be affecting more than a couple
people these days, and aren't the result of an explicit API call).
For this particular call (peer_create) I
Mark Roseman added the comment:
Config files affecting tests (and tests affecting config files!) is an issue.
Would like to see config files written into a different directory when running
tests. Any concerns with doing that?
--
___
Python tracker
Mark Roseman added the comment:
Attached uipreferences.py, which is a newer and more complete version of the
one in prefs-wip.patch
--
Added file: http://bugs.python.org/file40276/uipreferences.py
___
Python tracker rep...@bugs.python.org
http
Mark Roseman added the comment:
Have attached uitabs.py. From the header comments:
Standalone 'tabs' widget to switch between multiple different views.
Unlike the Tkinter ttk.Notebook widget, this widget is suitable for
displaying a potentially large number of tabs, as might be found
Mark Roseman added the comment:
Have attached debugpanel.py, implementing a ttk-based mockup of one possible
redesign of the debugger UI, as seen in
http://bugs.python.org/file40234/newtabs.png
--
Added file: http://bugs.python.org/file40266/debugpanel.py
Mark Roseman added the comment:
Have attached newTabExtension.py, which is Roger's tab extension, hacked to use
uitabs.py instead of the UI previously built into that extension.
--
Added file: http://bugs.python.org/file40265/newTabExtension.py
Mark Roseman added the comment:
I've put together a standalone tabs widget (mostly done) based on Tk canvas
widget, that emulates the behaviour of TextMate's tabs. I was able to modify
Roger's extension to use this widget. See attached screenshot newtabs.png (tabs
area is fully functioning
Mark Roseman added the comment:
Just came across this one (Terry I'm sure can figure out why).
I'm sympathetic with Guilherme's wish that Tk had done this one differently, as
an option to specify an existing text widget peer when creating a text widget,
rather than having the original spawn
Mark Roseman added the comment:
Did a quick check... this approach seems to work. Only change was in step 4
should set both ._w and ._name for the widget object
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17945
Mark Roseman added the comment:
Regarding the setting background for the multiple elements.. one possibility is
that the first time in a session they change the background of an element that
was same as the background, we ask if they'd like to apply that change to the
other program elements
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24893
___
___
Python-bugs-list
Mark Roseman added the comment:
I reproduced your problem on Windows, and verified that it wasn't an issue on
either Mac or Linux.
Your fix however, didn't change anything for me (on a Windows 7 VM). I tried a
few other things (raising the window, playing with various wm attributes, etc
Mark Roseman added the comment:
Watched that video clip - yikes, that is bad.
I tried playing around to reproduce it, but haven't had any success yet, though
did find another weird thing. If you have a bunch of short lines without any
blanks, sometimes when you click well to the right of all
Mark Roseman added the comment:
Alessandro, would you have a chance to test this one line patch, which makes
calltips work again on OS X?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24570
Mark Roseman added the comment:
Sounds like this one should be ready to review and incorporate.
As a reminder, mainwin3.patch, which should work on Tk 8.4+, gets rid of the
highlightthickness around the text widget in the editor, the sunken line/column
effect in the status bar, and adds
Mark Roseman added the comment:
Terry, when you get a chance, it would be great if you could have a look at
demodalize.patch (or if you can suggest someone else who would be good to take
a peek at it).
This is sort of the baseline for the uifactory, and touches a lot of things in
small ways
Mark Roseman added the comment:
Have attached macpopup-revised.patch, incorporating Serhiy's very helpful
suggestions. Unless there are any other thoughts, this one is probably ready to
go.
--
Added file: http://bugs.python.org/file40208/macpopup-revised.patch
Mark Roseman added the comment:
I am admittedly not a fan of skinnable user interfaces, especially for
non-entertainment applications. It doesn't add anything to the usability, and
makes support harder. It always says to me hello, 2002 called and wants it's
user interface back. I think
Mark Roseman added the comment:
Yes that should be good to go
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24782
___
___
Python-bugs-list
Mark Roseman added the comment:
Agree about the font resizing menu items/shortcuts... your original #17642
remains open for this
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24776
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24790
___
___
Python-bugs-list
Mark Roseman added the comment:
Looking to get some feedback on a large chunk of new code (not yet complete),
for the 'new' preferences dialog. Not so much UI things as if I've made any
glaring structural errors which aren't obvious to this Python sorta-newbie.
For lack of a better place
Mark Roseman added the comment:
There is no notion of middle button on Mac, hence right button is B2. It's
documented. Current Tk 8.6 has even removed the PasteSelection binding from
B2 on Aqua because of this (I've filed a Tk bug report to backport this to
8.5). 8.6 also defines
Mark Roseman added the comment:
Awesome, thanks Kevin. Have attached calltip.patch. The extra lift() call
doesn't seem to hurt on Windows or X11, so didn't make it conditional.
--
keywords: +patch
Added file: http://bugs.python.org/file40173/calltip.patch
Mark Roseman added the comment:
Exactly. The querydialog code (which will replace the simpledialog
askstring/askinteger calls) displays errors as shown in querydialog.png, with
the error messages disappearing as soon as you hit another key.
You can also pass in a 'validator' to check
New submission from Mark Roseman:
One of the concerns with making significant structural changes to the IDLE
codebase is breakage of external that might import a piece of idlelib (so not
just 'import idlelib' but a particular submodule).
PEP 434 already makes the case that this behaviour
New submission from Mark Roseman:
In EditorWindow.open_module... once switch to querydialog, display errors (e.g.
module not found) in askstring dialog itself, not open up subsequent
'showerror' dialog
--
components: IDLE
messages: 248539
nosy: kbk, markroseman, roger.serwy
Mark Roseman added the comment:
Work in progress, have a few more tweaks to make, but here's a snapshot...
--
Added file: http://bugs.python.org/file40176/querydialog.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24860
101 - 200 of 272 matches
Mail list logo
