Re: [PyKDE] KMimeType.findByPath return value
On Tuesday 31 December 2002 07:12, Jim Bublitz wrote:
> name() returns a QString, so
>
>print self.mimetype.latin1()
>
> should print the "appication/x-shellscript" and you should be able
> to use the value of self.mimetype.latin1() as a Python string.
Yes, that works but now there's another problem, see below. One of the
problems was, I think, that findByPath() never returns None, even if you
ask for a file that doesn't exist. It seems instead you get some undefined
result. But this is a problem with the KDE API, which never returns 0
(that's what the KDE documentation says).
Anyway, I think I've now built a small test case which crashes. I've
attached it, see the comment marked with "***". Make sure that the
filename in self.url really exists. I get "KCrash: crashing" but the
crash dialog doesn't appear so I don't have a backtrace. Actually it
doesn't always crash, but at least the problem that the returned
name().latin1() contains random characters appears each time.
Regards
Daniel
--
http://www.danielnaber.de
#!/usr/bin/python
import sys
from qt import *
from kdecore import KApplication, KCmdLineArgs, KURL
from kio import KMimeType, KServiceTypeProfile
class MainWindow(QMainWindow):
def __init__(self, ap):
apply(QMainWindow.__init__, (self,))
self.url = "/home/dnaber/DesktopDig/test/test1.html"
self.mimetype = KMimeType.findByPath(self.url).name()
self.mimestr = self.mimetype.latin1()
print "mimestr=%s (%s)" % (self.mimestr, type(self.mimestr))
self.offer = KServiceTypeProfile.preferredService(self.mimestr, "Application")
print "offer=%s" % self.offer
if self.offer:
# *** the following line sometimes makes this script
# crash (KCrash), it also crashes without .latin1(). It
# also prints out "name=ueror", the question marks
# are random characters when I use .utf8() instead:
name = self.offer.name().latin1()
print "name=%s" % name
print "isValid=%s" % self.offer.isValid()
return
def slotQuit():
app.quit()
KCmdLineArgs.init(sys.argv, "testapp", "test", "0.1")
app = KApplication()
main_win = MainWindow(app)
main_win.show()
app.connect(app, SIGNAL("lastWindowClosed()"), slotQuit)
app.exec_loop()
[PyKDE] pyqt/mysqld thread deadlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok. I have a PyQt program using mysql as a database with mysqldb as my database client. I'm spawning qt threads to do all the work before I call a postevent to let my application know I'm done. It turns out, however, that the thread locks in the middle of my run() call and never completes. I'm cross-posting this message as I'm not familiar with Python extension modules and I don't know if PyQt could have caused this, it is a Python bug (or feature) or if there is a problem in the mysqldb module code. Here's my run call: def run(self): """ called after the thread is spawned """ try: # never makes it through the quick_find_customer call self.data = quick_find.quick_find_customer(self.parameters) print "quick find returned:",self.data event = QCustomEvent(self.eventID) event.setData(self.data) QThread.postEvent(self.receiver,event) except Exception, msg: print msg I traced through everything and it seems to be blocking in the mysql code: def _execute(self, query, args): # makes it into the function but ... from types import ListType, TupleType from sys import exc_info # it never makes it this far try: if args is None: r = self._query(query) Once it locks, I get the following backtrace (using a full debug build of Python/PyQt/etc.): #0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 #1 0x40033858 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x400300eb in pthread_cond_wait () from /lib/libpthread.so.0 #3 0x080b5c0e in PyThread_acquire_lock (lock=0x813d418, waitflag=1) at Python/thread_pthread.h:374 #4 0x080a5874 in lock_import () at Python/import.c:166 #5 0x080a81b2 in PyImport_ImportModuleEx (name=0x8182fc4 "types", globals=0x87f56a4, locals=0x8114484, fromlist=0x87f83f4) at Python/import.c:1657 #6 0x080f617b in builtin___import__ (self=0x0, args=0x813ab0c) at Python/bltinmodule.c:40 #7 0x080f3ec6 in PyCFunction_Call (func=0x81379f0, arg=0x813ab0c, kw=0x0) at Objects/methodobject.c:79 #8 0x080cdd9b in PyObject_Call (func=0x81379f0, arg=0x813ab0c, kw=0x0) at Objects/abstract.c:1688 #9 0x0808ea7b in PyEval_CallObjectWithKeywords (func=0x81379f0, arg=0x813ab0c, kw=0x0) at Python/ceval.c:3058 #10 0x0808a3f8 in eval_frame (f=0x852f99c) at Python/ceval.c:1843 #32 0x0808d204 in PyEval_EvalCodeEx (co=0x870c6b0, globals=0x871a6cc, locals=0x0, args=0x81e2d78, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #33 0x080e30df in function_call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at Objects/funcobject.c:374 #34 0x080cdd9b in PyObject_Call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at Objects/abstract.c:1688 #35 0x080d6f80 in instancemethod_call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at Objects/classobject.c:2292 #36 0x080cdd9b in PyObject_Call (func=0x8582af4, arg=0x81e2d64, kw=0x0) at Objects/abstract.c:1688 #37 0x0808ea7b in PyEval_CallObjectWithKeywords (func=0x8582af4, arg=0x81e2d64, kw=0x0) at Python/ceval.c:3058 #38 0x40023ecb in sipEvalMethod (pm=0x8734788, args=0x81e2d64) at siplib.c:2898 #39 0x414a85a4 in sipQThread::sipVH_run(sipMethodCache const*, _sipThisType*) () from /usr/local/lib/python2.2/site-packages/libqtcmodule.so #40 0x414a8553 in sipQThread::run() () from /usr/local/lib/python2.2/site-packages/libqtcmodule.so #41 0x40517726 in QThreadPrivate::start(QThread*) (thread=0x8734778) at kernel/qthread_unix.cpp:79 - ---Type to continue, or q to quit--- #42 0x4051675b in start_thread (_arg=0x87327a0) at kernel/qthread_unix.cpp:98 #43 0x40031160 in pthread_start_thread () from /lib/libpthread.so.0 #44 0x40031262 in pthread_start_thread_event () from /lib/libpthread.so.0 So does anyone have any idea what's wrong or how to fix it? Please email me as well if you aren't posting to the PyQt/Python list (kibab at icehouse dot net). - --Kaleb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+EyxOeAVt8Tl/2kURApe3AJ9Sf5oBy2/+iKN3L5eS5YWsSGwK8ACfQQv8 sUmiu7EUmYRCglp0NkHaM8E= =sxi1 -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 5:58 pm, Kaleb Pederson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ok. I have a PyQt program using mysql as a database with mysqldb as my > database client. I'm spawning qt threads to do all the work before I call a > postevent to let my application know I'm done. > > It turns out, however, that the thread locks in the middle of my run() call > and never completes. I'm cross-posting this message as I'm not familiar > with Python extension modules and I don't know if PyQt could have caused > this, it is a Python bug (or feature) or if there is a problem in the > mysqldb module code. > > Here's my run call: > > def run(self): > """ called after the thread is spawned """ > try: > > # never makes it through the quick_find_customer call > self.data = quick_find.quick_find_customer(self.parameters) > print "quick find returned:",self.data > > event = QCustomEvent(self.eventID) > event.setData(self.data) > > QThread.postEvent(self.receiver,event) > > except Exception, msg: > print msg > > > I traced through everything and it seems to be blocking in the mysql code: > > def _execute(self, query, args): > # makes it into the function but ... > from types import ListType, TupleType > from sys import exc_info > # it never makes it this far > try: > if args is None: > r = self._query(query) > > Once it locks, I get the following backtrace (using a full debug build of > Python/PyQt/etc.): > > #0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 > #1 0x40033858 in __pthread_wait_for_restart_signal () from > /lib/libpthread.so.0 > #2 0x400300eb in pthread_cond_wait () from /lib/libpthread.so.0 > #3 0x080b5c0e in PyThread_acquire_lock (lock=0x813d418, waitflag=1) at > Python/thread_pthread.h:374 > #4 0x080a5874 in lock_import () at Python/import.c:166 > #5 0x080a81b2 in PyImport_ImportModuleEx (name=0x8182fc4 "types", > globals=0x87f56a4, locals=0x8114484, fromlist=0x87f83f4) > at Python/import.c:1657 > #6 0x080f617b in builtin___import__ (self=0x0, args=0x813ab0c) at > Python/bltinmodule.c:40 > #7 0x080f3ec6 in PyCFunction_Call (func=0x81379f0, arg=0x813ab0c, kw=0x0) > at Objects/methodobject.c:79 > #8 0x080cdd9b in PyObject_Call (func=0x81379f0, arg=0x813ab0c, kw=0x0) at > Objects/abstract.c:1688 > #9 0x0808ea7b in PyEval_CallObjectWithKeywords (func=0x81379f0, > arg=0x813ab0c, kw=0x0) at Python/ceval.c:3058 > #10 0x0808a3f8 in eval_frame (f=0x852f99c) at Python/ceval.c:1843 > > > > #32 0x0808d204 in PyEval_EvalCodeEx (co=0x870c6b0, globals=0x871a6cc, > locals=0x0, args=0x81e2d78, argcount=1, kws=0x0, kwcount=0, > defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 > #33 0x080e30df in function_call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at > Objects/funcobject.c:374 > #34 0x080cdd9b in PyObject_Call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at > Objects/abstract.c:1688 > #35 0x080d6f80 in instancemethod_call (func=0x870f34c, arg=0x81e2d64, > kw=0x0) at Objects/classobject.c:2292 > #36 0x080cdd9b in PyObject_Call (func=0x8582af4, arg=0x81e2d64, kw=0x0) at > Objects/abstract.c:1688 > #37 0x0808ea7b in PyEval_CallObjectWithKeywords (func=0x8582af4, > arg=0x81e2d64, kw=0x0) at Python/ceval.c:3058 > #38 0x40023ecb in sipEvalMethod (pm=0x8734788, args=0x81e2d64) at > siplib.c:2898 > #39 0x414a85a4 in sipQThread::sipVH_run(sipMethodCache const*, > _sipThisType*) () > from /usr/local/lib/python2.2/site-packages/libqtcmodule.so > #40 0x414a8553 in sipQThread::run() () from > /usr/local/lib/python2.2/site-packages/libqtcmodule.so > #41 0x40517726 in QThreadPrivate::start(QThread*) (thread=0x8734778) at > kernel/qthread_unix.cpp:79 > - ---Type to continue, or q to quit--- > #42 0x4051675b in start_thread (_arg=0x87327a0) at > kernel/qthread_unix.cpp:98 #43 0x40031160 in pthread_start_thread () from > /lib/libpthread.so.0 #44 0x40031262 in pthread_start_thread_event () from > /lib/libpthread.so.0 > > So does anyone have any idea what's wrong or how to fix it? Please email me > as well if you aren't posting to the PyQt/Python list (kibab at icehouse > dot net). To quote the Python source the lock is "to prevent parallel imports of the same module in different threads to return with a partially loaded module". What other imports (or the same import in other threads) might be happening at the same time? Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 11:40 am, you wrote: > On Wednesday 01 January 2003 5:58 pm, Kaleb Pederson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > It turns out, however, that the thread locks in the middle of my run() > > call and never completes. I'm cross-posting this message as I'm not > > familiar with Python extension modules and I don't know if PyQt could > > have caused this, it is a Python bug (or feature) or if there is a > > problem in the mysqldb module code. > > > > So does anyone have any idea what's wrong or how to fix it? Please email > > me as well if you aren't posting to the PyQt/Python list (kibab at > > icehouse dot net). > > To quote the Python source the lock is "to prevent parallel imports of the > same module in different threads to return with a partially loaded module". > What other imports (or the same import in other threads) might be happening > at the same time? > At this point in my application there is nothing else "NEW" going on. That is, I'm in the middle of the event loop and this occurs in response to a button press. The thread, of course, returns control to my application which then waits for more user input. I can think of no reason anything else would be trying to import ListType, TupleType, or exc_info. Furthermore, this is the first thread I spawn (although the behavior is similar for all subsequent threads) thus, I would hope there would be no other blocked threads. Phil, wouldn't the block cease once the "other" thread had successfully imported the module thereby unblocking my thread? Never through the rest of my application life does that thread unblock. Thanks for the info. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 7:55 pm, Kaleb Pederson wrote: > On Wednesday 01 January 2003 11:40 am, you wrote: > > On Wednesday 01 January 2003 5:58 pm, Kaleb Pederson wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > It turns out, however, that the thread locks in the middle of my run() > > > call and never completes. I'm cross-posting this message as I'm not > > > familiar with Python extension modules and I don't know if PyQt could > > > have caused this, it is a Python bug (or feature) or if there is a > > > problem in the mysqldb module code. > > > > > > So does anyone have any idea what's wrong or how to fix it? Please > > > email me as well if you aren't posting to the PyQt/Python list (kibab > > > at icehouse dot net). > > > > To quote the Python source the lock is "to prevent parallel imports of > > the same module in different threads to return with a partially loaded > > module". What other imports (or the same import in other threads) might > > be happening at the same time? > > At this point in my application there is nothing else "NEW" going on. That > is, I'm in the middle of the event loop and this occurs in response to a > button press. The thread, of course, returns control to my application > which then waits for more user input. I can think of no reason anything > else would be trying to import ListType, TupleType, or exc_info. > Furthermore, this is the first thread I spawn (although the behavior is > similar for all subsequent threads) thus, I would hope there would be no > other blocked threads. It would be any import, not just those specific things. > Phil, wouldn't the block cease once the "other" thread had successfully > imported the module thereby unblocking my thread? Never through the rest > of my application life does that thread unblock. Should do - but something obviously isn't right. If there was no other import going on then the first call to PyThread_acquire_lock() in lock_import() in import.c would succeed. It's not so it's blocking in the second call. You could try instrumenting lock_import(), or replace the mysqldb calls with code that still does the imports but nothing else. Phil Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
Phil Thompson <[EMAIL PROTECTED]> writes: > You could try instrumenting lock_import(), or replace the mysqldb calls with > code that still does the imports but nothing else. Alternatively, you could also ask your debugger for a stack trace for all threads. Regards, Martin ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 12:50 pm, you wrote: > Phil Thompson <[EMAIL PROTECTED]> writes: > > You could try instrumenting lock_import(), or replace the mysqldb calls > > with code that still does the imports but nothing else. > > Alternatively, you could also ask your debugger for a stack trace for > all threads. > > Regards, > Martin Hmm switching through the various threads yields: // although I don't display the entire traceback, this thread never acquires the lock. (gdb) thread 1 [Switching to thread 1 (Thread 16384 (LWP 4220))]#0 0x4024b1be in select () from /lib/libc.so.6 (gdb) bt #0 0x4024b1be in select () from /lib/libc.so.6 #1 0x40b76670 in __JCR_LIST__ () from /usr/qt/3-debug//lib/libqt-mt.so.3 #2 0x4053ed39 in QEventLoop::enterLoop() (this=0x8295368) at kernel/qeventloop.cpp:191 #3 0x4053ec52 in QEventLoop::exec() (this=0x8295368) at kernel/qeventloop.cpp:138 #4 0x40524b41 in QApplication::exec() (this=0x81c83b0) at kernel/qapplication.cpp:2471 #5 0x417eb27b in sipDo_QApplication_exec_loop(_object*, _object*) () from /usr/local/lib/python2.2/site-packages/libqtcmodule.so #6 0x080f3ec6 in PyCFunction_Call (func=0x8801cd8, arg=0x8134124, kw=0x0) at Objects/methodobject.c:79 #7 0x0808ae96 in eval_frame (f=0x814d1ac) at Python/ceval.c:2014 #8 0x0808d204 in PyEval_EvalCodeEx (co=0x81462e8, globals=0x81743dc, locals=0x81743dc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #9 0x080828c0 in PyEval_EvalCode (co=0x81462e8, globals=0x81743dc, locals=0x81743dc) at Python/ceval.c:481 #10 0x080a644a in PyImport_ExecCodeModuleEx (name=0xbfffee80 "gem.src.gui.gui", co=0x81462e8, pathname=0xbfffe540 "/home/kibab/JDC/gem/src/gui/gui.pyc") at Python/import.c:505 #11 0x080a6c12 in load_source_module (name=0xbfffee80 "gem.src.gui.gui", pathname=0xbfffe540 "/home/kibab/JDC/gem/src/gui/gui.pyc", fp=0x8189f38) at Python/import.c:787 #12 0x080a76be in load_module (name=0xbfffee80 "gem.src.gui.gui", fp=0x8189f38, buf=0xbfffe9d0 "/home/kibab/JDC/gem/src/gui/gui.py", type=1) at Python/import.c:1371 #13 0x080a8d60 in import_submodule (mod=0x818a224, subname=0xbfffee8c "gui", fullname=0xbfffee80 "gem.src.gui.gui") at Python/import.c:1910 #14 0x080a8525 in load_next (mod=0x818a224, altmod=0x818a224, p_name=0xb2a0, buf=0xbfffee80 "gem.src.gui.gui", p_buflen=0xbfffee7c) at Python/import.c:1766 #15 0x080a7eee in import_module_ex (name=0x0, globals=0x8145154, locals=0x8145154, fromlist=0x8114484) at Python/import.c:1624 #16 0x080a81d2 in PyImport_ImportModuleEx (name=0x818a924 "gem.src.gui.gui", globals=0x8145154, locals=0x8145154, fromlist=0x8114484) at Python/import.c:1658 #17 0x080f617b in builtin___import__ (self=0x0, args=0x813d8e4) at Python/bltinmodule.c:40 // Here we have the second (manager) thread (gdb) thread 2 [Switching to thread 2 (Thread 32769 (LWP 4225))]#0 0x4024988b in poll () from /lib/libc.so.6 (gdb) bt #0 0x4024988b in poll () from /lib/libc.so.6 #1 0x40030d6e in __pthread_manager () from /lib/libpthread.so.0 #2 0x40030fba in __pthread_manager_event () from /lib/libpthread.so.0 // the third thread ... this one calls lock_import() and then apparently gets suspended? (gdb) thread 3 [Switching to thread 3 (Thread 16386 (LWP 4226))]#0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 #1 0x40033858 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x400300eb in pthread_cond_wait () from /lib/libpthread.so.0 #3 0x080b5c0e in PyThread_acquire_lock (lock=0x813d418, waitflag=1) at Python/thread_pthread.h:374 #4 0x080a5874 in lock_import () at Python/import.c:166 #5 0x080a81b2 in PyImport_ImportModuleEx (name=0x8182fc4 "types", globals=0x880079c, locals=0x8114484, fromlist=0x87fcc1c) at Python/import.c:1657 #6 0x080f617b in builtin___import__ (self=0x0, args=0x813ab0c) at Python/bltinmodule.c:40 >From my limited knowledge of the Python interpreter, it looks like the lock only gets acquired once in the third thread. In which case, there would be no reason for it to block. But, the first thread also had some relevant import calls, so I'm not sure. Where do I look now? --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
Kaleb Pederson wrote: (gdb) thread 1 #0 0x4024b1be in select () from /lib/libc.so.6 [...] #16 0x080a81d2 in PyImport_ImportModuleEx (name=0x818a924 "gem.src.gui.gui", globals=0x8145154, locals=0x8145154, fromlist=0x8114484) at Python/import.c:1658 [...] From my limited knowledge of the Python interpreter, it looks like the lock only gets acquired once in the third thread. In which case, there would be no reason for it to block. But, the first thread also had some relevant import calls, so I'm not sure. Where do I look now? See the source of PyImport_ImportModuleEx. It acquires the import lock, so you are holding the import lock while QApplication_exec_loop is running. That means you deadlock. gem.src.gui.gui should not run the mainloop, but expose a function to run the mainloop, which the importer of gui should then invoke. Regards, Martin ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 01:42 pm, Martin v. Löwis wrote: > Kaleb Pederson wrote: > > (gdb) thread 1 > > #0 0x4024b1be in select () from /lib/libc.so.6 > > [...] > > > #16 0x080a81d2 in PyImport_ImportModuleEx (name=0x818a924 > > "gem.src.gui.gui", globals=0x8145154, locals=0x8145154, > > fromlist=0x8114484) at > > Python/import.c:1658 > > [...] > > >>From my limited knowledge of the Python interpreter, it looks like the > >> lock > > > > only gets acquired once in the third thread. In which case, there would > > be no reason for it to block. But, the first thread also had some > > relevant import calls, so I'm not sure. Where do I look now? > > See the source of PyImport_ImportModuleEx. It acquires the import lock, > so you are holding the import lock while QApplication_exec_loop is > running. That means you deadlock. > > gem.src.gui.gui should not run the mainloop, but expose a function to > run the mainloop, which the importer of gui should then invoke. > > Regards, > Martin Ahh. I'm going to change that right now. I'll let you know. Thank you. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 01:42 pm, Martin v. Löwis wrote: > Kaleb Pederson wrote: > > (gdb) thread 1 > > #0 0x4024b1be in select () from /lib/libc.so.6 > > See the source of PyImport_ImportModuleEx. It acquires the import lock, > so you are holding the import lock while QApplication_exec_loop is > running. That means you deadlock. > > gem.src.gui.gui should not run the mainloop, but expose a function to > run the mainloop, which the importer of gui should then invoke. > > Regards, > Martin It works beautifully! Thank you for all the help. It would have taken me a long time to figure that one out by myself. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] KMimeType.findByPath return value
On 01-Jan-03 Daniel Naber wrote: > On Tuesday 31 December 2002 07:12, Jim Bublitz wrote: >> name() returns a QString, so >>print self.mimetype.latin1() >> should print the "appication/x-shellscript" and you should be >> able >> to use the value of self.mimetype.latin1() as a Python string. > Yes, that works but now there's another problem, see below. One > of the problems was, I think, that findByPath() never returns > None, even if you ask for a file that doesn't exist. It seems > instead you get some undefined result. But this is a problem > with the KDE API, which never returns 0 (that's what the KDE > documentation says). > Anyway, I think I've now built a small test case which crashes. > I've attached it, see the comment marked with "***". Make sure > that the filename in self.url really exists. I get "KCrash: > crashing" but the crash dialog doesn't appear so I don't > have a backtrace. Actually it doesn't always crash, but at > least the problem that the returned name().latin1() contains > random characters appears each time. KServiceTypeProfile.preferredService takes a QString as its first argument, so you should use "mimetype" instead of "mimestr". That took care of the crash for me, but I got an odd value for offer.name(). I was using an older value of PyKDE which didn't use findByPath, so that may have been my problem. Let me know if that fixes your problem. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] QThread issue
Hello! I'm programming LokiPoki (http://lokipoki.sf.net), and i have a question about QThread.. (You can see my code in the CVS repository on that site). When an error occurs in the code executed inside a thread, my GUI just freezes, but no error message is displayed on the console, unless i have the b0rking piece of code between "try:" and "except:".. Why is that, and how can i fix it? :$ Thanks in advance! -- Bart Verwilst Gentoo Linux Developer, Desktop Team Gent, Belgium ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
