Problem with giant font sizes in tkinter
uahmed
gleam.uahmed at gmail.com
Thu Feb 10 12:06:16 EST 2011
Hi ,
I am new one but ur talked make me laugh too :D , although here is relevant
link for you
" if Tk cannot come up with an exact match, it tries to find a similar font.
If that fails, Tk falls back to a platform-specific default font. Tk's idea
of what is "similar enough" probably doesn't correspond to your own view, so
you shouldn't rely too much on this feature."
http://www.pythonware.com/library/tkinter/introduction/x444-fonts.htm
Hope it helps you
On Thu, Feb 10, 2011 at 9:55 PM, <python-list-request at python.org> wrote:
> Send Python-list mailing list submissions to
> python-list at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
> python-list-request at python.org
>
> You can reach the person managing the list at
> python-list-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
>
> Today's Topics:
>
> 1. Yappi error "context not found" (Brian)
> 2. Re: Markdown to reStructuredText (Michele Simionato)
> 3. Shared memory python between two separate shell-launched
> processes (Charles Fox (Sheffield))
> 4. Re: Easy function, please help. (Jason Swails)
> 5. Re: Shared memory python between two separate shell-launched
> processes (Jean-Paul Calderone)
> 6. Re: Problem with giant font sizes in tkinter (Cousin Stanley)
> 7. Re: email.encoders.encode_base64 creates one line only
> (spam at uce.gov)
> 8. Re: OO Python (Dan Stromberg)
> 9. Re: Easy function, please help. (Ethan Furman)
> 10. Re: Problem with giant font sizes in tkinter (rantingrick)
>
>
> ---------- Forwarded message ----------
> From: Brian <dribnairb at gmail.com>
> To: python-list at python.org
> Date: Thu, 10 Feb 2011 05:38:43 -0800 (PST)
> Subject: Yappi error "context not found"
> I'm posting here because I can't find a Yappi specific mailing list.
>
> I've been using the rather brilliant Yappi from
> http://code.google.com/p/yappi/
> It works well for small programs with a few threads. However, when
> trying to run it over large programs with several hundred threads I've
> been getting the error "context not found".
>
> The most basic example I can come up with which illustrates the
> problem is below. Changing the number of threads started from 25 down
> to, say, 10, works fine. Any more than ~25 and the error keeps
> appearing. This is using Python 2.6.5 and Ubuntu Linux 10.04. I don't
> have another box to try this out on at the moment.
>
> I've tested a similar script using thread.start_new_thread() and that
> doesn't seem to have the problem. So is there some issue with Yappi
> and inheriting from threading.Thread?
>
> import yappi
> import time
> import threading
>
> class MyThread(threading.Thread):
> def run(self):
> time.sleep(1)
>
> yappi.start()
>
> for i in range(0,25):
> c = MyThread()
> c.start()
> time.sleep(1)
>
> yappi.print_stats()
> yappi.stop()
>
>
> Running the above gives:
> [*] [yappi-err] context not found.
> [*] [yappi-err] context not found.
> [*] [yappi-err] context not found.
> [*] [yappi-err] context not found.
> ...
>
> Any help appreciated.
>
>
>
> ---------- Forwarded message ----------
> From: Michele Simionato <michele.simionato at gmail.com>
> To: comp.lang.python at googlegroups.com
> Date: Thu, 10 Feb 2011 00:03:19 -0800 (PST)
> Subject: Re: Markdown to reStructuredText
> Looks cool, I will have a look at it, thanks!
>
>
>
> ---------- Forwarded message ----------
> From: "Charles Fox (Sheffield)" <charles.fox at gmail.com>
> To: python-list at python.org
> Date: Thu, 10 Feb 2011 06:30:18 -0800 (PST)
> Subject: Shared memory python between two separate shell-launched processes
> Hi guys,
> I'm working on debugging a large python simulation which begins by
> preloading a huge cache of data. I want to step through code on many
> runs to do the debugging. Problem is that it takes 20 seconds to
> load the cache at each launch. (Cache is a dict in a 200Mb cPickle
> binary file).
>
> So speed up the compile-test cycle I'm thinking about running a
> completely separate process (not a fork, but a processed launched form
> a different terminal) that can load the cache once then dunk it in an
> area of shareed memory. Each time I debug the main program, it can
> start up quickly and read from the shared memory instead of loading
> the cache itself.
>
> But when I look at posix_ipc and POSH it looks like you have to fork
> the second process from the first one, rather than access the shared
> memory though a key ID as in standard C unix shared memory. Am I
> missing something? Are there any other ways to do this?
>
> thanks,
> Charles
>
>
>
> ---------- Forwarded message ----------
> From: Jason Swails <jason.swails at gmail.com>
> To: Benjamin Kaplan <benjamin.kaplan at case.edu>
> Date: Thu, 10 Feb 2011 09:50:18 -0500
> Subject: Re: Easy function, please help.
>
>
> On Thu, Feb 10, 2011 at 3:31 AM, Benjamin Kaplan <benjamin.kaplan at case.edu
> > wrote:
>
>>
>> > On Wed, Feb 9, 2011 at 5:34 PM, MRAB <python at mrabarnett.plus.com>
>> wrote:
>>
>> >>> Or typecast to an int if you want to neglect decimals before
>> converting
>> >>> to a string, etc.
>> >>>
>> >> [snip]
>> >> Python doesn't have typecasting. :-)
>> >
>> > Because these basic types are not mutable? <excuse> Most of my work has
>> to
>> > be in Fortran, so I'm a relative newcomer to Python. When I don't need
>> > Fortran-y performance it's much nicer (obviously to anyone that's used
>> them
>> > both)! Still don't know much deeper than Python's cosmetic surface at
>> this
>> > point. </excuse>
>> >
>>
>> Not exactly. It's because everything in Python is an object. What
>> you're doing isn't type casting. It's just calling an object
>> constructor- no different than any other class in the language.
>>
>
> Ah, makes sense, thanks. Most of what I see/work in is C and Fortran --
> not much OOP there :)
>
> --Jason
>
> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
>
>
> ---------- Forwarded message ----------
> From: Jean-Paul Calderone <calderone.jeanpaul at gmail.com>
> To: python-list at python.org
> Date: Thu, 10 Feb 2011 07:43:54 -0800 (PST)
> Subject: Re: Shared memory python between two separate shell-launched
> processes
> On Feb 10, 9:30 am, "Charles Fox (Sheffield)" <charles.... at gmail.com>
> wrote:
> > Hi guys,
> > I'm working on debugging a large python simulation which begins by
> > preloading a huge cache of data. I want to step through code on many
> > runs to do the debugging. Problem is that it takes 20 seconds to
> > load the cache at each launch. (Cache is a dict in a 200Mb cPickle
> > binary file).
> >
> > So speed up the compile-test cycle I'm thinking about running a
> > completely separate process (not a fork, but a processed launched form
> > a different terminal)
>
> Why _not_ fork? Load up your data, then go into a loop forking and
> loading/
> running the rest of your code in the child. This should be really
> easy to
> implement compared to doing something with shared memory, and solves
> the
> problem you're trying to solve of long startup time just as well. It
> also
> protects you from possible bugs where the data gets corrupted by the
> code
> that operates on it, since there's only one copy shared amongst all
> your
> tests. Is there some other benefit that the shared memory approach
> gives
> you?
>
> Of course, adding unit tests that exercise your code on a smaller data
> set
> might also be a way to speed up development.
>
> Jean-Paul
>
>
>
> ---------- Forwarded message ----------
> From: Cousin Stanley <cousinstanley at gmail.com>
> To: python-list at python.org
> Date: Thu, 10 Feb 2011 15:48:47 +0000 (UTC)
> Subject: Re: Problem with giant font sizes in tkinter
> Steven D'Aprano wrote:
>
> > I have a tkinter application under Python 2.6 which is shows text
> > in a giant font, about twenty(?) times larger than expected.
> >
> > The fonts are set using:
> >
> > titlefont = '-Adobe-Helvetica-Bold-R-Normal-*-180-*'
> > buttonfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*'
> > labelfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*'
> > ....
>
> Although I've been a linux user for several years,
> that type of font spec hurts my head .... :-)
>
> Will the more simplistic type of tuple spec
> not work in your tkinter application ?
>
> canv.create_text(
> 81 , 27 ,
> text = ' NTSC Standard ' ,
> fill = 'white' ,
> font = ( 'Helvetica' , 12 , 'bold' ) )
>
>
> --
> Stanley C. Kitching
> Human Being
> Phoenix, Arizona
>
>
>
>
> ---------- Forwarded message ----------
> From: spam at uce.gov
> To: python-list at python.org
> Date: Thu, 10 Feb 2011 08:51:07 -0700
> Subject: Re: email.encoders.encode_base64 creates one line only
>
> This is with python 3.1.2 (r312:79147). I have not tried with 2.7.
>>
>> When I create an attachment with email.mime.image.MIMEImage, by default it
>> uses email.encoders.encode_base64 for the encoder, but that results in a
>> single line base64 string, instead of the recommended multiple 76-chars
>> lines.
>>
>> This works with most MTA and MUA, but some of them choke on it.
>>
>>
> In case somebody runs into the same issue:
> http://bugs.python.org/issue9298
>
> And I added a work around if you need a solution before this bug is fixed
> at:
> http://bugs.python.org/issue11156#msg128213
>
> --
> Yves.
> http://www.SollerS.ca/
>
> http://blog.zioup.org/
>
>
>
> ---------- Forwarded message ----------
> From: Dan Stromberg <drsalists at gmail.com>
> To: Paul Symonds <Paul.J.Symonds at gmail.com>
> Date: Thu, 10 Feb 2011 08:36:29 -0800
> Subject: Re: OO Python
> On Wed, Feb 9, 2011 at 1:50 PM, Paul Symonds <Paul.J.Symonds at gmail.com>
> wrote:
> > Are there any good resources to learn OO Python from?
>
> Yes, plenty, but it's important for us to know so we can advise you:
> Do you know any other OO languages yet?
>
>
>
> ---------- Forwarded message ----------
> From: Ethan Furman <ethan at stoneleaf.us>
> To: Jason Swails <jason.swails at gmail.com>, python-list at python.org
> Date: Thu, 10 Feb 2011 08:52:38 -0800
> Subject: Re: Easy function, please help.
> Jason Swails wrote:
>
>> On Wed, Feb 9, 2011 at 8:16 PM, Ethan Furman wrote:
>> while n: is plenty readable. n is either something or nothing, and
>> something evaluates to True, nothing to False.
>>
>> Sure it's readable. But then you have to make sure that the loop will
>> eventually take n down to 0.
>>
>
> Sure, but the same holds true with 'while n != 0' -- you have to make sure
> the loop will eventually take n down to 0.
>
> You can always *assume* that the programmer knew what they were doing (not
>> an assumption I'm typically willing to make on code that's not my own).
>>
>
> Hopefully not something you have to deal with unless you're debugging...
>
> How is "while n != 0:" any worse? (or abs(n) < tolerance). It has
>> exactly the same effect without adding any code while at the same time
>> directly communicates the intended conditional. IMO it makes reading the
>> code easier to read barring effective documentation (my experience with
>> people documenting their code is that they don't; at least in my field).
>> "while n != 0" makes my life easier.
>>
>
> In that instance (a bunch of mathematical functions), I can easily see
> using that construct.
>
> The fact that the proposed loop finished with *nothing* was coincidental.
>> What if he had been doing some type of prime factorization or something
>> where each iteration reduced the number until eventually all you were left
>> with was the multiplicative identity? You'd say (correctly) that obviously
>> the same approach won't work, but in some lines of thought it's a logical
>> extension to use the same construct (especially to those that don't fully
>> understand why the original loop exits in the first place). Expanding the
>> conditional a little can only help IMO.
>>
>
> Thank you for making my argument for me -- you have to understand the tool
> you are using to make the best use of it.
>
> def num_digits(n):
>> return len(str(n).replace('-','').replace('.',''))
>>
>> Or typecast to an int if you want to neglect decimals before
>> converting to a string, etc.
>>
>> Or use recursion!
>>
>> >>> def num_digits(n):
>> ... if n == 0:
>> ... return 0
>> ... else:
>> ... return num_digits(n//10) + 1
>> ...
>> >>> num_digits(1)
>> 1
>> >>> num_digits(0)
>> 0
>>
>>
>> 0 is still one digit. ;)
>>
>>
>> Well that is something; yet only nothing evaluates to False. We seem to
>> be at an impasse :).
>>
>
> I fail to see how a faulty algorithm puts us at an impasse. To tweak your
> code:
>
> --> def num_digits(n, _first_pass=True):
> --> if n == 0:
> --> return int(_first_pass)
> --> else:
> --> return num_digits(n//10, _first_pass=False) + 1
>
> correctly handles the special case of zero. To use my style, it would look
> like:
>
> --> def num_digits(n, _first_pass=True):
> --> if n:
> --> return num_digits(n//10, _first_pass=False) + 1
> --> else:
> --> return int(_first_pass)
>
> And, of course, this only works for non-negative integers. (I'll leave the
> discussion of whether zero is non-negative to others. ;) As I said
> earlier, I can see using the 'if n == 0' construct in certain situations,
> and if the non-zero branch were lengthy I would stick with the first version
> here.
>
> ~Ethan~
>
>
>
> ---------- Forwarded message ----------
> From: rantingrick <rantingrick at gmail.com>
> To: python-list at python.org
> Date: Thu, 10 Feb 2011 08:52:19 -0800 (PST)
> Subject: Re: Problem with giant font sizes in tkinter
> On Feb 10, 12:59 am, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
> > I have a tkinter application under Python 2.6 which is shows text in a
> > giant font, about twenty(?) times larger than expected.
> >
> > The fonts are set using:
> >
> > titlefont = '-Adobe-Helvetica-Bold-R-Normal-*-180-*'
> > buttonfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*'
> > labelfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*'
> >
> > On one PC (Fedora), the text is displayed fine. Running xlsfonts gives me
> > this:
> >
> > $ xlsfonts -fn '-Adobe-Helvetica-Bold-R-Normal-*-140-*'
> > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso10646-1
> > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1
> > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso10646-1
> > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1
> >
> > On a second PC (Ubuntu), the text is displayed in HUGE letters and I get
> > this from xlsfonts:
> >
> > $ xlsfonts -fn '-Adobe-Helvetica-Bold-R-Normal-*-140-*'
> > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso10646-1
> > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso10646-1
> > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1
> > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1
> > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso10646-1
> > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso10646-1
> > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1
> > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1
> >
> > I don't know how to diagnose or fix the problem. What should I do to fix
> > this problem?
>
>
> First let me stop laughing... hold on... yea just a minute... a little
> longer please... gawd i am enjoying this... ok i am ready... *pffftt*
> ha ha ha ha ha ha ha!
>
> I thought you hated Tkinter Steven? That is what you told this fine
> group many times anyway. Also on many occasions you have said that you
> have no use for GUI's, period. This is very interesting that know you
> cannot even draw text to preferred size.
>
> Oh, and about your problem. READ THE FREAKING MANUAL!
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110210/5c6cc556/attachment-0001.html>
More information about the Python-list
mailing list