Ann.: Python wrapper for Tktreectrl
I wrote a Tkinter wrapper for the tktreectrl widget (<http://tktreectrl.sourceforge.net>). Tktreectrl is an advanced tool that lets you set up things like sortable multi column listboxes and tree browsers. The python module comes with a reference manual and a (very basic) demo script. The url is <http://www.8ung.at/klappnase/TkinterTreectrl/TkinterTreectrl.html>. Any reports, good or bad, are much appreciated. Regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Ann: Tkinter drag and drop module
I wrote a wrapper for the tkdnd Tk extension (<http://sourceforge.net/projects/tkdnd>), which adds native drag and drop support to Tkinter (windows and unix only). It was the first time for me to try wrapping a Tk extension, and I couldn't find any documentation on this, so I would still consider it experimental; however at least for the most part it seems to work well. The module can be used with both standard Tkinter and Tix, and makes it quite easy to e.g. drop a bunch of files from a file manager onto any Tkinter widget. It comes with a basic reference manual and a small demo app. It can be found at <http://www.8ung.at/klappnase/TkinterDnD/TkinterDnD.html>. Any feedback is much appreciated. Best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
tk.createfilehandler() broken with threaded tcl?
Hello everyone, I am running into troubles with some of my scripts that make use of tk.createfilehandler() to catch the output messages of subprocesses I started with popen2.Popen4() (debian linux, python-2.3.5, tk-8.4.9). Sometimes when those background processes are running it happens that the gui freezes and the processlist shows the subprocess in zombie state. I've been using the same scripts without problems on mandrake (with several versions of python and tk), so I came to think the problem may be the debian build of python / tk. Now I found that on debian (unlike mandrake) tcl/tk is build with --enable-threads, so I thought this *might* be the cause for the problems. I tried and replaced the call to tk.createfilehandler() with a "manual" loop that reads Popen4.fromchild() to catch the output messages and the problems seem to be gone, so it looks like using tk.createfilehandler() with threaded tk is the problem. Does anyone have an idea if this makes sense or am I on the wrong track? Best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
i18n: looking for expertise
Hello all,
I am trying to internationalize my Tkinter program using gettext and
encountered various problems, so it looks like it's not a trivial
task.
After some "research" I made up a few rules for a concept that I hope
lets me avoid further encoding trouble, but I would feel more
confident if some of the experts here would have a look at the
thoughts I made so far and told me if I'm still going wrong somewhere
(BTW, the program is supposed to run on linux only). So here is what I
have so far:
1. use unicode instead of byte strings wherever possible. This can be
a little tricky, because in some situations I cannot know in advance
if a certain string is unicode or byte string; I wrote a helper module
for this which defines convenience methods for fail-safe
decoding/encoding of strings and a Tkinter.UnicodeVar class which I
use to convert user input to unicode on the fly (see the code below).
2. so I will have to call gettext.install() with unicode=1
3. make sure to NEVER mix unicode and byte strings within one
expression
4. in order to maintain code readability it's better to risk excess
decode/encode cycles than having one too few.
5. file operations seem to be delicate; at least I got an error when I
passed a filename that contains special characters as unicode to
os.access(), so I guess that whenever I do file operations
(os.remove(), shutil.copy() ...) the filename should be encoded back
into system encoding before; The filename manipulations by the os.path
methods seem to be simply string manipulations so encoding the
filenames doesn't seem to be necessary.
6. messages that are printed to stdout should be encoded first, too;
the same with strings I use to call external shell commands.
file UnicodeHandler.py ##
# -*- coding: iso-8859-1 -*-
import Tkinter
import sys
import locale
import codecs
def _find_codec(encoding):
# return True if the requested codec is available, else return
False
try:
codecs.lookup(encoding)
return 1
except LookupError:
print 'Warning: codec %s not found' % encoding
return 0
def _sysencoding():
# try to guess the system default encoding
try:
enc = locale.getpreferredencoding().lower()
if _find_codec(enc):
print 'Setting locale to %s' % enc
return enc
except AttributeError:
# our python is too old, try something else
pass
enc = locale.getdefaultlocale()[1].lower()
if _find_codec(enc):
print 'Setting locale to %s' % enc
return enc
# the last try
enc = sys.stdin.encoding.lower()
if _find_codec(enc):
print 'Setting locale to %s' % enc
return enc
# aargh, nothing good found, fall back to latin1 and hope for the
best
print 'Warning: cannot find usable locale, using latin-1'
return 'iso-8859-1'
sysencoding = _sysencoding()
def fsdecode(input, errors='strict'):
'''Fail-safe decodes a string into unicode.'''
if not isinstance(input, unicode):
return unicode(input, sysencoding, errors)
return input
def fsencode(input, errors='strict'):
'''Fail-safe encodes a unicode string into system default
encoding.'''
if isinstance(input, unicode):
return input.encode(sysencoding, errors)
return input
class UnicodeVar(Tkinter.StringVar):
def __init__(self, master=None, errors='strict'):
Tkinter.StringVar.__init__(self, master)
self.errors = errors
self.trace('w', self._str2unicode)
def _str2unicode(self, *args):
old = self.get()
if not isinstance(old, unicode):
new = fsdecode(old, self.errors)
self.set(new)
###
So before I start to mess up all of my code, maybe someone can give me
a hint if I still forgot something I should keep in mind or if I am
completely wrong somewhere.
Thanks in advance
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: looking for expertise
"Neil Hodgson" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Michael: > > > 5. file operations seem to be delicate; at least I got an error when I > > passed a filename that contains special characters as unicode to > > os.access(), so I guess that whenever I do file operations > > (os.remove(), shutil.copy() ...) the filename should be encoded back > > into system encoding before; > >This can lead to failure on Windows when the true Unicode file name can > not be encoded in the current system encoding. > >Neil Like I said, it's only supposed to run on linux; anyway, is it likely that problems will arise when filenames I have to handle have basically three sources: 1. already existing files 2. automatically generated filenames, which result from adding an ascii-only suffix to an existing filename (like xy --> xy_bak2) 3. filenames created by user input ? If yes, how to avoid these? Any hints are appreciated Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for expertise
"Neil Hodgson" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Michael: > > > Like I said, it's only supposed to run on linux; anyway, is it likely > > that problems will arise when filenames I have to handle have > > basically three sources: > > ... > > 3. filenames created by user input > >Have you worked out how you want to handle user input that is not > representable in the encoding? It is easy for users to input any characters > into a Unicode enabled UI either through invoking an input method or by > copying and pasting from another application or character chooser applet. > >Neil As I must admit, no. I just couldn't figure out that someone will really do this. I guess I could add a test like (pseudo code): try: test = fsdecode(input)# convert to unicode test.encode(sysencoding) except: # show a message box with something like "Invalid file name" Please tell me if you find any other possible gotchas. Thanks so far Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: i18n: looking for expertise
"Serge Orlov" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> I've never used tkinter, but I heard good things about it. Are you
> sure it's not you who made it to return byte string sometimes?
Yes, I used a Tkinter.StringVar to keep track of the contents of an
Entry widget; as long as I entered only ascii characters get() returns
a byte string, as soon as a special character is entered it returns
unicode.
Anyway, my UnicodeVar() class seems to be a handy way to avoid
problems here.
>
> > 4. in order to maintain code readability it's better to risk excess
> > decode/encode cycles than having one too few.
>
> I don't think so. Either you need decode/encode or you don't.
I use a bunch of modules that contain helper functions for frequently
repeated tasks. So it sometimes happens for example that I call one of
my module functions to convert user input into unicode and then call
the next module function to convert it back to byte string to start
some file operation; that's what I meant with "excess decode/encode
cycles". However, trying to avoid these ended in totally messing up
the code.
> > 5. file operations seem to be delicate;
>
> You should be ready to handle unicode errors at file operations as
> well as for example ENAMETOOLONG error. Any file system with path
> argument can throw it, I don't think anything changed here with
> introduction of unicode. For example access can return 11 (on
> my linux system) error codes, consider unicode error to be twelveth.
>
> > at least I got an error when I
> > passed a filename that contains special characters as unicode to
> > os.access(), so I guess that whenever I do file operations
> > (os.remove(), shutil.copy() ...) the filename should be encoded back
> > into system encoding before;
>
> I think python 2.3 handles that for you. (I'm not sure about the
> version)
> If you have to support older versions, you have to do it yourself.
I am using python-2.3.4 and get unicode errors:
>>> f = os.path.join(u'/home/pingu/phonoripper', u'\xc3\u20ac')
>>> os.path.isfile(f)
True
>>> os.access(f, os.R_OK)
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in position
24-25: ordinal not in range(128)
>>> f = f.encode('iso-8859-15')
>>> os.access(f, os.R_OK)
True
>>>
Thanks for the feedback
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mysterious "Attribute Errors" when GUI Programming
"Coral Snake" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > -- > Tkinter: > > from Tkinter import * > root = Tk() This creates the application's main window. The Tk() command is not some kind of initialization routine, but actually returns a ready to use toplevel widget. > win = Toplevel(root) This creates a child window with the parent "root"; > win.pack() here you try to put the child window into the main window; this cannot work, because a Tk() or Toplevel() window cannot contain other Toplevel() instances. Toplevel() is used for things like dialogs. If you need a separate container widget inside "root" use Frame() instead. > Label(win, text= "Hello, Python World").pack(side=TOP) > Button(win, text= "Close", command=win.quit).pack(side=RIGHT) > win.mainloop() > - > > AttributeError: Toplevel instance has no attribute 'pack' > > - The correct usage of what you tried looks like this: from Tkinter import * root = Tk() Label(win, text= "Hello, Python World").pack(side=TOP) Button(win, text= "Close", command=win.quit).pack(side=RIGHT) root.mainloop() I hope this helps Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: i18n: looking for expertise
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > That's apparently a bug in os.access, which doesn't support Unicode file > names. As a work around, do > > def access(name, mode, orig=os.access): > try: > return orig(name, mode) > except UnicodeError: > return orig(name.encode(sys.getfilesystemencoding(), mode)) > os.access=access > > Apparently, access is used so rarely that nobody has noticed yet (or > didn't bother to report). os.path.isfile() builds on os.stat(), which > does support Unicode file names. > > Regards, > Martin Ah, thanks! Now another question arises: you use sys.getfilesystemencoding() to encode the file name, which looks like it's the preferred method. However when I tried to find out how this works I got a little confused again (from the library reference): getfilesystemencoding() Return the name of the encoding used to convert Unicode filenames into system file names, or None if the system default encoding is used. The result value depends on the operating system: (...) * On Unix, the encoding is the user's preference according to the result of nl_langinfo(CODESET), or None if the nl_langinfo(CODESET) failed. On my box (mandrake-10.1) sys.getfilesystemencoding() returns 'ISO-8859-15', however : >>> locale.nl_langinfo(locale.CODESET) 'ANSI_X3.4-1968' >>> Anyway, my app currently runs with python-2.2 and I would like to keep it that way if possible, so I wonder which is the preferred replacement for sys.getfilesystemencoding() on versions < 2.3 , or in particular, will the method I use to determine "sysencoding" I described in my original post be safe or are there any traps I missed (it's supposed to run on linux only)? Thanks and best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: i18n: looking for expertise
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL
PROTECTED]>...
> Michael:
>
> on my box, (winXP SP2), sys.getfilesystemencoding() returns 'mbcs'.
Oh, from the reading docs I had thought XP would use unicode:
* On Windows 9x, the encoding is ``mbcs''.
* On Mac OS X, the encoding is ``utf-8''.
* On Unix, the encoding is the user's preference according to the
result of nl_langinfo(CODESET), or None if the nl_langinfo(CODESET)
failed.
* On Windows NT+, file names are Unicode natively, so no conversion is
performed.
Maybe that's for compatibility between different Windows flavors.
>
> If you post your revised solution to this unicode problem, I'd be
> delighted to test it on Windows. I'm working on a Tkinter front-end
> for Vivian deSmedt's rsync.py and would like to address the issue of
> accented characters in folder names.
>
> thanks
> Stewart
> stewart dot midwinter at gmail dot com
I wrote it for use with linux only, and it looks like using the system
encoding as I try to guess it in my UnicodeHandler module (see the
first post) is fine there.
When on windows the filesystemencoding differs from what I get in
UnicodeHandler.sysencoding I guess I would have to define separate
convenience methods for decoding/encoding filenames with sysencoding
replaced with sys.getfilesystemencoding()( I found the need for these
convenience methods when I discovered that some strings I used were
sometimes unicode and sometimes not, and I have a lot of interactions
between several modules which makes it hard to track which I have
sometimes).
Tk seems to be pretty smart on handling unicode, so using unicode for
everything that's displayed on tk widgets should be ok (I hope).
So filling a listbox with the contents of a directory "pathname" looks
like this:
pathname = fsencode(pathname)# make sure it's a byte string, for
python2.2 compatibility
flist = map(fsdecode, os.listdir(pathname))
flist.sort()
for item in flist:
listbox.insert('end', item)
For file operations I have written a separate module which defines
convenience methods like these:
##
def remove_ok(self, filename, verbose=1):
b, u = fsencode(filename), fsdecode(filename)
if not os.path.exists(b):
if verbose:
# popup a dialog box, similar to tkMessageBox
MsgBox.showerror(parent=self.parent, message=_('File not
found:\n"%s"') % u)
return 0
elif os.path.isdir(b):
if verbose:
MsgBox.showerror(parent=self.parent, message=_('Cannot
delete "%s":\nis a directory') % u)
return 0
if not os.access(os.path.dirname(b), os.W_OK):
if verbose:
MsgBox.showerror(parent=self.parent, message=_('Cannot
delete "%s":\npermission denied.') % u)
return 0
return 1
def remove(self, filename, verbose=1):
b, u = fsencode(filename), fsdecode(filename)
if self.remove_ok(filename, verbose=verbose):
try:
os.remove(b)
return 1
except:
if verbose:
MsgBox.showerror(parent=self.parent, message=_('Cannot
delete "%s":\npermission denied.') % u)
return 0
###
It looks like you don't need to do any encoding of filenames however,
if you use python2.3 (at least as long as you don't have to call
os.access() ), but I want my code to run with python2.2 ,too.
I hope this answers your question. Unfortunately I cannot post all of
my code here, because it's quite a lot of files, but the basic concept
is still the same as I wrote in the first post.
Best regards
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: i18n: looking for expertise
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > In the locale API, you have to do > > locale.setlocale(locale.LC_ALL, "") > > to activate the user's preferences. Python does that on startup, > but then restores it to the "C" locale, since that is the specified > locale for the beginning of the (Python) program. > > Try that before invoking nl_langinfo. > > > Anyway, my app currently runs with python-2.2 and I would like to keep > > it that way if possible, so I wonder which is the preferred > > replacement for sys.getfilesystemencoding() on versions < 2.3 , or in > > particular, will the method I use to determine "sysencoding" I > > described in my original post be safe or are there any traps I missed > > (it's supposed to run on linux only)? > > I would put an nl_langinfo call in-between, since this is more reliable > than getdefaultlocale (which tries to process environment variables > themselves and happens to crash if they are not in an expected form). > Thanks!! Actually I came to try my code on another box today which still runs python2.2 and found that my original code crashed because neither sys.getpreferredencoding() nor sys.stdin.encoding exist and locale.getdefaultlocale()[1] returnd 'de' .So I changed my _sysencoding() function to this: def _sysencoding(): # try to guess the system default encoding try: enc = locale.getpreferredencoding().lower() if _find_codec(enc): print 'Setting locale to %s' % enc return enc except AttributeError: # our python is too old, try something else pass locale.setlocale(locale.LC_ALL, "") enc = locale.nl_langinfo(locale.CODESET).lower() if _find_codec(enc): print 'Setting locale to %s' % enc return enc # the last try enc = locale.getdefaultlocale()[1].lower() if _find_codec(enc): print 'Setting locale to %s' % enc return enc # aargh, nothing good found, fall back to latin1 and hope for the best print 'Warning: cannot find usable locale, using latin-1' return 'iso-8859-1' > See idlelib/IOBinding.py for the algorithm that I use in IDLE to > determine the "user's" encoding. I guess I should have done so from the beginning. Thanks again and best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: i18n: looking for expertise
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > klappnase wrote: > > enc = locale.nl_langinfo(locale.CODESET).lower() > > Notice that this may fail on systems which don't provide the > CODESET information. Recent Linux systems (glibc 6) have it, > and so do recent Solaris systems, but if you happen to use > an HPUX9 or some such, you find that locale.CODESET raises > an AttributeError. > > Regards, > Martin Thanks again, Things are really tricky and my hair begins to turn gray ;-) So it seems like I'll have to add another try/except condition (and now it finally looks pretty much like I had directly copied your code from IDLE). Best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter Bitmap Newbie question
Neil Hodgson <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Wim Goffin: > > > But just to make sure I'm on the right track, > > - Is XBM the best way to for bitmaps? The ones I saw so far are all black > > and white. Do they also exist in color? > >XPM is the version of XBM with colour. > > > - Is XBM also the best format for glyphs on the Windows platform? Or would > > 'Images' of a different format be nicer? > >It depends on what you want to do with icons. Do you want users to be > able to change icons? It is less likely Windows users will have tools > for manipulating XPM files. The only feature that you are likely to want > that is not available from XPM is multi-level transparency which is > available from PNG files. > >My generic advice without additional details of your project is that > PNG is the best format for icons displayed by your code. Icons used by > the operating system such as for applications should be in a format > supported by that OS: Windows prefers ICO files. > > > - Does someone know of a nice downloadable collection of standard glyphs > > (Bitmaps for Open file, New file, Save file, ...) with a free license? > > http://sourceforge.net/projects/icon-collection/ > >Neil However, if you want to use Tkinter you should be aware that Tkinter only supports xbm-Bitmaps and gif-Images out of the box. You can use the python imaging library to add support for other image formats but I think that PIL just does an on the fly format conversion into gif for you, so you might experience a quality loss if you use for example png icons, so you are probably better off looking for a collection of gifs. Best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
oss mixer usage
Hi, I am trying to write a mixer program using the ossaudiodev module. I could hardly find any documentation or example code, so I try and ask here. There are two things that seem to work already, however I am not sure if the solutions I found are the way it is supposed to be. First, when on initialization of my MixerController class I query the properties of the mixer device in use, I tried the following: self._mixer = ossaudiodev.openmixer() self.names, self.controls, self.stereocontrols, self.reccontrols = [], [], [], [] clabels = ossaudiodev.control_labels for label in clabels: control = clabels.index(label) if self._mixer.controls() & (1 << control): # channel is available self.names.append(label.strip()) self.controls.append(control) # now see if it's a stereo channel if self._mixer.stereocontrols() & (1 << control): self.stereocontrols.append(control) # finally see if it is an input device if self._mixer.reccontrols() & (1 << control): self.reccontrols.append(control) This works, at least on my box, however the ossaudiodev.control_label attribute is not mentioned in the library reference, so I am not sure if this is the "canonical" way that will always work. Second, when I want to change the currently used recording source, I am not sure if I have to provide different code for sound cards that support multiple active recording source channels and sound cards that support only one active recording source channel; the code I wrote works with my card (which allows multiple channels being active), but I don't have a card that supports only one active recording channel at hand so I cannot test if the same code will work. Finally, if it *is* neccessary to provide different code, how can I find out which type of card is currently in use? Any pointers are much appreciated. Thanks in advance Michael -- http://mail.python.org/mailman/listinfo/python-list
Tix.Grid patch
Hi all, I just wrote a wrapper for the Tix.Grid widget (http://www.8ung.at/klappnase/TixGrid/TixGrid.html); I guess I should have searched before, because now I found this has already been done for Python2.5 . However it looks like my version offers some more functionality (and the ScrolledGrid in Python2.5 seems to be broken) than the one I saw at http://svn.python.org/view/python/trunk/Lib/lib-tk/Tix.py?rev=46691&view=auto , so I thought I could contribute a patch. My apologies if this is a dumb question, but I don't know how to do that. Any hints are appreciated Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Tix.Grid patch
Fredrik Lundh schrieb: > > if you'd spent enough time clicking around on python.org, you might have ended > up on this page: > > http://sourceforge.net/tracker/?group_id=5470&atid=305470 > > (it's not obvious how to get there, so it's probably easiest if you just > click on the > above link ;-) > > Thanks Fredrik, I just uploaded the patch, hope everything is ok. Michael -- http://mail.python.org/mailman/listinfo/python-list
New os.path.exists() behavior - bug or feature?
Hi all,
yesterday I installed Python-2.5 and python-2.4.4 on my windows2k box.
When trying to use os.path.exists() to detect which drives are present
on the system I noticed that
these behave differently:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]
on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> for char in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':
if os.path.exists('%s:\\' % char):
print '%s:\\' % char
A:\
C:\
D:\
E:\
>>>
###
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> for char in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':
if os.path.exists('%s:\\' % char):
print '%s:\\' % char
C:\
>>>
When I insert a floppy into A: os.path.exists('A:\\') will return True
on Python-2.5, too.
Does anyone know, is this inconsistent behavior a bug or a new feature?
I also noticed that the Tix binaries are no longer present in 2.5, does
anyone know if it is
planned to remove them pemanently?
Thanks in advance
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: New os.path.exists() behavior - bug or feature?
Martin v. Löwis schrieb: > > Neither, nor. In both cases, the operating system is asked, and gives > this answer. However, in the Windows API, there is no "exists" function > (nor is there on Unix); instead, exists is implemented by calling > several underlying functions. The precise set of functions used did > change between 2.4 and 2.5. > > It is quite difficult to investigate the precise nature of the change > that leads to this change in observable behavior. If you think this is > a bug, it would be best if you could also investigate a patch. > I don't know if it is a bug; at least it is backwards incompatible, which I think is never a good thing. Unfortunately, I am afraid writing a patch is beyond my expertise :( Regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkdnd--does anyone use it?
Kevin Walzer schrieb: > Does anyone use the Tkdnd module that comes with Tkinter to allow > drag-and-drop of Tkinter widgets in your application? (Not the binary > extension that hooks into Xdnd and OLE-dnd on Windows.) I've looked at > the various documents for Tkdnd, and it looks somewhat complicated, > particulary if you want to use it outside of the canvas widget; I've > also found very few examples of its actual use (as opposed to sample > code snippets). I'm curious if anyone is actually using it in a > production application and, if so, what your experience with it is. > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com I use it in phonoripper (http://klappnase.zexxo.net/phonoripper.index.html) to drag files from a directory tree into a listbox. I found it to be less complicated than it looked at a first glance. If you like you can have a look at the DirTree and TrackTree modules to see how i use it. (I actually use Treectrl widgets instead of a Tkinter.Listbox and a slightly modified Tkdnd module, but the logic is the same). Regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkdnd--does anyone use it?
> I use it in phonoripper > (http://klappnase.zexxo.net/phonoripper.index.html) to drag files from > Oops, wrong link address, should be: http://klappnase.zexxo.net/phonoripper/index.html Apologies Michael -- http://mail.python.org/mailman/listinfo/python-list
Using ioctl
Hello,
I am writing an app that records from the soundcard using ossaudiodev.
In the OSS programmer's guide they recommend when reading data
fragments from the soundcard
to use the fragment size as it is requested by the driver. According to
the programmer's guide
the ioctl call to determine the requested fragment size is:
int frag_size;
if ioctl(audio_fd, SNDCTL_DSP_GETBLKSIZE, &frag_size) == -1)
error();
Unfortunately this procedure is not implemented in the ossaudiodev
module, so I
tried to write it myself.
>From reading the fcntl module's docs, I came to the following solution:
try:
f = array.array('h', [0])
fcntl.ioctl(audio_fd, ossaudiodev.SNDCTL_DSP_GETBLKSIZE, f, 1)
frag_size = f.tolist()[0]
except:
frag_size = -1
if frag_size <= 0:
frag_size = 4096
This *seems* to work, I tried several soundcards and got frag_size
values like 4096, 8192 or 16384 .
However I am not really sure about what I am doing there, so I would
feel more confident
if anyone could explain how ioctl is supposed to be used ( I also felt
that I should use
the try...except block for the call in case it fails, but I don't have
an idea "except *what*").
Any hints are much appreciated.
thanks in advance
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Segfault with tktreectrl on python-2.5 on linux
Hello,
I use the tktreectrl Tk extension (http://tktreectrl.sourceforge.net)
through the python wrapper module
(http://klappnase.zexxo.net/TkinterTreectrl/index.html).
With python-2.5 it seems that each time some text is inserted into the
treectrl widget a segfault occurs (on linux, on windows2000 it seemed
to work).
Some people sent me mail describing the same problem, so I think it is
not a problem with my installation of python-2.5. The treectrl widget
itself works well when running from Tcl or from python2.4, so i suspect
that it is a bug in python-2.5.
Below the output from gdb when running the dirtree demo from the
TkinterTreectrl package:
(gdb) run
Starting program: /usr/local/bin/python2.5
/home/pingu/projekte/TkinterTreectrl/TkinterTreectrl-0.6/demo/dirtree.py
[Thread debugging using libthread_db enabled]
[New Thread -1209842944 (LWP 21831)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209842944 (LWP 21831)]
block_alloc (b=0x1, size=16) at Python/pyarena.c:109
109 if (b->ab_offset + size > b->ab_size) {
(gdb) bt
#0 block_alloc (b=0x1, size=16) at Python/pyarena.c:109
#1 0x080d829e in PyArena_Malloc (arena=0x82b2790, size=16) at
Python/pyarena.c:192
#2 0x081129ca in Ellipsis (arena=0x10) at Python/Python-ast.c:1764
#3 0xb77731ef in DisplayProcText () from
/usr/lib/treectrl2.2/libtreectrl2.2.so
Any ideas?
Regards
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: Segfault with tktreectrl on python-2.5 on linux
Anton Hartl schrieb: > > Solutions: > > a) convince Python developers to prefix ALL new (wrt. 2.5) >global symbols with a prefix like "_PyAST_" or equivalent; >this would be consistent with how it is done anyway, >unfortunately the new AST symbols deviate from this practise >(there are symbols like "Assert", "If", "Then", ...) > > or b) apply an equivalent rule to the global symbols in >tktreectrl that are global by accident, i.e. because >of the way the library is structured and built > Anton, you're cool, actually renaming Ellipsis to Py_Ast_Ellipsis in ast.c and Python-ast.c seems to fix this. What I don't understand, isn't it very likely that such things will happen when names like "Ellipsis" or "Slice" and "Index" (which I also found in Python-ast.c) are being used, or are the treectrl people doing something they should avoid? I think the answer to this might be important when deciding to whom I should send a bug report :) Thanks and best regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Segfault with tktreectrl on python-2.5 on linux
Anton Hartl schrieb: > The bug report should go to both; I actually contacted Jeremy Hylton > as a main contributor of the new AST code two weeks ago but didn't > get any response. > Ok, I submitted bug reports on both the tktreectrl and the python sourceforge pages. Now I'll have a nice cup of tea and see what happens :) Regards Michael -- http://mail.python.org/mailman/listinfo/python-list
