From kmmcdonald at wisc.edu Wed Mar 17 01:54:47 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Wed Mar 17 01:56:33 2004 Subject: [Tkinter-discuss] Some random thought, looking for feedback Message-ID: Hi all. Thanks to all those who set up the list for the rest of us! Here's a thought I had about Python/Tk in general. I've recently been doing some funky stuff with the Text widget, and in order to make my own life easier, I've come up with Python classes that wrap marks and tags. The main reason to do this is that once marks and tags are objects they are (IMHO) much easier to use and extend. For example, I can say something like: mytag = instanceofmytextsubclass.tagat(index) Now that it's an object, I can extend its behavior easily and also can refer to it without referring to its containing widget. For example, I might implement a function to see if a tag touches a given index, and then just use it as if mytag.touches(index): ... In fact, using those objects, I've been able to implements a useful Range class, which can be used to cover a range of text like a tag, but which does not disappear if the text it encloses disappears, i.e. like a mark, and which can also be identified uniquely (through its enclosed mark), or as one of many ranges of the same "type" (through its enclosed tag.) This was relatively easy using the wrapper classes, but would have been, I believe, rather more difficult if done with Tkinter alone. I'm now starting to get into event handling and, as it turns out, seem to be doing the same sort of thing with events, writing wrapper classes. Since events apply throughout Tk and not just in the Text widget, this got me wondering if it would be worthwhile (and if there was any interest in) layering a more Pythonic layer atop Tkinter. I could see this being useful in a number of ways, not least in adding a certain amount of "self-documentation" to the library (since python users would be looking mostly at python code for reference, rather than at code which more thinly wraps Tcl), and perhaps in permitting non-Tkinter users to more easily use Tk. This is nothing against Tkinter, it's a great package, I'm just wondering if it is worth the effort to add a more object-oriented layer on top. Comments most appreciated. Thanks, Ken From FBatista at uniFON.com.ar Wed Mar 17 11:51:28 2004 From: FBatista at uniFON.com.ar (Batista, Facundo) Date: Wed Mar 17 11:53:09 2004 Subject: [Tkinter-discuss] Tkinter aesthetic Message-ID: The other day in #python at irc.freenode.net, an user told me that Tkinter under Linux is *very* ugly (he migrated to GTK+ because of this). Is there a plan to beautify it? Thank you! . Facundo From claird at lairds.com Wed Mar 17 12:06:42 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 12:07:09 2004 Subject: [Tkinter-discuss] Tkinter aesthetic In-Reply-To: Message-ID: > From tkinter-discuss-bounces@python.org Wed Mar 17 11:53:10 2004 > . > . > . > The other day in #python at irc.freenode.net, an user told me that Tkinter > under Linux is *very* ugly (he migrated to GTK+ because of this). > Is there a plan to beautify it? > . > . > . Yes, no, and yes. This mailing list is where Tkinter stuff is happening (well, it's *really* happening on Fredrik's desktop, but let's consider that as an extension of the mailing list, for the moment), so, until we plan it, no, there's effectively no plan. ON THE OTHER HAND, this is a big issue for the Tcl/Tk folks, and they've already made enormous progress (incidentally, I'm unhappy with that page; by this weekend, I'll redo it to make it easier to read). One conclusion: even if Tkinter folk do nothing except track upcoming Tk releases, visuals under Linux will improve a bunch over the next year. From FBatista at uniFON.com.ar Wed Mar 17 12:14:03 2004 From: FBatista at uniFON.com.ar (Batista, Facundo) Date: Wed Mar 17 12:15:46 2004 Subject: [Tkinter-discuss] Tkinter aesthetic Message-ID: claird@phaseit.net: #- This mailing list is where Tkinter stuff is happening (well, it's #- *really* happening on Fredrik's desktop, but let's consider that #- as an extension of the mailing list, for the moment), so, until #- we plan it, no, there's effectively no plan. #- #- ON THE OTHER HAND, this is a big issue for the Tcl/Tk folks, and #- they've already made enormous progress (incidentally, I'm unhappy with #- that page; by this weekend, I'll redo it to make it easier to #- read). One conclusion: even if Tkinter folk do nothing except #- track upcoming Tk releases, visuals under Linux will improve a #- bunch over the next year. I'm happy with this. I'm not in a hurry, simply wanted to know if the "beautifying process" was stopped or ongoing. Anyway, by the time I'll finish my project, we'll have holograms on the desktop, :p Thank you! . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA La informaci?n contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener informaci?n confidencial o propietaria, cuya divulgaci?n es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no est? autorizado a divulgar, copiar, distribuir o retener informaci?n (o parte de ella) contenida en este mensaje. Por favor notif?quenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magn?tico) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telef?nica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electr?nicos pueden ser alterados, motivo por el cual Telef?nica Comunicaciones Personales S.A. no aceptar? ninguna obligaci?n cualquiera sea el resultante de este mensaje. Muchas Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/tkinter-discuss/attachments/20040317/826daa1e/attachment.html From jepler at unpythonic.net Wed Mar 17 12:18:50 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 17 12:18:54 2004 Subject: [Tkinter-discuss] Tkinter aesthetic In-Reply-To: References: Message-ID: <20040317171849.GM2446@unpythonic.net> On Wed, Mar 17, 2004 at 01:51:28PM -0300, Batista, Facundo wrote: > The other day in #python at irc.freenode.net, an user told me that Tkinter > under Linux is *very* ugly (he migrated to GTK+ because of this). > > Is there a plan to beautify it? We're captive to what the tcl/tk folks give us, for the most part. Tcl/Tk 8.5 (I tried a CVS version a few weeks ago) looks visually much better on Linux, mostly for the following reasons: * Support for subpixel rendering of fonts (./configure --enable-xft) * The indicator on checkbuttons and radiobuttons has a "windows style" instead of the old motif style. * The images in tk_dialog are now in color Another glaringly ugly widget, the scrollbar, doesn't appear to have changed. There are some ugly hacks to make Tk (as far back as 8.2) place win95-look images over the ugly motif-style widgets, but the code is written in Tcl and is likely to turn your stomach: http://unpy.net/cgi-bin/viewcvs.cgi/nf/rb.tcl http://unpy.net/cgi-bin/viewcvs.cgi/nf/cb.tcl http://unpy.net/cgi-bin/viewcvs.cgi/nf/sb.tcl A combobox has yet to be added, but bwidgets has one that looks pretty much like win95. (I've never tried the bwidgets wrappers, which are at http://effbot.org/zone/bwidgets.htm) Setting up a good options database helps, too, for instance by making the background of entry and text widgets white, and by using a normal-weight sans-serif font. Something along the lines of http://unpy.net/cgi-bin/viewcvs.cgi/nf/options.tcl?rev=1.20.6.1&content-type=text/vnd.viewcvs-markup Tk still doesn't do fancy stuff like track the Gnome or KDE theme, which is what you'd really want. Jeff PS If you want to try tk8.5 with Python, you'll need the patch from python.org/sf/905863 From stewart at midtoad.homelinux.org Wed Mar 17 12:20:16 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Wed Mar 17 12:26:04 2004 Subject: [Tkinter-discuss] Re: Tkinter aesthetic In-Reply-To: References: Message-ID: <20040317102016.09ede35f@pc-00065.midtoad.homelinux.org> Hola che! Tkinter is just a set of Python wrappers (if that's the right word) around the Tk GUI toolset that is written in the Tcl language. so, the question needs to be asked of the Tcl/Tk community. Of course, the answer is of interest to the Python community since we use it. I'm guessing that the look of Tk widgets is due to the way it achieves it cross-platform independence. I have a Tkinter app that I move seamlessly from Windows to Linux and back again. To me, anyway, that independence is worth something. If we get a nicer look (and for me, Qt has the nicest look of all the GUI toolkits), but lose that independence, we won't have advanced at all. Of course, if we can get a more modern look and retain that independence, I'm all for it. As for GTK, after at least 5 hours and numerous attempts, I *still* can't get it working under Windows! On Wed, 17 Mar 2004 13:51:28 -0300"Batista, Facundo" spake thusly: > The other day in #python at irc.freenode.net, an user told me that Tkinter > under Linux is *very* ugly (he migrated to GTK+ because of this). > > Is there a plan to beautify it? -- Stewart Midwinter running on Mandrake Linux 9.2 e-mail: Stewart 'at' Midwinter.ca, stewart 'at' midtoad.homelinux.org web: http://www.midwinter.ca, http://midtoad.homelinux.org voice: +1.403.714.4329 PGP key:http://www.keyserver.net Umwelt schuetzen, Rad benuetzen! From claird at lairds.com Wed Mar 17 12:29:56 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 12:30:16 2004 Subject: [Tkinter-discuss] Administrative items Message-ID: 1. Yes, I applied to gmane, so this'll be available as a newsgroup. I have no idea how long the process'll take. 2. What *I* really, really want, is a Wiki for Tkinter. It's a big enough subject to deserve its own; that's my view, at least. I can't face setting up a Wiki myself, just now (personal reasons); any volunteers? I'll gleefully pour in content, once there's a container, and I'm sure others will too. 3. Why are we doing this? A colleague I respect very, very much asked why we have a mailing list, rather than just (?!?) training people to use Subject-line keywords in comp.lang.python, for example. I have abundant reasons, but not so well-formulated that I can express them succinctly (basics: Tkinter social dynamics will fit this mailing list better). 'Any one else know how to say it? How much does the world need another Tkinter book? 'Know what? We *could* do a collaborative one. I wonder if that'd be interesting ... From claird at lairds.com Wed Mar 17 12:31:43 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 12:32:00 2004 Subject: [Tkinter-discuss] Re: Tkinter aesthetic In-Reply-To: <20040317102016.09ede35f@pc-00065.midtoad.homelinux.org> Message-ID: > From tkinter-discuss-bounces@python.org Wed Mar 17 12:26:06 2004 > . > . > . > As for GTK, after at least 5 hours and numerous attempts, I *still* can't get it > working under Windows! > . > . > . Me too--or neither. Whichever. I know there are good people working with GTK+, and achieving wonderful things. It sure isn't a match for me, somehow ... From FBatista at uniFON.com.ar Wed Mar 17 12:35:27 2004 From: FBatista at uniFON.com.ar (Batista, Facundo) Date: Wed Mar 17 12:37:15 2004 Subject: [Tkinter-discuss] Administrative items Message-ID: claird@phaseit.net wrote: #- How much does the world need another Tkinter book? 'Know #- what? We *could* #- do a collaborative one. I wonder if that'd be interesting ... How many books are on-line (so anyone can download it for free)? I think the first question is answered. Yes, we *could* do a collaborative one. And I think that'd very interesting: for us and for Tkinter newbies (by the way, I belong to both of those groups). . Facundo From FBatista at uniFON.com.ar Wed Mar 17 12:39:26 2004 From: FBatista at uniFON.com.ar (Batista, Facundo) Date: Wed Mar 17 12:41:13 2004 Subject: [Tkinter-discuss] Re: Tkinter aesthetic Message-ID: Stewart Midwinter wrote: #- I'm guessing that the look of Tk widgets is due to the way #- it achieves it #- cross-platform independence. I have a Tkinter app that I #- move seamlessly from #- Windows to Linux and back again. To me, anyway, that #- independence is worth #- something. If we get a nicer look (and for me, Qt has the #- nicest look of all #- the GUI toolkits), but lose that independence, we won't have #- advanced at all. Of #- course, if we can get a more modern look and retain that #- independence, I'm all #- for it. My exact position, :) #- As for GTK, after at least 5 hours and numerous attempts, I #- *still* can't get it #- working under Windows! I made it work, but it's a difficult task (did it three times, and always had to get into google to search for answers). And I don't want to get into it when I carry my application to another desk. . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA La informaci?n contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener informaci?n confidencial o propietaria, cuya divulgaci?n es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no est? autorizado a divulgar, copiar, distribuir o retener informaci?n (o parte de ella) contenida en este mensaje. Por favor notif?quenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magn?tico) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telef?nica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electr?nicos pueden ser alterados, motivo por el cual Telef?nica Comunicaciones Personales S.A. no aceptar? ninguna obligaci?n cualquiera sea el resultante de este mensaje. Muchas Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/tkinter-discuss/attachments/20040317/38ca1165/attachment-0001.html From jeffh at ActiveState.com Wed Mar 17 13:23:14 2004 From: jeffh at ActiveState.com (Jeff Hobbs) Date: Wed Mar 17 13:34:31 2004 Subject: [Tkinter-discuss] Tkinter aesthetic In-Reply-To: Message-ID: <011401c40c4c$e989b360$de04a8c0@activestate.ca> Cameron Laird wrote: > > From tkinter-discuss-bounces@python.org Wed Mar 17 11:53:10 2004 > > . > > The other day in #python at irc.freenode.net, an user told me that > > Tkinter under Linux is *very* ugly (he migrated to GTK+ because of > > this). > > > Is there a plan to beautify it? > > . > Yes, no, and yes. > ON THE OTHER HAND, this is a big issue for the Tcl/Tk folks, > and they've already made enormous progress > tcl.projectforum.com/tk/Home > (incidentally, I'm unhappy > with that page; by this weekend, I'll redo it to make it > easier to read). One conclusion: even if Tkinter folk do > nothing except track upcoming Tk releases, visuals under > Linux will improve a bunch over the next year. For those who don't like the default look of Tk, the first thing to do is tighten up the ancient defaults (which haven't changed in much too long). This is very easy to do, and you can try something like the attached code here: http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/2021443 At ActiveState, we use that for all our apps. It's Tcl code, but you can place it on the Tcl side of the bridge easily (or convert it to the requisite python code). That may well be the new defaults for Tk 8.5. However, Tk 8.5 is getting a lot of dev attention right now, and more widgets and themed widgets are both high on the priority list. These include fancy beasts like: http://tktreectrl.sourceforge.net/ and themeable replacements for core widgets as seen here (actually working with Tk 8.4): http://tktable.sourceforge.net/tile/ I'm starting to work more actively on the Tk core in order to improve things across the languages in 8.5. The focus right now is Tcl/Tk and Perl/Tk. Tkinter is also important, it's just that Tkinter's current state is better than Perl/Tk's current state, FWIW. Note that I'm not on this list, so you'll have to cc me with any extra commentary, questions. Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos From kmmcdonald at wisc.edu Wed Mar 17 14:08:23 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Wed Mar 17 14:08:44 2004 Subject: [Tkinter-discuss] Answers to a couple of Cameron's questions Message-ID: <766F6B38-7846-11D8-BFFE-000A956870AC@wisc.edu> 1) Why a mailing list? I find that a mailing list is better if I have a particular focus. Due to the volume of something like comp.lang.python, I may not bother it for days on end, whereas getting the mailing list batched to me every day is very easy. 2) As regards a Tkinter book, I always thought that it would be really cool if Tkinter itself provided help in a consistent manner. For example: import Tkinter print Tkinter.__help__ As long as each "level" contains at least a reference to everything on the next "level", it would be easi(er) for a newbie to drill down to what they want. Also easier to maintain. Obviously, docstrings would be fine too. Ken From jepler at unpythonic.net Wed Mar 17 14:27:47 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 17 14:28:01 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: References: Message-ID: <20040317192747.GN2446@unpythonic.net> On Wed, Mar 17, 2004 at 12:29:56PM -0500, Cameron Laird wrote: > I can't face setting up a Wiki > myself, just now (personal reasons); any volunteers? http://tkinter.unpythonic.net/wiki/ aka http://tkinter.unpy.net/wiki/ .. this is running on DSL with only 128kbps outgoing, so it may feel slow. This is the first time I've installed a wiki for public use, so it's possible I've got something wrong. Let me know if you encounter any problems. Jeff From claird at lairds.com Wed Mar 17 14:44:11 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 14:44:17 2004 Subject: [Tkinter-discuss] Answers to a couple of Cameron's questions In-Reply-To: <766F6B38-7846-11D8-BFFE-000A956870AC@wisc.edu> Message-ID: > From tkinter-discuss-bounces@python.org Wed Mar 17 14:08:52 2004 > . > . > . > 2) As regards a Tkinter book, I always thought that it would be really > cool if Tkinter itself provided help in a consistent manner. For > example: > import Tkinter > print Tkinter.__help__ > As long as each "level" contains at least a reference to everything on > the > next "level", it would be easi(er) for a newbie to drill down > to what they want. Also easier to maintain. Obviously, docstrings > would be fine too. > . > . > . 'Sounds like a project. From all I know, the core Python maintainers are plenty receptive to "patches", especially those which provide documentation, including docstrings. Is Kenneth's idea the right way to go? From claird at lairds.com Wed Mar 17 14:49:26 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 14:49:37 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <20040317192747.GN2446@unpythonic.net> Message-ID: > From jepler@dsndata.com Wed Mar 17 14:27:58 2004 > . > . > . > http://tkinter.unpythonic.net/wiki/ > aka http://tkinter.unpy.net/wiki/ > .. this is running on DSL with only 128kbps outgoing, so it may feel > slow. > This is the first time I've installed a wiki for public use, so it's > possible I've got something wrong. Let me know if you encounter any > problems. > Jeff It's working fine for me. Let me particularly recommend to others. From mfranklin1 at gatwick.westerngeco.slb.com Wed Mar 17 15:50:16 2004 From: mfranklin1 at gatwick.westerngeco.slb.com (Martin Franklin) Date: Wed Mar 17 15:51:32 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: References: Message-ID: <4058BA08.504@gatwick.westerngeco.slb.com> Cameron Laird wrote: >>From jepler@dsndata.com Wed Mar 17 14:27:58 2004 >> . >> . >> . >>http://tkinter.unpythonic.net/wiki/ >>aka http://tkinter.unpy.net/wiki/ >>.. this is running on DSL with only 128kbps outgoing, so it may feel >>slow. > > >>This is the first time I've installed a wiki for public use, so it's >>possible I've got something wrong. Let me know if you encounter any >>problems. > > >>Jeff > > > It's working fine for me. Let me particularly recommend > > to others. Great start Jeff. What do people want in the Widget list / Widget pages? Example usage? A discussion of all the widget specific options? I guess a python translation of the Tk man pages would be a start? Martin From jepler at unpythonic.net Wed Mar 17 16:09:59 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 17 16:10:05 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <4058BA08.504@gatwick.westerngeco.slb.com> References: <4058BA08.504@gatwick.westerngeco.slb.com> Message-ID: <20040317210959.GQ2446@unpythonic.net> On Wed, Mar 17, 2004 at 08:50:16PM +0000, Martin Franklin wrote: > What do people want in the Widget list / Widget pages? Example usage? A > discussion of all the widget specific options? I guess a python > translation of the Tk man pages would be a start? I don't know. I have found that often the answer to a Tkinter question is buried in a Tk manpage somewhere, but Python users (especially Python users on Windows?) often don't realize those manpages are even relevant because they use Tcl syntax everywhere. Which makes me think we need a TranslatingTcl page... Jeff From FBatista at uniFON.com.ar Wed Mar 17 16:16:22 2004 From: FBatista at uniFON.com.ar (Batista, Facundo) Date: Wed Mar 17 16:18:06 2004 Subject: [Tkinter-discuss] Administrative items Message-ID: On Wed, Mar 17, 2004 at 08:50:16PM +0000, Martin Franklin wrote: #- > What do people want in the Widget list / Widget pages? #- Example usage? A discussion of all the widget specific options? #- I guess a python translation of the Tk man pages would be a start? Me, who's in a pre-newbie state, but firmly decided to use Tkinter as python's GUI, miss very much a comprehensive manual. I know it's a hard task (that's why I'm attempting to participate in a collaborative book), but I think is very important. For example: Note the difference in Python if you don't it's Python Standard Library! . Facundo From claird at lairds.com Wed Mar 17 16:20:59 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 16:21:07 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: Message-ID: > From tkinter-discuss-bounces@python.org Wed Mar 17 16:18:06 2004 > . > . > . > Me, who's in a pre-newbie state, but firmly decided to use Tkinter as > python's GUI, miss very much a comprehensive manual. > . > . > . Facundo, how does fail to meet your need? From FBatista at uniFON.com.ar Wed Mar 17 16:30:40 2004 From: FBatista at uniFON.com.ar (Batista, Facundo) Date: Wed Mar 17 16:32:19 2004 Subject: [Tkinter-discuss] Administrative items Message-ID: claird@phaseit.net wrote: #- > From tkinter-discuss-bounces@python.org Wed Mar 17 16:18:06 2004 #- > . #- > . #- > . #- > Me, who's in a pre-newbie state, but firmly decided to use #- Tkinter as #- > python's GUI, miss very much a comprehensive manual. #- > . #- > . #- > . #- Facundo, how does #- fail to meet your need? Use it a lot. 99.99% of times. But: - Need to fill ALL the widget patterns. Because you look at the syntax and options, but in doubt (and always faster) you look to the widget more common usage. - Need to fill with a lot of catchy details (those that are common sense to an experimented user but a newbie spends two hours looking around), i.e. how to finish a Tkinter app when using IDLE. - Needs to be packed in a better PDF or an HTML that you can print-it-all. - Needs to be updated (1999!) With all said, it's a *very* good book. I appreciate all the sections in each widget, and the organization of the first chapter. Because of that I thought it was a pitty when Fredrik said it was dead. I'll be very happy with a full and updated version of _this_ book (not so happy as to buy it with my devaluated argentinian pesos, but enough happy as to spend personal time in the effort). . Facundo From PeterM at resmed.com.au Wed Mar 17 17:09:15 2004 From: PeterM at resmed.com.au (Peter Milliken) Date: Wed Mar 17 17:09:23 2004 Subject: [Tkinter-discuss] Administrative items Message-ID: <274A369893F5FB4099345F006439D987013877C4@bella.corp.resmed.org> Not meaning to be critical of the Intro :-) It is a great starting point but I'm not sure you should be holding it up as a "comprehensive" manual.... :-) I believe it is not comprehensive enough in some areas and the way it is written it doesn't leave the possibility that there is more information that should/could be searched for. For example, if you look at "Events and Bindings" and compare the attributes available from the Event Object as opposed to the attributes that are mentioned for the Event Object on the Tk man page. There are many more attributes available (see the equivalent Tk page) about an event than are mentioned in the Intro - sometimes these types of details can make a huge difference to an implementation of something i.e. I once wrote an application (in my Tcl/Tk days before I shifted to Python/Tkinter) that was required to time the difference between keystrokes (speech therapist wanted to measure and gather data on the frequency of stuttering in a patient) - I could have used a call to a time module but that all depended on *when* I decided to process the event - presenting all sorts of notty problems for the code, whereas the event object actually contains a time attribute - captured by the event processing system, that tells me quite accurately enough *when* that event occured. So there was no notty problems about "when" the key event was generated, I just used the time attribute of the event. So the Intro is a nice starting point that will probably be used by many without having to go further, but I believe it is far from "comprehensive" - in my view :-) Given that I have read books on GUI programming with Tcl/Tk and read the Grayson book on using Python with Tkinter, I find myself going continually to the Tk pages directly - but this is a "hidden" field for many newbies and your average Python programmer who doesn't have any Tcl/Tk background and therefore doesn't realise the wealth of detail that the Tk elements actually have and can provide. Probably the only real answer is a comprehensive translation of the Tk pages into Pythonese rather than "summaries" such as the Intro - something that I consider quite "dangerous" because of the lack of clues that all has not be faithfully "translated" (IMO - very critical of a noble effort and I apologise if this offends anyone). Peter -----Original Message----- From: Cameron Laird [mailto:claird@lairds.com] Sent: Thursday, March 18, 2004 8:21 AM To: FBatista@uniFON.com.ar; tkinter-discuss@python.org Subject: RE: [Tkinter-discuss] Administrative items > From tkinter-discuss-bounces@python.org Wed Mar 17 16:18:06 2004 > . > . > . > Me, who's in a pre-newbie state, but firmly decided to use Tkinter as > python's GUI, miss very much a comprehensive manual. > . > . > . Facundo, how does fail to meet your need? _______________________________________________ Tkinter-discuss mailing list Tkinter-discuss@python.org http://mail.python.org/mailman/listinfo/tkinter-discuss Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. This communication is confidential and may contain legally privileged information. By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in,the content of the email and of any attachments. If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 9886 5000 Sydney, Australia. From stewart at midtoad.homelinux.org Wed Mar 17 17:30:53 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Wed Mar 17 17:23:14 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <20040317192747.GN2446@unpythonic.net> References: <20040317192747.GN2446@unpythonic.net> Message-ID: <1079562653.4058d19dd4f22@midtoad.homelinux.org> Cool, a wiki already! Thanks, Jeff. Unless the wiki presumes to be the be-all, end-all of Tkinter knowledge (no telling where this effort might get to in time), it would benefit from a Links or Resources page, with pointers to other stuff already published in various places. ... 1 min later: wow, someone already added one! Good stuff. -- Stewart Midwinter Calgary, Alberta stewart 'at' midwinter 'dot' ca Quoting Jeff Epler : > On Wed, Mar 17, 2004 at 12:29:56PM -0500, Cameron Laird wrote: > > I can't face setting up a Wiki > > myself, just now (personal reasons); any volunteers? > > http://tkinter.unpythonic.net/wiki/ > aka http://tkinter.unpy.net/wiki/ > .. this is running on DSL with only 128kbps outgoing, so it may feel > slow. > > This is the first time I've installed a wiki for public use, so it's > possible I've got something wrong. Let me know if you encounter any > problems. > > Jeff > > _______________________________________________ > Tkinter-discuss mailing list > Tkinter-discuss@python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss > From jepler at unpythonic.net Wed Mar 17 20:21:53 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 17 20:22:39 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <4058BA08.504@gatwick.westerngeco.slb.com> References: <4058BA08.504@gatwick.westerngeco.slb.com> Message-ID: <20040318012153.GA12550@unpythonic.net> On Wed, Mar 17, 2004 at 08:50:16PM +0000, Martin Franklin wrote: > What do people want in the Widget list / Widget pages? Example usage? A > discussion of all the widget specific options? I guess a python > translation of the Tk man pages would be a start? Well, one route to go is a translation of the Tk manpage into Python terms. An example of this (done mostly manually) is now at http://tkinter.unpy.net/wiki/Widgets/Button Comments, please. I don't intend to do another unless response is clearly positive... Problems I see: * Options vary according to Tk version. We'd have to decide on a version to document, and what version-dependent differences to note * The process takes time (and I did one of the very simple pages) * Maybe docstrings in the Tkinter module are more appropriate * What about the other things we'd like to say (I think a sample program and maybe even screenshots if moinmoin can do it), how do they fit into the document when the structure is taken from a manpage? * Can wiki pages be renamed later, or is it manual cut&paste followed by renaming incoming links? For instance Widgets/Button vs Widgets/Button/Manual vs WidgetReference/Button, to name three places this page could belong. Jeff From jepler at unpythonic.net Wed Mar 17 20:36:30 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 17 20:37:08 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <20040318012153.GA12550@unpythonic.net> References: <4058BA08.504@gatwick.westerngeco.slb.com> <20040318012153.GA12550@unpythonic.net> Message-ID: <20040318013630.GC12550@unpythonic.net> [Replying to my own post] > On Wed, Mar 17, 2004 at 08:50:16PM +0000, Martin Franklin wrote: > > What do people want in the Widget list / Widget pages? Example usage? A > > discussion of all the widget specific options? I guess a python > > translation of the Tk man pages would be a start? On Wed, Mar 17, 2004 at 07:21:53PM -0600, Jeff Epler wrote: > Well, one route to go is a translation of the Tk manpage into Python > terms. [...] Boy is my face red---most of this information is already in 'pydoc Tkinter.Button'. IMO, it's a waste of effort to reiterate the documentation the user already has. In the case of Button, this would leave the "Description" and "Default Bindings" sections. Jeff From claird at lairds.com Wed Mar 17 20:48:00 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 20:48:08 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <20040318012153.GA12550@unpythonic.net> Message-ID: > From tkinter-discuss-bounces@python.org Wed Mar 17 20:23:08 2004 > . > . > . > Well, one route to go is a translation of the Tk manpage into Python > terms. An example of this (done mostly manually) is now at > http://tkinter.unpy.net/wiki/Widgets/Button > Comments, please. I don't intend to do another unless response is > clearly positive... > Problems I see: > * Options vary according to Tk version. We'd have to decide on a > version to document, and what version-dependent differences to note > * The process takes time (and I did one of the very simple pages) > * Maybe docstrings in the Tkinter module are more appropriate > * What about the other things we'd like to say (I think a sample > program and maybe even screenshots if moinmoin can do it), how do > they fit into the document when the structure is taken from a manpage? > * Can wiki pages be renamed later, or is it manual cut&paste followed > by renaming incoming links? For instance Widgets/Button vs > Widgets/Button/Manual vs WidgetReference/Button, to name three places > this page could belong. > . > . > . 1. I consider this valuable, 2. even though I *bet* it was costly in terms of your time. 3. I have counter questions: how about references on that page to and ? 4. Your questions are good ones. I want to come back to them. From claird at lairds.com Wed Mar 17 20:53:23 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 17 20:53:26 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <20040318013630.GC12550@unpythonic.net> Message-ID: > From tkinter-discuss-bounces@python.org Wed Mar 17 20:37:46 2004 > . > . > . > Boy is my face red---most of this information is already in 'pydoc > Tkinter.Button'. IMO, it's a waste of effort to reiterate the > documentation the user already has. In the case of Button, this would > leave the "Description" and "Default Bindings" sections. > . > . > . Well, me too. Let's eliminate redundancy, but keep the page, and strip it down to choice references and novel elements. From jepler at unpythonic.net Wed Mar 17 21:25:02 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 17 21:25:42 2004 Subject: [Tkinter-discuss] Per-widget wiki pages In-Reply-To: References: <20040318013630.GC12550@unpythonic.net> Message-ID: <20040318022502.GD12550@unpythonic.net> On Wed, Mar 17, 2004 at 08:53:23PM -0500, Cameron Laird wrote: > Well, me too. Let's eliminate redundancy, but keep the page, > and strip it down to choice references and novel elements. OK -- A slimmed-down version now at http://tkinter.unpy.net/wiki/Widgets/Button the original version at http://tkinter.unpy.net/wiki/Widgets/Button?action=recall&date=1079572546 Jeff From kbk at shore.net Thu Mar 18 23:48:13 2004 From: kbk at shore.net (Kurt B. Kaiser) Date: Thu Mar 18 23:48:18 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <274A369893F5FB4099345F006439D987013877C4@bella.corp.resmed.org> (Peter Milliken's message of "Thu, 18 Mar 2004 09:09:15 +1100") References: <274A369893F5FB4099345F006439D987013877C4@bella.corp.resmed.org> Message-ID: <877jxhwigi.fsf@hydra.localdomain> Peter Milliken writes: > Probably the only real answer is a comprehensive translation of the Tk pages > into Pythonese rather than "summaries" such as the Intro - something that I > consider quite "dangerous" because of the lack of clues that all has not be > faithfully "translated" (IMO - very critical of a noble effort and I > apologise if this offends anyone). It seems to me that our time is limited and that we should focus on showing people how to access and understand the Tcl/Tk docs in a Python context, rather that trying to rewrite (and maintain) everything. The problem I had initially was figuring out where to find everything, and the wiki should help with that. It's better to enhance the Tkinter doc strings and use the wiki for meta information, IMHO. Another use would be to post good examples of Tkinter code. Possibly also a few examples which are written in both Tkinter and Tcl so folks can see how they compare. -- KBK From claird at lairds.com Thu Mar 18 23:58:02 2004 From: claird at lairds.com (Cameron Laird) Date: Fri Mar 19 00:03:18 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <877jxhwigi.fsf@hydra.localdomain> Message-ID: > From tkinter-discuss-bounces@python.org Thu Mar 18 23:48:20 2004 > . > . > . > It seems to me that our time is limited and that we should focus on showing > people how to access and understand the Tcl/Tk docs in a Python context, > rather that trying to rewrite (and maintain) everything. > The problem I had initially was figuring out where to find everything, > and the wiki should help with that. > It's better to enhance the Tkinter doc strings and use the wiki for meta > information, IMHO. > Another use would be to post good examples of Tkinter code. Possibly also > a few examples which are written in both Tkinter and Tcl so folks can see > how they compare. > . > . > . You sound good to me. From clnethery at juno.com Fri Mar 19 00:32:29 2004 From: clnethery at juno.com (clnethery@juno.com) Date: Fri Mar 19 00:32:46 2004 Subject: [Tkinter-discuss] Pmw question Message-ID: <20040318.213230.23607.2708957@webmail19.nyc.untd.com> Hi there. I'm a newbie to Python and Tkinter and have encountered a problem I don't know how to overcome. The issue is as follows: I have created a GUI consisting of PMW Notebooks with PMW Notebooks inside them. I am now trying to insert a Pmw Scrolled Frame inside one of the "sub"-Notebooks, with Entryfields within the Scrolled Frame. I receive the error: "ScrolledFrame instance has no attribute 'tk'", which I assume is because ScrolledFrame inherits from Mega-Architype instead of Mega-Widget. Does anyone know of a way to get around this problem? Thanking you in advance, CN From stewart at midtoad.homelinux.org Fri Mar 19 01:03:43 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Fri Mar 19 00:47:31 2004 Subject: [Tkinter-discuss] Administrative items In-Reply-To: <877jxhwigi.fsf@hydra.localdomain> References: <274A369893F5FB4099345F006439D987013877C4@bella.corp.resmed.org> <877jxhwigi.fsf@hydra.localdomain> Message-ID: <1079676223.405a8d3fd0101@midtoad.homelinux.org> Quoting "Kurt B. Kaiser" : > The problem I had initially was figuring out where to find everything, > and the wiki should help with that. ... > Another use would be to post good examples of Tkinter code. Possibly also > a few examples which are written in both Tkinter and Tcl so folks can see > how they compare. Yes, I think this is going in the right direction. We need good examples, to aid learning. My own process of learning may be typical of others': first I read some explanations, then I look at some code. Then I try to get that code to run verbatim (and often it doesn't! - due to some typo, or omitted line, and that is a roadblock to the beginner). If I get through that, I then start thinking about a problem I want to solve, and look for code that solves that same problem. If I can't find that, I look for code that solves some similar problem, and try to adapt it (often unsuccessfully; my hard drive is full of failed attempts at adapting others' code to my needs). Actually writing my own code doesn't occur until a long way down the path of learning. What would have helped me, and would still help me, is a collection of code samples that are trying to solve some problem - and the problem itself is clearly stated. Descriptions of how widgets work in and of themselves isn't as useful as explanations and examples of how they work together with the underlying app to achieve desired results. There are too many books and guides out there that show, for example, a button with a callback that does nothing but 'print "got the callback"' along with a hand-waving statement that "of course, you would put your own methods here". There's precious little out there in easily accessible form that shows how to "put your own methods here". For example, it's nice to see how you can have an image that updates regularly, but it's more useful to show how to fetch data from a server and graph it in real-time. Anyway, that's my perception on a niche that could be usefully filled. cheers Stewart From stewart at midtoad.homelinux.org Fri Mar 19 01:05:53 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Fri Mar 19 00:49:19 2004 Subject: [Tkinter-discuss] Pmw question In-Reply-To: <20040318.213230.23607.2708957@webmail19.nyc.untd.com> References: <20040318.213230.23607.2708957@webmail19.nyc.untd.com> Message-ID: <1079676353.405a8dc1c8bd1@midtoad.homelinux.org> Quoting clnethery@juno.com: > I receive the > error: "ScrolledFrame instance has no attribute 'tk'", which I assume is > because ScrolledFrame inherits from Mega-Architype instead of Mega-Widget. > Does anyone know of a way to get around this problem? CN, how about posting a section of the code that's causing you the problem, so we can see clearly how to help you? Include your import statements, since they may be part of the issue. Stewart From clnethery at juno.com Fri Mar 19 02:23:58 2004 From: clnethery at juno.com (clnethery@juno.com) Date: Fri Mar 19 02:26:25 2004 Subject: [Tkinter-discuss] Pmw Question Message-ID: <20040318.232445.23607.2709525@webmail19.nyc.untd.com> Sorry about that, I forgot to include a code example. Let me warn you first... ..this is ugly, OOP newbie code (my imports probably illustrate that, for starters), but it replicates the problem: ### imports ### import Tkinter from Tkinter import * from Tkconstants import * import idlelib.TreeWidget as tw import Pmw from xml.dom.minidom import parseString from idlelib.TreeWidget import TreeItem, TreeNode ### initialization ### root = Tkinter.Tk() root.title('Agile Integration Tool') Pmw.initialise(root) ### menubar ### mBar=Pmw.MenuBar(root, hull_relief='raised', hull_borderwidth=1) mBar.pack(fill='x') mBar.addmenu('File', 'Close this window or exit') mBar.addcascademenu('File', 'New', 'Set some other preferences', traverseSpec = 'z', tearoff = 1) mBar.addmenuitem('File', 'command', 'Save this application', command='save', label='Save') mBar.addmenuitem('File', 'command', 'Open up SaveAs dialog', command='saveas', label='Save As') mBar.addmenuitem('File', 'separator') mBar.addmenuitem('File', 'command', 'Exit the application', command='exit', label='Exit') Mainframe = Frame(root, width=1015, height=708) Mainframe.pack(fill = 'both', expand = 1, padx = 5, pady = 5) Notebook = Pmw.NoteBook(Mainframe) Notebook.setnaturalsize() Notebook.pack(fill = 'both', expand = 1, padx = 5, pady = 5) Notebook1 = Notebook.add('General Stuff') Notebook1MainFrame = Frame(Notebook1, borderwidth=2, width=975, height=600, relief=GROOVE) Notebook1MainFrame.pack(fill = 'both', expand = 1, padx = 5, pady = 5) Notebook1MainFrame.place(relx=0.01, rely=0.01, anchor=NW) Notebook1SubFrameRight = Frame(Notebook1MainFrame, borderwidth=2, relief=GROOVE, height=580, width=470) Notebook1SubFrameRight.pack(fill = 'both', expand = 1, padx = 5, pady = 5) Notebook1SubFrameRight.place(relx=0.5, rely=0.01, anchor=NW) HashBoxFrame = Frame(Notebook1SubFrameRight, borderwidth=2, width=440, height=280, relief=GROOVE) HashBoxFrame.pack(padx=1, pady=1, fill='both', expand=1) HashBoxFrame.place(relx=0.02, rely=0.36, anchor=NW) sc2 = Pmw.ScrolledFrame(HashBoxFrame) sc2.pack(fill=X, expand=1, padx=2, pady=2) sc2.place(relx=0.025, rely=0.025, anchor=NW) HashBox1 = Pmw.EntryField(sc2, labelpos=W, labelmargin=1, validate = None) HashBox1.pack(fill=X, expand=1, padx=1, pady=1) HashBox2 = Pmw.EntryField(sc2, labelpos=W, labelmargin=1, validate = None) HashBox2.pack(fill=X, expand=1, padx=1, pady=1) HashBox1.place(relx=0.01, rely=0.01, anchor=NW) HashBox2.place(relx=0.5, rely=0.01, anchor=NW) root.mainloop() I've removed most of the excess code, to make the remaining bad code easier to read. If you replace "sc2 = Pmw.ScrolledFrame(HashBoxFrame)" with "sc2 = Frame(HashBoxFrame)" it displays the EntryFields as I would like to display them (except for the fact that they're not in a ScrolledFrame). From stewart at midtoad.homelinux.org Fri Mar 19 02:46:52 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Fri Mar 19 02:30:37 2004 Subject: [Tkinter-discuss] Good source for Tkinter example code Message-ID: <1079682412.405aa56c2ef0b@midtoad.homelinux.org> There's a good source for Tkinter example code, in the context of a 6-part student-oriented tutorial at Bryce Embry's website: http://bembry.org/tech/python/notes/tkinter_1.php If you're not using Idle, don't forget to add root.mainloop() to all his code examples! -- Stewart Midwinter Calgary, Alberta stewart 'at' midwinter 'dot' ca From mfranklin1 at gatwick.westerngeco.slb.com Fri Mar 19 02:45:53 2004 From: mfranklin1 at gatwick.westerngeco.slb.com (Martin Franklin) Date: Fri Mar 19 02:47:02 2004 Subject: [Tkinter-discuss] Pmw Question In-Reply-To: <20040318.232445.23607.2709525@webmail19.nyc.untd.com> References: <20040318.232445.23607.2709525@webmail19.nyc.untd.com> Message-ID: <405AA531.6000207@gatwick.westerngeco.slb.com> clnethery@juno.com wrote: > Sorry about that, I forgot to include a code example. Let me warn you first... ..this is ugly, OOP newbie code (my imports probably illustrate that, for starters), but it replicates the problem: > > > ### imports ### > > import Tkinter > from Tkinter import * > from Tkconstants import * > import idlelib.TreeWidget as tw > import Pmw > > from xml.dom.minidom import parseString > from idlelib.TreeWidget import TreeItem, TreeNode > > ### initialization ### > > root = Tkinter.Tk() > root.title('Agile Integration Tool') > Pmw.initialise(root) > > > ### menubar ### > > mBar=Pmw.MenuBar(root, hull_relief='raised', hull_borderwidth=1) > mBar.pack(fill='x') > > mBar.addmenu('File', 'Close this window or exit') > mBar.addcascademenu('File', 'New', 'Set some other preferences', traverseSpec = 'z', tearoff = 1) > mBar.addmenuitem('File', 'command', 'Save this application', command='save', label='Save') > mBar.addmenuitem('File', 'command', 'Open up SaveAs dialog', command='saveas', label='Save As') > mBar.addmenuitem('File', 'separator') > mBar.addmenuitem('File', 'command', 'Exit the application', command='exit', label='Exit') > > > Mainframe = Frame(root, width=1015, height=708) > Mainframe.pack(fill = 'both', expand = 1, padx = 5, pady = 5) > Notebook = Pmw.NoteBook(Mainframe) > Notebook.setnaturalsize() > Notebook.pack(fill = 'both', expand = 1, padx = 5, pady = 5) > Notebook1 = Notebook.add('General Stuff') > > > Notebook1MainFrame = Frame(Notebook1, borderwidth=2, width=975, height=600, relief=GROOVE) > Notebook1MainFrame.pack(fill = 'both', expand = 1, padx = 5, pady = 5) > Notebook1MainFrame.place(relx=0.01, rely=0.01, anchor=NW) > > Notebook1SubFrameRight = Frame(Notebook1MainFrame, borderwidth=2, relief=GROOVE, height=580, width=470) > Notebook1SubFrameRight.pack(fill = 'both', expand = 1, padx = 5, pady = 5) > Notebook1SubFrameRight.place(relx=0.5, rely=0.01, anchor=NW) > > HashBoxFrame = Frame(Notebook1SubFrameRight, borderwidth=2, width=440, height=280, relief=GROOVE) > HashBoxFrame.pack(padx=1, pady=1, fill='both', expand=1) > HashBoxFrame.place(relx=0.02, rely=0.36, anchor=NW) > > sc2 = Pmw.ScrolledFrame(HashBoxFrame) > sc2.pack(fill=X, expand=1, padx=2, pady=2) > sc2.place(relx=0.025, rely=0.025, anchor=NW) > > HashBox1 = Pmw.EntryField(sc2, labelpos=W, labelmargin=1, validate = None) To put anything into a ScrolledFrame you must use the interior() method (so the scrolled frame can update its scrollbars I guess... So: HashBox1 = Pmw.EntryField(sc2.interior(), labelpos=W, labelmargin=1, validate = None) etc.. HTH Martin From clnethery at juno.com Fri Mar 19 03:45:28 2004 From: clnethery at juno.com (clnethery@juno.com) Date: Fri Mar 19 03:48:22 2004 Subject: [Tkinter-discuss] Another Pmw Question: Cascading OptionMenu Message-ID: <20040319.004620.23607.2709683@webmail19.nyc.untd.com> I have another question--this time regarding the OptionMenu widget. Is anyone aware of an existing cascading OptionMenu widget? I attempted to re-write the OptionMenu widget by renaming it something else and incorporating what seemed like all of the cascading-related code from menubar (seemed like a good idea at the time). I added the widget to the Pmw definition file, added '('hotkeys', 1, INITOPT) to "optiondefs" in the new widget's '__init__' function(really OptionMenu's __init__ function)... Everything worked splendidly until the program failed to run, with an error that still keeps me up nights. I don't recall the specific error, but I'm guessing that I might be trying to reinvent the wheel, so I thought I'd ask before I cause myself any more trouble. Note to self: YOU DON'T KNOW WHAT YOU'RE DOING. From stewart at midtoad.homelinux.org Fri Mar 19 09:58:52 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Fri Mar 19 09:44:09 2004 Subject: [Tkinter-discuss] Re: Another Pmw Question: Cascading OptionMenu In-Reply-To: <20040319.004620.23607.2709683@webmail19.nyc.untd.com> References: <20040319.004620.23607.2709683@webmail19.nyc.untd.com> Message-ID: <1079708332.405b0aac95781@midtoad.homelinux.org> I may have struggled with the very problem you are having. Does this do what you want? http://www.faqts.com/knowledge_base/view.phtml/aid/29011/fid/264 From kmmcdonald at wisc.edu Mon Mar 22 20:04:12 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Mon Mar 22 20:15:50 2004 Subject: [Tkinter-discuss] More thoughts on Tkinter documentation Message-ID: Here are two more ideas for how to proceed with Tkinter documentation. 1) Is it possible to set up some sort of "structured wiki", where a) Some people can set up documentation structure, and others can add to it. b) Anyone can go in and write documentation in a section, and the "owner" of the section can then integrate (or discard) what has been contributed. For me, this would work well. If I needed to know something, go look at the online document. If my answer is there, great. If my answer isn't there, I have to go and figure it out myself-- and having done that, it isn't much more time to go back and type in what I've found. 2) I'm still a big fan of inline documentation. However, I don't really like docstrings because they don't provide enough structure or analytical power, especially for a fairly complex interface like Tkinter. I think it would be rather cool to define a more structured form of inline documentation, eg. a __doct__ special field (combination of doc and dict) field, where, given a function def f(foo, bar): .... The doct object for the function could be something like: __doct__ = dict( args=dict( foo="This argument is never used.", bar="Neither is this one!" ), return="Returns None or an integer", see=["otherfun1", "otherfun2"] examples = [...,...,...] ) and so on. I like this for a number of reasons. It is easy to write tools to check the validity of the documentation (i.e. are all arguments described? Are any arguments described which don't actually exist?). More importantly (at least in the short run), it would be quite easy to write a little script which, given Tkinter documented in this form, could nicely format and present the information in the doct objects at various levels of detail. I could also conceive of writing docts _outside_ of Tkinter (referring to the appropriate methods/funs/etc by name), and then either include them in Tkinter as a separate file, or write a script to do an automatic integration. (There are definite advantages to the separate approach, as long as it is done in a manner which allows tools such as referred to above to work.) As far as I'm concerned, the only thing that's preventing me from contributing documentation right now is that I have no structure to hang it on. I am embarrassed to confess that I have never used CVS in any significant way (my background is scripting/tech writing, not large project programming), and in any case wouldn't want to go into Tkinter to do documentation without a more structured approach than docstrings. Any thoughts on the above? I can't do much about (1) myself, but if I receive any positive feedback about (2), I'll put together a couple of docts for a bit of Tkinter stuff, and post them to see if people think its worth continuing. Cheers, Ken From claird at lairds.com Mon Mar 22 20:48:25 2004 From: claird at lairds.com (Cameron Laird) Date: Mon Mar 22 20:48:31 2004 Subject: [Tkinter-discuss] More thoughts on Tkinter documentation In-Reply-To: Message-ID: > From tkinter-discuss-bounces@python.org Mon Mar 22 20:16:13 2004 > . > . > . > Here are two more ideas for how to proceed with Tkinter documentation. > 1) Is it possible to set up some sort of "structured wiki", where > a) Some people can set up documentation structure, > and others can add to it. > b) Anyone can go in and write documentation in a section, > and the "owner" of the section can then integrate (or discard) > what has been contributed. > For me, this would work well. If I needed to know something, > go look at the online document. If my answer is there, great. > If my answer isn't there, I have to go and figure it out myself-- > and having done that, it isn't much more time to go back and > type in what I've found. > . > . > . > Any thoughts on the above? I can't do much about (1) myself, > but if I receive any positive feedback about (2), I'll put > together a couple of docts for a bit of Tkinter stuff, and post > them to see if people think its worth continuing. > . > . > . I think you can. Just put stuff in the Wiki right now, tonight, as you think best. Do one page. Next time a question arises in clp, you, or another of us, will write another page on your model, and answer the poster with a URL. The snowball accelerates. That's *my* idea of how it can work. From JasonHarper at pobox.com Tue Mar 23 04:05:26 2004 From: JasonHarper at pobox.com (Jason Harper) Date: Tue Mar 23 03:59:26 2004 Subject: [Tkinter-discuss] Python->Tcl lists Message-ID: <405FFD93.C410915@pobox.com> Does Tkinter provide any way of properly converting a Python list to a Tcl list? Specifically, I am trying to insert text into a Text widget with multiple tags, which is supposedly allowed by passing a list of tag names. However, passing a Python list doesn't work - as far as I can tell, the list just gets converted with str() and then split on whitespace! The results (as verified with .tag_names()) is a mishmash of word fragments, including commas, quote marks, and brackets that could have only come from the stringification of the list: no such characters were actually part of the tags in the list. Jason Harper From jepler at unpythonic.net Tue Mar 23 08:14:17 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Tue Mar 23 08:14:55 2004 Subject: [Tkinter-discuss] Python->Tcl lists In-Reply-To: <405FFD93.C410915@pobox.com> References: <405FFD93.C410915@pobox.com> Message-ID: <20040323131416.GA10162@unpythonic.net> Python tuples, including nested tuples, are converted to Tcl lists. Lists are just converted to strings. >>> import Tkinter >>> tk = Tkinter.Tk().tk >>> tk.call("list", [1, "a b", 3, "{"]) # A list is just converted "\\[1,\\ 'a\\ b',\\ 3,\\ '\\{'\\]" # as by str() >>> tk.call("list", (1, "a b", 3, "{")) # A tuple is converted '{1 {a b} 3 \\{}' # to a tcl list >>> tk.call("list", (1, (2, 3, "a b"), "c d")) # Nested example '{1 {2 3 {a b}} {c d}}' >>> tk.call("list", 1, "a b", 3, "{") # Positional args are quoted '1 {a b} 3 \\{' # as needed So where you're trying to do text.insert(0.0, "blah", [other, args, here]) you should try text.insert(0.0, "blah", tuple([other, args, here])) or text.insert(0.0, "blah", *[other, args, here]) or text.insert(0.0, "blah", other, args, here) I just did the following and got "what I expected": >>> import Tkinter >>> t = Tkinter.Text() >>> t.tag_configure("red", background="red") >>> t.tag_configure("blue", background="blue") >>> t.pack() >>> t.insert(0.0, "blah", "red", " ", "", "bleep", "blue") Jeff From kmmcdonald at wisc.edu Tue Mar 23 14:38:57 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Tue Mar 23 14:39:02 2004 Subject: [Tkinter-discuss] (no subject) Message-ID: From previous message: --------------------------------------------- So where you're trying to do text.insert(0.0, "blah", [other, args, here]) you should try text.insert(0.0, "blah", tuple([other, args, here])) or text.insert(0.0, "blah", *[other, args, here]) or text.insert(0.0, "blah", other, args, here) ----------------------------------------------- And to be a little pickier, that should probably be something like: text.insert("1.0", ...) as Text indexes of the n.n form are (a) still strings, and (b) count lines from 1, not from 0. "0.0" will probably work, but if it does, it will refer to the same location as "1.0" However, I'm surprised from the above that text.insert(0.0, "blah", tuple([other, args, here])) would work. Why wouldn't that have the same problem as text.insert(0.0, "blah", [other, args, here]) Thanks, Ken McDonald From claird at lairds.com Tue Mar 23 14:46:05 2004 From: claird at lairds.com (Cameron Laird) Date: Tue Mar 23 14:46:10 2004 Subject: [Tkinter-discuss] Gmane picked us up. Message-ID: The TkinterDiscuss Wiki page has a pertinent hyperlink. From kmmcdonald at wisc.edu Tue Mar 23 14:54:02 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Tue Mar 23 14:56:21 2004 Subject: [Tkinter-discuss] Tools for summarizing a module? Message-ID: Before I start any documentation effort on Tkinter, I'd like to get a good idea of what's in there right now. Is there a good tool that will go through a module, and print out, in summary form, its functions, classes, methods, etc., with docstrings if present? If not, I'll write my own, but why waste effort if this has already been done? Thanks, Ken From stewart at midtoad.homelinux.org Tue Mar 23 16:16:14 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Tue Mar 23 15:58:58 2004 Subject: [Tkinter-discuss] Re: Tools for summarizing a module? In-Reply-To: References: Message-ID: <1080076574.4060a91e6986a@midtoad.homelinux.org> Ken, not sure if this is exactly what you need, but Pydoc is a very simple tool to use. It will generate a series of HTML pages, one for each Python script in your folder tree. All you need to do is place your quoted doc strings as shown in the attached example file. then, to view the documentation, you run pydoc in viewer mode and it launches a browser to show the pages. cheers -- Stewart Midwinter Calgary, Alberta stewart 'at' midwinter 'dot' ca Quoting Kenneth McDonald : > Before I start any documentation effort on Tkinter, I'd like to get > a good idea of what's in there right now. Is there a good tool > that will go through a module, and print out, in summary form, > its functions, classes, methods, etc., with docstrings if present? > If not, I'll write my own, but why waste effort if this has already > been done? -------------- next part -------------- #!/usr/bin/env python # -*- coding: Latin-1 -*- # =============================================================================c+ # company name and address # Calgary, Alberta # Canada T2P 2V7 # Voice: # Web: #email: # # Copyright (C) company name All Rights Reserved. # # This software is subject to copyright protection under the laws of Canada and other countries. # This software is the confidential and proprietary information of # ... # =============================================================================c- '''The module configfilereader creates the class ConfigFileReconstructor, and provides methods for reading, converting and writing out the files associated with the DDE interface. This module is called by the following modules: ddetransformer ''' '''Pychecker reports the following unresolved warnings: cfr\configfilereconstructor_new.py:127: Statement appears to have no effect ''' '''Pychecher reports that the following modules are not used: import errno, sys, os, traceback, exceptions ''' import string import cfr import uti.csvreader class ConfigFileReconstructor: '''The class ConfigFileReconstructor has methods for reading, converting and writing out the files associated with the DDE interface''' def __init__(self, writeUSRFile = 1, ConfigFile='dde_out.usr'): '''Set the names of the dde input and output files, and the lwserver.usr file; add some items to the configuration dictionary.''' self.__writeUSRFile = writeUSRFile self.__Config = ConfigFile self.__InputAliasDictionary = {} self.__OutputAliasDictionary = {} self.__LWSDictionary = {} self.__ConfigAliasInputAddDictionary = {} self.__ConfigAliasInputDeleteDictionary = {} self.__ConfigAliasOutputAddDictionary = {} self.__ConfigAliasOutputDeleteDictionary = {} self.__ConfigServerAddDictionary = {} self.__ConfigServerDeleteDictionary = {} self.__ConfigServerAddDictionary['AUXTrigger E I 1 -1'] = 'AUXTrigger E I 1 -1\n' # snip code return def readConfigFiles(self): '''Read the dde_out.usr file, determine action to take based on which of (AE,DE, AO,DO, AI,DI) was specified, then parse the lines. Also, read the dde_out.csv created by PCG and parse it. ''' self._Ddeoutf = uti.CSVReader(self.__Ddeout,'r') self._Ddeinf = uti.CSVReader(self.__Ddein,'r') self._Lwserverf = uti.CSVReader(self.__Lwserver,'r') self._Configf = uti.CSVReader(self.__Config,'r') # Read in dde/database modification file # snip code return def convert(self): '''Convert lines based on type of command (AE,DE, AO,DO, AI,DI) ''' # Delete points first so there is no confusion keys = self.__ConfigAliasInputDeleteDictionary.keys() print 'Process/Delete Input Alias Dictionary' for key in keys: self.__InputAliasDictionary[key] = None # snip code return def writeConfigFiles(self): '''write out dde_out.csv, dde_in.csv, lwserver.usr ''' self._Ddeoutf = uti.CSVReader(self.__Ddeout,'w') lines = [] # write out dde_out.csv keys = self.__InputAliasDictionary.keys() print 'Write',self.__Ddeout for key in keys: if (self.__InputAliasDictionary[key] != None): lines.append(self.__InputAliasDictionary[key]) self._Ddeoutf.putlines(lines) self._Ddeoutf.close() # snip code return cfr.ConfigFileReconstructor = ConfigFileReconstructor From kmmcdonald at wisc.edu Wed Mar 24 18:40:25 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Wed Mar 24 19:46:20 2004 Subject: [Tkinter-discuss] Inserting a unicode zero-width nonbreaking space into a Text widget, from Tkinter, on a Mac Message-ID: As the subject says, I am attempting to insert a particular unicode character (\ufeff) into a Text widget, from Python. This is not quite working correctly, and I'm not sure if the problem is between Python and Tcl, or is a problem of OS X not properly knowing the character. This character is supposed to be a 0-width space, and using Python's unicodedata.name function confirms that feff is in fact the proper unicode sequence. The character is construction using a one-character python string: zws = u"\ufeff" And then passed to Text's insert command. Unfortunately, what shows up on screen is a complex (perhaps Chinese) asian ideograph. "Python in a Nutshell" indicates that all communication between Tkinter and Tk is in unicode, so I had hoped this would transfer correctly. Not sure if I need to do some conversion or not...could there be a conflict between a straight Unicode (16-bit) representation and a UTF-8 representation? Or do I need to do an OS setting to make sure the OS and the internal representation are on the same wavelength? Thanks, Ken From stewart at midtoad.homelinux.org Wed Mar 24 20:11:19 2004 From: stewart at midtoad.homelinux.org (Stewart Midwinter) Date: Wed Mar 24 19:57:42 2004 Subject: [Tkinter-discuss] Re: Inserting a unicode zero-width nonbreaking space into a Text widget In-Reply-To: References: Message-ID: <1080177079.406231b76bf71@midtoad.homelinux.org> A zero-width space? Is that an oxymoron like "military intelligence"? I'm curious, what would be the usual application for such a beast? -- Stewart Midwinter Calgary, Alberta stewart 'at' midwinter 'dot' ca Quoting Kenneth McDonald : > This character is supposed to be a 0-width space, ... From jepler at unpythonic.net Wed Mar 24 22:54:37 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Wed Mar 24 22:54:48 2004 Subject: [Tkinter-discuss] Inserting a unicode zero-width nonbreaking space into a Text widget, from Tkinter, on a Mac In-Reply-To: References: Message-ID: <20040325035437.GD16886@unpythonic.net> In *theory*, # t = Tkinter.Text() t.insert(Tkinter.END, u"a\ufeffb") should work just fine. However, I doubt Tk's text engine has enough advanced text layout to respond appropriately to a zero-width nonbreaking space. (heck, I just learned my mozilla doesn't properly render \u200b, a breaking zero-width space) Anyway, Tk has some complicated machinery to look through a number of operating system fonts in various encodings to find a font where the encoding of the character maps onto an existing glyph. When this fails, it shows a placeholder (empty rectangle---what I got in my test, on a Linux system) or an \xXXXX escape code. If it shows an incorrect character, I'd be tempted to blame either a font with a character that u"\ufeff" (erroneously) encodes to, or a bad Tcl encoding that (erroneously) encodes u'\ufeff' to the wrong thing. It doesn't make things easier that Tcl has its own encoding machinery and list of fonts to try. Jeff From Benjamin.Riefenstahl at epost.de Thu Mar 25 06:34:56 2004 From: Benjamin.Riefenstahl at epost.de (Benjamin Riefenstahl) Date: Thu Mar 25 06:55:57 2004 Subject: [Tkinter-discuss] Re: [MACTCL] Inserting a unicode zero-width nonbreaking space into a Text widget, from Tkinter, on a Mac In-Reply-To: (Kenneth McDonald's message of "Wed, 24 Mar 2004 17:40:25 -0600") References: Message-ID: Hi Kenneth, Kenneth McDonald writes: > And then passed to Text's insert command. Unfortunately, what shows > up on screen is a complex (perhaps Chinese) asian ideograph. Current Mac OS X text rendering implementation is based on QuickDraw, which is non-Unicode and very limited for stuff outside of your current locale. The effect you observe is common with that implementation. If you can recompile, try the ATSU patch from , that should work for you. One of its biggest issues at the moment is speed. I am actively working on that. benny From jepler at unpythonic.net Thu Mar 25 07:59:38 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Thu Mar 25 07:59:48 2004 Subject: [Tkinter-discuss] Re: [MACTCL] Inserting a unicode zero-width nonbreaking space into a Text widget, from Tkinter, on a Mac In-Reply-To: References: Message-ID: <20040325125937.GA20786@unpythonic.net> [I removed Cc: tcl-mac@lists.sourceforge.net because I got a letter about moderator approval the last time I sent a message. Apologies to everyone who won't see this message] Thanks for the info, Benjamin. I've just created a page on the Wiki about unicode, and included a reference to this post. If you'd like to add more information about the situation on OS X, please drop by. http://tkinter.unpy.net/wiki/UnicodeSupport Jeff From clnethery at juno.com Thu Mar 25 16:51:24 2004 From: clnethery at juno.com (clnethery@juno.com) Date: Thu Mar 25 16:53:49 2004 Subject: [Tkinter-discuss] How do you get your application to open up with a specific, static siz e? Message-ID: <20040325.135216.11628.29894@webmail24.nyc.untd.com> I am developing an application that I want to open up at a specific size. For some reason, I cannot get the application to open up full-size. When I run it, it is minimized and all scrunched up. Specifically, I am wondering why the following line, "Mainframe = Tkinter.Frame(root, width=1015, height=705)" doesn't automatically open the application fullsize. The following code illustrates what I am referring to: import sys import Tkinter import Pmw root = Tkinter.Tk() root.title('Tool') Pmw.initialise(root) Mainframe = Tkinter.Frame(root, width=1015, height=705) ### menubar ### class AtsMenuBar: menuDict = { } def __init__(self): menuBar=Pmw.MenuBar(Mainframe, hull_relief='raised', hull_borderwidth=1) menuBar.pack(fill='x') menuBar.addmenu('File', 'Close this window or exit') menuBar.addcascademenu('File', 'New', 'Set some other preferences', traverseSpec = 'z', tearoff = 1) menuBar.addmenuitem('File', 'command', 'Save this application', command='save', label='Save') menuBar.addmenuitem('File', 'command', 'Open up SaveAs dialog', command='saveas', label='Save As') menuBar.addmenuitem('File', 'separator') menuBar.addmenuitem('File', 'command', 'Exit the application', command='exit', label='Exit') menuBar.addmenu('Edit', 'Undo, Cut, Copy, Paste, Select All or Delete') menuBar.addmenuitem('Edit', 'command', 'Undo last action', command='undo', label='Undo') menuBar.addmenuitem('Edit', 'command', 'Cut the current selection', command='cut', label='Cut') menuBar.addmenuitem('Edit', 'command', 'Copy the current selection', command='copy', label='Copy') menuBar.addmenuitem('Edit', 'command', 'Paste the current selection', command='paste', label='Paste') menuBar.addmenuitem('Edit', 'command', 'Select All', command='selectAll', label='Select All') menuBar.addmenuitem('Edit', 'command', 'Delete', command='delete', label='Delete') menuBar.addmenu('Help', 'Help Topics', 'About') menuBar.addmenuitem('Help', 'command', 'Show help topics', command='helptopics', label='Help topics') menuBar.addmenuitem('Help', 'command', 'Show About window', command='AboutUs', label='About Us') menuBar.addcascademenu('New', 'Thing', 'Set some other preferences', traverseSpec = 'z', tearoff = 1) menuBar.addmenuitem('New', 'command', 'Thing2', command = 'Thing2', label = 'Thing2') menuBar.addmenuitem('New', 'command', 'Thing3', command = 'Thing3', label = 'Thing3') menuBar.addmenuitem('Thing', 'command', 'Stuff1', command = 'Stuff1', label = 'Stuff1') menuBar.addmenuitem('Thing', 'command', 'Stuff2', command = 'Stuff2', label = 'Stuff2') menuBar.addmenuitem('Thing', 'command', 'Stuff3', command = 'Stuff3', label = 'Stuff3') menuBar.addmenuitem('Thing', 'command', 'Stuff4', command = 'Stuff4', label = 'Stuff4') menuBar.addmenuitem('Thing', 'command', 'Stuff5', command = 'Stuff5', label = 'Stuff5') menu = AtsMenuBar() Mainframe.pack(fill = 'both', expand = 1, padx = 5, pady = 5) if __name__ == '__main__': try: root.mainloop() except: sys.exit('\nUnexpected exception. Terminating application.') From klappnase at web.de Thu Mar 25 17:42:49 2004 From: klappnase at web.de (Michael Lange) Date: Thu Mar 25 17:52:48 2004 Subject: [Tkinter-discuss] How do you get your application to open up with a specific, static siz e? In-Reply-To: <20040325.135216.11628.29894@webmail24.nyc.untd.com> References: <20040325.135216.11628.29894@webmail24.nyc.untd.com> Message-ID: <20040325234249.33989e82.klappnase@web.de> On Thu, 25 Mar 2004 21:51:24 GMT clnethery@juno.com wrote: > > I am developing an application that I want to open up at a specific size. For some reason, I cannot get the application to open up full-size. When I run it, it is minimized and all scrunched up. Specifically, I am wondering why the following line, "Mainframe = Tkinter.Frame(root, width=1015, height=705)" doesn't automatically open the application fullsize. > The reason is that your Mainframe widget doesn't contain anything except the MenuBar and the default behavior of a Frame is to only take the size on the screen that is actually required by the widgets it contains. If you want to take your Frame the size you defined anyway, you will have to use: Mainframe.pack(fill = 'both', expand = 1, padx = 5, pady = 5) Mainframe.pack_propagate(0) to override this default behavior. However, if you want to open your app in full-size I would prefer the Tk.geometry() method: root.geometry('1015x705+0+0') You can even check out the screenwidth and -height to make this independent from the actual screen resolution settings: >>> r=Tk() >>> w, h = r.maxsize() >>> print w 1009 >>> print h 738 >>> I hope this helps Michael From jepler at unpythonic.net Fri Mar 26 09:35:58 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Fri Mar 26 09:36:02 2004 Subject: [Tkinter-discuss] How do you get your application to open up with a specific, static siz e? In-Reply-To: <20040325.135216.11628.29894@webmail24.nyc.untd.com> References: <20040325.135216.11628.29894@webmail24.nyc.untd.com> Message-ID: <20040326143558.GH16608@unpythonic.net> Michael Lange's advice to use pack_propagate(0) is good. You might also want to look at .wm_minsize() and .wm_maxsize(), which can set the minimum and maximum sizes for a toplevel window. Note that if a window's current size is (say) 100x100 and you call wm_minsize(200,200) the size won't change. But if the user starts a resize operation, the window will jump to 200x200. (at least, this is my experience on Linux) On Windows with tk8.3 and newer you can use .wm_state("zoomed") on a toplevel window to start maximized. Jeff From kmmcdonald at wisc.edu Tue Mar 30 04:02:51 2004 From: kmmcdonald at wisc.edu (Kenneth McDonald) Date: Tue Mar 30 04:02:56 2004 Subject: [Tkinter-discuss] Text widget, fonts, on OS X: questions and thoughts Message-ID: <05FA018B-8229-11D8-B9D6-000A956870AC@wisc.edu> Hi all. I am trying to change the font associated with a tag in a Text widget. Since there is no "direct" way (that I can see) to do this in Tkinter, I'm (somewhat circuitously) doing something which should according to my understanding of Tkinter and Tk, eventually result in a call on the Tk side somewhat of the form: tag configure mytag font { -family system -size 10 } (Not too sure about the quoting.) I don't make the call directly (it gets built out of some more abstract structures I've implemented), so it may be slightly different from what I've shown above--but it does execute and it does result in a slightly different font being displayed. Unfortunately, the "other" font is just barely smaller than the "default" fault, and more to the point, none of the font attributes--size, family, weight, slant--have any effect upon it. Tomorrow is going to be devoted to solving this (hopefully not all day), but before I got into it, I wanted to ask: 1) Are there any known problems with using other fonts in the Text widget under OS X? 2) Would anyone care to provide a short (2-4 line) snippet of Python code that they know correctly changes a tag's font? Now, back to a subject that created a brief flurry of activity a bit ago, but has since died down--but not in my mind! That's the subject of Tkinter documentation. I have a plan in mind for starting out, which I'll begin this week, hopefully, and seek feedback from the mailing list as I start coming up with things. However, as I do more work with Tkinter in general, and with the Text widget in particular, I'm also coming to believe that part of the "documentation" problem is in fact a problem of multilingualism--even if Tkinter were beautifully documented right now, it's still too close to the Tk level to be easily learned and used but people who _don't_ want to learn Tk. I'm finding myself wrapping a lot of things (font will be one) in Python classes to (almost completely) hide their Tkness, and to add functionality. Anyone interested in doing more of that sort of thing? Do you think it's a good idea? And, does anyone know the current maintainer of Tkinter, so I can contact them and see if they'd be willing to include further code? Thanks, Ken From JasonHarper at pobox.com Tue Mar 30 04:28:13 2004 From: JasonHarper at pobox.com (Jason Harper) Date: Tue Mar 30 04:22:59 2004 Subject: [Tkinter-discuss] Text widget, fonts, on OS X: questions and thoughts References: <05FA018B-8229-11D8-B9D6-000A956870AC@wisc.edu> Message-ID: <40693DA2.2B0EA237@pobox.com> > I am trying to change the font associated with a tag in a Text > widget. Since there is no "direct" way (that I can see) to do this in > Tkinter, Sure there is... I haven't actually changed a tag's font, but this works for all of the other tag attributes I've tried: mytext.tag_config(mytag, foreground="RED", justify=RIGHT) > tag configure mytag font { -family system -size 10 } I think "system" is a Mac-specific special font identifier that implies a size (and other attributes), not just a family. Try an actual font family name there, and you should have better luck changing the size. > I'm finding > myself wrapping a lot of things (font will be one) in Python > classes to (almost completely) hide their Tkness, There already is a Python wrapper for fonts - import tkFont. Jason Harper From jepler at unpythonic.net Tue Mar 30 08:02:12 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Tue Mar 30 08:02:43 2004 Subject: [Tkinter-discuss] Text widget, fonts, on OS X: questions and thoughts In-Reply-To: <05FA018B-8229-11D8-B9D6-000A956870AC@wisc.edu> References: <05FA018B-8229-11D8-B9D6-000A956870AC@wisc.edu> Message-ID: <20040330130212.GC31278@unpythonic.net> As noted in another post, you should probably be able to use t.tag_configure("mytag", font=font_specifier) where t is your text widget and font_specifier names your font. It may be the syntax you're using to describe the font that is wrong. "-family system -size 10" looks like the value for a "font configure" or "font create" command. Please read the manpage for font(n) down at FONT DESCRIPTION. Syntax 3 is probably the one you want: [3] family ?size? ?style? ?style ...? A properly formed list whose first element is the desired font family and whose optional second element is the desired size. The interpretation of the size attribute follows the same rules described for -size in FONT OPTIONS below. Any additional optional arguments following the size are font styles. Possible values for the style arguments are as follows: normal bold roman italic underline overstrike In this case, you should try t.tag_configure("mytag", font=("system", 12)) I just tried the following in an interactive session, and it seemed to work: >>> import Tkinter >>> t = Tkinter.Text() >>> t.pack() >>> t.insert("end", "xyzzy", "mytag") >>> t.tag_configure("mytag", font=("courier", 36)) If combining a font size with the font name "system" doesn't work, maybe it's because "system" is one of the special macintosh fonts listed at the end under PLATFORM-SPECIFIC ISSUES, so font=("system", 12) is not an example of font naming style 3, but style 2 (system font) with extra junk at the end. I'm not sure what to do in this case, but it probably involves using the tkFont module to find the details of the "system" font, then creating a new font with the same details. >>> t.tk.split(t.tk.call("font", "actual", "fixed")) ('-family', 'fixed', '-size', '12', '-weight', 'normal', '-slant', 'roman', '-underline', '0', '-overstrike', '0') Jeff