TkDocs is a language-neutral resource for developers who are interested
in using Tk as their GUI. The highlight is an extensive tutorial that
illustrates how to use the newest generation of Tk features and best
practices to create modern and attractive user interfaces.
I'm pleased to
Paul Rubin http://[EMAIL PROTECTED] wrote:
However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.
People should probably be more aware of work that has been going on
Mike Meyer [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Alex Martelli) writes:
Maybe that's the key difference between the mindset of a
mathematician and that of an engineer -- I consider reaching over
95% of visitors to be _quite good indeed_,
What surprises me is that marketing types will
You elided the paragraph where I pointed out the third alternative:
provide a better experience for the 95%, and an ok experience for the
5%. WWW technologies are designed to degrade gracefully - it's easy to
take advantage of that.
What I'm suggesting is taking the effort you'd put to the
Ed Leafe [EMAIL PROTECTED] wrote:
On Sunday 31 July 2005 12:03, Paul Rubin wrote:
How on earth did you decide that, since tkinter actually runs out of
the box when you install Python on most platforms, and wxPython doesn't?
Because Tkinter looked like crap on OS X. Sorry, but it's hard
How can I embed a browser in Tk (I mean a real browser, like Mozilla,
Safari, or even Exploder)? At all? On any platform? This has always
been the tradeoff for Tk.
Try this as one example:
http://wiki.tcl.tk/4094
Tk is great for learning, easy to write small, basic interfaces,
Paul Rubin http://[EMAIL PROTECTED] wrote:
Cliff Wells [EMAIL PROTECTED] writes:
Still, that leaves Linux and Mac out in the cold. But I'll admit you
met my challenge. Most likely you can actually do most of the things
with Tk you can with Wx, it's simply a matter of how much effort is
Peter peter.milli...@gmail.com wrote:
Besides, the book is mainly about using Python with Tkinter - and
Tkinter hasn't changed that much since 2000, so I believe it is just
as relevant today as it was back then.
I'd say that Tkinter has substantially changed - with the introduction
of the
With regard to Tkinter documentation, and in particular the newer, more
modern aspects thereof (e.g. ttk, styles, etc.) please have a look at
the tutorial at http://www.tkdocs.com
Would it be useful to link to this from the main Python Tkinter
documentation?
Mark
--
r rt8...@gmail.com wrote:
On Aug 28, 11:12 am, Mark Roseman m...@markroseman.com wrote:
Would it be useful to link to this from the main Python Tkinter
documentation?
Thanks Mark, but i would hate to see more links to TCL code in the
python docs. Whats the use of Tkinter if the docs
MRAB pyt...@mrabarnett.plus.com wrote:
Manzur Ahmed wrote:
i wanted to ask you if one of you could help me to use Tkinter. i'm
trying to just create a simple GUI for which I have provided the code
for below.
There are some differences between Python 3.x and Python 2.x. In Python
3.1
So let me hear of ANY improvements and/or suggestions for Tkinter/IDLE
docs, code, or whatever.
Why don't you modify the IDLE code to use the newer ttk widget set,
rather than what its using now? You'd be surprised at how much
difference you'll see.
--
I'll venture to say that the path of least resistance (which includes
little or modest development effort) would be for Python to retain
Tkinter in the way it does now, but have Tkinter GUI's magically appear
less horrid.
Guess what? That's already happened. Newer versions of Tk (which
bart.c ba...@freeuk.com wrote:
Grant Edwards inva...@invalid.invalid wrote in message
Since Tk already provides a basic GUI toolset, and Python can interface
with it more directly than it can with other toolkits
(PyGui - PyGtk - Gtk - Xlib),
Compare that to this:
TkInter - Tcl -
Martin v. Loewis mar...@v.loewis.de wrote:
For the record, Python *does* include newer versions of Tk all the time.
Martin, just to reinforce the point... developers using Tkinter need to
make some fairly minor changes to their application code to truly take
advantage of the improvements in
Martin v. Loewis mar...@v.loewis.de wrote:
To quote from the first section of the tutorial at http://www.tkdocs.com
Unfortunately, neither that tutorial nor your postings are really
specific on what those changes might be. So I'm skeptical that they
actually exist, or, if they exist,
rantingrick rantingr...@gmail.com wrote:
As is evidenced by the lack of
development for Tkinter. But with Tkinter there is a larger problem,
TclTk! Even Tk is not a full featured GUI library
Please, enough of this nonsense rant already! :-)
Discounting completely and without evidence or
If you guys spent 1/10th as much time articulating the problems you see
with Tkinter (and being willing to listen when people offer solutions)
as you do trying to convince everyone else you're right, you'd probably
have ... well, anyway, no sense in being practical.
--
Octavian,
Thank you for clearly articulating your concern that Tk does not provide
any support for screen readers.
While I believe that people can have legitimate differences of opinion
as to whether this merits its removal/replacement from stdlib, there is
no question that this is a serious
Octavian Rasnita orasn...@gmail.com wrote:
But unfortunately it is not accessible for screen readers and it
discriminates many potential users.
Octavian, thank you for very clearly making and repeating your point
about screen readers. It is very obvious that at this point in time Tk
(and
Littlefield, Tyler ty...@tysdomain.com wrote:
Rather, I believe
those pushing accessibility should concentrate on the root cause; that
of fixing TKInter, and not forcing everyone else to use a different library.
Here, here. From my queries to some of the Tcl/Tk folks, it seems that
while
Terry Reedy tjre...@udel.edu wrote:
Tk itself is purely a gui package -- abstract widgits, geometry placers
to make them visible, and an event system to make them active. But it
does have the baggage of needing tcl included. About a decade ago, some
people had the idea of removing the tcl
Terry Reedy tjre...@udel.edu wrote:
1. The performance issues of having Tk use Tcl are negligible; the bulk
of Tk (code-wise and time-wise) are spent in C. Tcl itself is also very
fast nowadays, using all the usual techniques that modern dynamic
languages use.
I have the impression
Dietmar Schwertberger n...@schwertberger.de wrote:
But the fact that Tkinter is still the standard GUI toolkit tells a lot
about the situation...
...
Sure, I know how to code GUIs. But the learning curve is too steep
for new users wanting to implement simple GUIs.
As is obvious to
Rick Johnson rantingrickjohn...@gmail.com wrote:
Book authors and Doc authors are not always the most well informed; as
we have witnessed by this very thread! Obviously these tutorials are more
like: What NOT to do when coding Tkinter GUIs! No wonder everyone hates
Tkinter. :-)
Indeed.
Hi Richard,
I would strongly second the advice that Kevin provided: rewriting is a
substantial step not to be taken lightly. If a mere facelift is desired,
migrating to the more modern tools provided in recent versions of Tcl/Tk
may well meet your needs at a fraction of the cost/effort.
For
Mark Roseman added the comment:
The squares next to foreground/background are placeholders for those controls I
can't remember what they're called (colour wells?) where it shows the current
colour, and clicking it brings up a colour picker allowing you to change. So
separate ones
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24039
___
___
Python-bugs-list
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2053
___
___
Python-bugs-list
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9262
___
___
Python-bugs-list
Mark Roseman added the comment:
Yes that's exactly what I was thinking. If everything is a frame rather than a
toplevel it'll be much easier to reconfigure things.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24826
Mark Roseman added the comment:
I did some followup on this today, and could reproduce it with a few lines of
Tcl/Tk code. As Ned noted, it seems particular to the ActiveTcl build, as when
I built my own 8.5.18 it also worked fine.
(If you're curious, the thing that is failing
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:
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
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
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:
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:
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:
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/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
New submission from Mark Roseman:
By default, IDLE chooses courier for the text editor font.
As you'll see from the attached screenshot, while this looks ok on Windows,
it's inconsistent with the standard fixed width fonts on Linux and OS X, and
borders on unreadable particularly
New submission from Mark Roseman:
The screen shot shows the current version of the main IDLE window, with the
little pics at the bottom indicating what it looks like when the window loses
focus. A few entirely cosmetic changes I'd like to make here:
1. Swap scrollbar for ttk scrollbar
Mark Roseman added the comment:
Same changes for 2.7 branch
--
Added file: http://bugs.python.org/file40059/tearoff27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13884
Mark Roseman added the comment:
Quick question how best to represent this in the config-main.def file. My
thought is to leave a font= line there so that the GetOption call returns an
empty string. The editor code can then detect that and substitute TkFixedFont.
Would this break anything
Mark Roseman added the comment:
As indicated in prior comments, the tearoff menus are strictly a holdover from
ancient Motif, and are no longer found in current user interfaces on any
platform. Because of that, I would strongly support deleting them altogether,
rather than making available
Mark Roseman added the comment:
I'm ok with putting TkFixedFont in the config file. Only potential downside I
see is that the code will look for this specific value, but people may read the
config file and assume it could be changed to any Tk*Font.
I'd strongly argue against putting
Mark Roseman added the comment:
Sounds good. To clarify, (2) refers to not the overall window, but just around
the text widget. Both regarding this and the comments regarding status bar (4),
things look really good now on Windows. The changes I've made are barely
perceptible
Mark Roseman added the comment:
Doing it via the option database vs. on each menu would be my preferred
approach. The option database is global, not per toplevel, so would cover
everything. Only 'downside' is the whole its-not-an-application-its-a-library
thing, though in the highly unlikely
Mark Roseman added the comment:
Serhiy, I appreciate what you're saying, but special casing to handle both ttk
and non-ttk cases seems not feasible given the amount of resources available to
enhance/maintain IDLE. Additionally, part of the rationale for making these
changes is to simplify
Mark Roseman added the comment:
Got it re: 2.7/3.4. So the only stumbling block left to 8.5/ttk in 3.5 would be
the current Mac build that is ok with Tcl/Tk 8.4...?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24759
Mark Roseman added the comment:
What do you think of the layout in cfg_font_layout.png? (before/after)
--
Added file: http://bugs.python.org/file40105/cfg_font_layout.png
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24776
Mark Roseman added the comment:
For illustration, attached idle_find_ttk.png, which is a minor layout tweak of
the existing one (works on all the various find dialogs, though not shown in
screen shot). I agree with Al's other suggestions here.
--
nosy: +markroseman
Added file: http
New submission from Mark Roseman:
I'm wondering about moving the functionality of the 'configure extensions'
dialog into the main configuration dialog. As I don't know the history here,
I'm wondering why it was made separate.
My proposal would be to add an 'Extensions' tab in the main config
Mark Roseman added the comment:
One of the other options I was playing with previously was a listbox for
choosing the theme (what I'd suspect is the main user activity here).
--
Added file: http://bugs.python.org/file40110/cfg_highlight_alt.png
Mark Roseman added the comment:
Incidentally (and this I would say is a definite bug) because the modal doesn't
fully work on the Mac, you can actually create multiple copies of the config
dialog!
--
___
Python tracker rep...@bugs.python.org
http
New submission from Mark Roseman:
Placeholder for improvements to the syntax highlighting tab in IDLE config
dialog.
I've attached cfg_highlight.png which shows a before and after I'm suggesting
as a starting point. It would have the same functionality but uses a lot less
pieces to implement
Mark Roseman added the comment:
While I think this approach would largely be a bad idea for an IDLE-sized
application, where I think it definitely would be useful is in something very
restricted like the tkSimpleDialog code.
To improve the various little 'askstring', 'askinteger' etc
Mark Roseman added the comment:
cfg_highlight_alt.png shows with the listbox for choosing a theme
Also added highlight3.png... same kind of thing, but by renaming the tab as
'Themes' you no longer even need the row of labels at the top. And it parallels
the fonts/tabs design suggestion
Mark Roseman added the comment:
Great. Sent in the contributor agreement Monday so I assume it should percolate
through soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24750
Mark Roseman added the comment:
Sounds good. Only suggestion, given it's user facing, is to have the error
message point them towards a solution. Off the top of my head, maybe something
like IDLE requires Python be configured to use Tk 8.5 or newer (you have Tk
x.x) with a title of IDLE
Mark Roseman added the comment:
The attached mainwin.patch implements these few small changes (except for
removing the Mac grow box space); checked active/inactive on Mac, Windows,
Linux.
--
keywords: +patch
Added file: http://bugs.python.org/file40070/mainwin.patch
New submission from Mark Roseman:
Is there any reason the IDLE settings dialog is modal?
(Actually while it is modal on Windows and Linux, on OS X you can actually
switch back to the main window while the settings dialog is up, but you can't
actually type etc. into it!)
While I could
Mark Roseman added the comment:
Ok, I'll do some playing around with that one over the next few days, and see
if anything comes up.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24760
Mark Roseman added the comment:
The mainwin2.patch keeps the width of the fields constant. Thanks!
--
Added file: http://bugs.python.org/file40071/mainwin2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24750
Mark Roseman added the comment:
I'll raise the practical matter that ActiveState no longer distributes 8.4.x as
part of its Community edition ActiveTcl, though I presume it would be available
as part of its for-fee Business version. Therefore if someone wants to use
Python on 10.5, it would
Mark Roseman added the comment:
Ned, quick question... if there is a tcl/tk 8.5.x on the system, will the 32
bit prebuilt distros link with it, or only with a 8.4.x version?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Mark Roseman added the comment:
I've attached defaultfont.patch which will look for the magic value
'TkFixedFont' in the configuration file and do some appropriate magic with it.
Most of the font handling smarts are now in a 'GetFont' call in configHandler,
which as a bonus reduces some
Mark Roseman added the comment:
Screenshot extdlg.png shows result
--
Added file: http://bugs.python.org/file40119/extdlg.png
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24782
Mark Roseman added the comment:
I've attached extdlg.patch, which changes the UI for the configure extensions
dialog.
In particular, it replaces the stacked tabs with a listbox on the left, with
the details of each extension appearing in a labelframe on the right. The
inside
Mark Roseman added the comment:
I read #7949 as saying the text widget picks up the background color from the
system-wide GTk theme.
This one is saying that the background color of the text widget should be
changeable as part of an IDLE highlighting theme
Mark Roseman added the comment:
Have attached macpopup.patch which removes the incorrect Tk behaviour and makes
it so that right click on Mac will bring up the context menu as appropriate.
--
keywords: +patch
Added file: http://bugs.python.org/file40148/macpopup.patch
Mark Roseman added the comment:
I'm attaching mainwin3.patch, which is a subset of the previous patches,
modified to not use ttk. It gets rid of the highlightthickness, the sunken
line/column effect, and adds a thin separator below the text widget.
--
Added file: http
Mark Roseman added the comment:
note that many of these are using 'simpledialog' which has that limitation
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24812
Mark Roseman added the comment:
The attached demodalize.patch (which includes the changes from the previously
posted decouple_config.patch) changes both the settings dialog and the about
dialog to be non-modal.
There's a new class UIFactory which is responsible for launching these kinds
Mark Roseman added the comment:
I've attached functionaltests.patch which provides a starting point, using Tk
introspection and event generation to exercise the running application. The
heart of it is the (very much in progress) TkTestCase class which provides a
bunch of Tkinter-specific
New submission from Mark Roseman:
This is a placeholder issue for adding automated functional/integration tests
to complement the existing unit tests.
--
messages: 248428
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE
Changes by Mark Roseman m...@markroseman.com:
--
components: +IDLE
keywords: +patch
Added file: http://bugs.python.org/file40164/functionaltests.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24845
New submission from Mark Roseman:
Undo/Redo in Edit menu should be disabled when there is nothing to Undo or Redo
--
components: IDLE
messages: 248168
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Disable Undo/Redo menu items when
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1528593
___
___
Python-bugs-list
New submission from Mark Roseman:
Right now when you're running a program you can still select the 'debugger'
item in the menu... you just get an error dialog you can only toggle the
debugger when idle (with a title don't debug now).
While I got a kick out of the title and using the word idle
New submission from Mark Roseman:
If I have just an edit window open with my program, there's no way to run the
program with the debugger visible. Should be a way to do so without going
through the extra steps of opening up a shell window first
--
components: IDLE
messages: 248175
New submission from Mark Roseman:
It's fairly easy to get IDLE to revert back to an empty menubar, i.e. just a
Python menu.
For example, open a shell, debugger, and editor window. Click on debugger
window, then editor window, then close editor window. Focus goes back to
debugger, but doesn't
New submission from Mark Roseman:
Most of the dialogs in IDLE on OS X do respond to 'Return' key as equivalent to
hitting OK, and Escape to hitting Cancel.
Guidelines also suggest that the Enter key (on numeric keypad) should work like
'Return', and Cmd-. (period) should work like Cancel
New submission from Mark Roseman:
No reason for it to be modal. Especially on OS X (where it really isn't...)
--
components: IDLE
messages: 248167
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: About IDLE dialog shouldn't be modal
New submission from Mark Roseman:
Rather than including the window width/height in the config dialog, just
remember the last window size and use that next time
--
components: IDLE
messages: 248176
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status
Changes by Mark Roseman m...@markroseman.com:
--
nosy: +markroseman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17642
___
___
Python-bugs-list
New submission from Mark Roseman:
In an editor window, with no selection, most of the items in the format menu
(indent, tabify, etc.) aren't applicable, so the corresponding menu items
should be disabled.
--
components: IDLE
messages: 248171
nosy: kbk, markroseman, roger.serwy
New submission from Mark Roseman:
If there are going to be highlighting themes in IDLE, and the ability to
customize them, why not the background color of the window? Light on dark is
easier for some people to read - adding one that did that would be a good
candidate for another built
Changes by Mark Roseman m...@markroseman.com:
--
components: +IDLE
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24801
___
___
Python-bugs-list
New submission from Mark Roseman:
Right now breakpoints can only be set/cleared by using a context menu on a line
in the editor. I discovered this entirely by reading through the bug database,
as right-click doesn't work on OS X (#24801).
Some other tools use an indicator (e.g. stop sign
New submission from Mark Roseman:
This builds on things like the tabbed editor suggestion, but essentially I'm
talking about a scenario where you'd have your one (editor) window open working
on your program, you click 'run...' or 'debug...' from the menu, and a shell
and debugger area open up
1 - 100 of 299 matches
Mail list logo
