Re: [PyKDE] PyQt - getting unexpected async reply in threaded ap

2003-02-23 Thread Nicholas John Murison
On Sun, 2003-02-23 at 17:26, Jim Bublitz wrote:
> On 23-Feb-03 Nicholas John Murison wrote:
> > As far as I can remember, somewhere in the PyQt it says there
> > should be a global qApp variable.  However, my code can't seem
> > to find it, so I've passed on the object through constructor
> > parameters to the threads.
>  
> > This seems to be working, and I hope it is the right way to go
> > about these kind of things.
> 
> You should be able to access qApp if you just do:
> 
>from qt import qApp
> 
> or if you do (not the best form):
> 
>from qt import *

Ok, I really have been acting thick.  I was doing "import qt" and
referencing "qApp", rather than "qt.qApp".

I shall bow my head in shame for a suitable period of time.

Thanks,
-- 
Nicholas John Murison
~
http://www.urgusabic.net


signature.asc
Description: This is a digitally signed message part


[PyKDE] ANNOUNCE: IQtPy for event handling by Python's read-eval-print loop

2003-02-23 Thread Gerard Vermeulen
Hi,

I am using this little toy for a week and I can't miss it anymore:

it allows me to use the standard Python interpreter running in an
xterm/Eterm/konsole to create and control PyQt widgets, and to use
the widgets at the same time as in a standard GUI program.

You can get this little toy (less 100 lines of C++ code including
a lot of comments and whitespace) from
http://gerard.vermeulen.free.fr/index.html#IQtPy

Name: IQtPy
Version: 0.1
Summary: Tool to control PyQt widgets from Python running in a terminal
Home-page: http://gerard.vermeulen.free.fr
Author: Gerard Vermeulen
Author-email: gvermeul at grenoble dot cnrs dot fr
License: LGPL
Description:
IQtPy enables you to create and control PyQt widgets from the
Python interpreter (or IPython) running in a text terminal.

The programming style 'imposed' by PyQt (and other GUI toolkits) is
to create an application instance, some widgets and to enter into
an event loop that locks YOU from the terminal. IQtPy gives you both
worlds: you can type Python statements in the interpreter and interact
with your widgets at the same time.

IQtPy works by hooking a function handling a limited number of events
on the event hook of the readline module. The GNU readline library
closes the event loop by calling the hooked function at a maximum
rate of 10 times per second while reading your keyboard input.

This method can be applied to any GUI toolkit that permits to process
events out of the main event loop and any Python interpreter with a
decent readline module.
;-) Oh Bill, this seems to exclude Python compiled with MSVC ;-)

The following example displays 100 working clocks:

packer:~/IQtPy-0.1$ python
Python 2.2.2 (#1, Nov  2 2002, 15:17:50)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import iqt, aclock
>>> list = []
>>> for i in range(100): list.append(aclock.clock())
...
>>> Ctrl-D
packer:~/IQtPy-0.1$

Platform: Unix

Happy hacking -- Gerard

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde


Re: [PyKDE] PyQt - getting unexpected async reply in threaded ap

2003-02-23 Thread Jim Bublitz
On 23-Feb-03 Nicholas John Murison wrote:
> As far as I can remember, somewhere in the PyQt it says there
> should be a global qApp variable.  However, my code can't seem
> to find it, so I've passed on the object through constructor
> parameters to the threads.
 
> This seems to be working, and I hope it is the right way to go
> about these kind of things.

You should be able to access qApp if you just do:

   from qt import qApp

or if you do (not the best form):

   from qt import *

See for example application.py in the examples3/ subdirectory.

(Just as a side note: current versions of PyKDE don't implement the
equivalent kApp variable because it was causing a compilation
problem; PyKDE does implement the static

KApplication.kApplication()

which can be called from any module and will return the program's
KApplication instance)

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde


Re: [PyKDE] PyQt - getting unexpected async reply in threaded app(newbie)

2003-02-23 Thread Nicholas John Murison
Ah, I think I've solved it now.

Locking the QApplication object would be a good idea!

As far as I can remember, somewhere in the PyQt it says there should be
a global qApp variable.  However, my code can't seem to find it, so I've
passed on the object through constructor parameters to the threads.

This seems to be working, and I hope it is the right way to go about
these kind of things.

Thanks,
Nick Murison

On Sat, 2003-02-22 at 12:40, Phil Thompson wrote:
> On Saturday 22 February 2003 11:53 am, Nicholas John Murison wrote:
> > Hi all,
> >
> > Both a colleague and I have run into the identical problem when using
> > PyQt in a threaded environment.
> >
> > I have a threaded app, which uses QThreads for the threading model.  I
> > am trying to get the child threads to be able to create and display
> > windows as part of the GUI.  To my knowledge, all GUI creation must take
> > place within one thread in PyQt.  Therefore I am trying to do all GUI
> > calls from the main thread.  This isn't working, and I keep getting
> > "unexpected async reply" errors from Xlib.
> >
> > Let me demonstrate my object instance hierarchy:
> >
> > __main__
> >   -> creates a QApplication
> >   -> creates a QObject derivative
> >  -> creates QThread derivatives
> > -> creates SocketServer.TCPServer derivatives
> >-> creates SocketServer.BaseRequestHandler derivatives
> >   -> calls main QObject derivative instance and asks for a
> >  window to be displayed
> >
> > This last step is where it all goes wrong.
> >
> > My classes are split over several files, a few of which need to import
> > qt.  So the qt module is imported several times over, which hopefully is
> > ok.
> >
> > Also, I tried referring to the global qApp object, both in my
> > BaseRequestHandler derivative class, and in the main QObject derivative
> > class in the main thread.  In both of these cases, Python claimed qApp
> > did not exist.
> >
> > Any suggestions would be most helpful.
> 
> At the risk of stating the obvious, have you read the "Thread Support in Qt" 
> section of the Qt documentation?
> 
> Phil
> 
> ___
> PyKDE mailing list[EMAIL PROTECTED]
> http://mats.gmd.de/mailman/listinfo/pykde
-- 
Nicholas John Murison
~
http://www.urgusabic.net


signature.asc
Description: This is a digitally signed message part