I have managed to write a small GUI app, it had a frm_app.py from eric3s QT
designer & a dlg_app.py which defined a class that inherited the frm_app.py
class all AK
I am now on a more ambitious project. There will be a main app screen, some
dialogue screens for more info etc and a backend script analysing a database
which will take some time to run.
The backend script is almost there, just tons of auditing rules to write for
it but the backend 'engine' is working.
How to fit the GUI around it ?
If I have my dlg_app.py inhereting frm_app.py all is well until I need a
poppup dialogue.
Would I define another module say dlg_info.py with its frm_info.py which I
would import and call when needed generating its own QT object and window.
And in that module code something like the following would make the window on
the fly ?
app = QApplication(sys.argv)
win = info()
app.setMainWidget(win)
win.show()
Q(app, SIGNAL('lastWindowClosed()'),app, SLT('quit()'))
app.exec_loop()
Secondly my backend will take a while to run & I would like to display a
status bar in the GUI. The only way i can see to do this is to either
(1) make my backend a class & inherit dlg_app.py so I can access the QT widget
directly or
(2) pass info from the backend via a socket (yep know about them now!) to a QT
script running in timerEvent()
Which is the best method ? is there a better way ?
Dave
Tutor maillist - Tutor (AT) python (DOT) org

I am now on a more ambitious project. There will be a main app
screen, some
dialogue screens for more info etc and a backend script analysing a
database
which will take some time to run.

How to fit the GUI around it ?

If I have my dlg_app.py inhereting frm_app.py all is well until I
need a
poppup dialogue.

Its usually better to make popups inherit directly from TopLevel
rather
than the parent form.

Would I define another module say dlg_info.py with its frm_info.py

Its usually best to put each significant window/dialog in its own
form.
It makes them easier to reuse in other projects for one thing!

would import and call when needed generating its own QT
object and window.

Not sure how QT works so can't comment on that.

app = QApplication(sys.argv)

Are you sure there isn't a QDialog base class somewhere in QT?
Thats usually been the case in other GUI toolkits I've used.

Secondly my backend will take a while to run & I would like to
display a
status bar in the GUI. The only way i can see to do this is to
either

Sounds like a job for a thread

(2) pass info from the backend via a socket (yep know about them
now!) to a QT
script running in timerEvent()

You can do this but threads are less resource greedy.

HTH,

Alan Gauld
Author of the Learn to Program web site

Tutor maillist - Tutor (AT) python (DOT) org

Tuesday 22 August 2006 17:15, Alan Gauld wrote:
I am now on a more ambitious project. There will be a main app
screen, some
dialogue screens for more info etc and a backend script analysing a
database
which will take some time to run.

How to fit the GUI around it ?

If I have my dlg_app.py inhereting frm_app.py all is well until I
need a
poppup dialogue.

Its usually better to make popups inherit directly from TopLevel
rather
than the parent form

K I will look into that

Would I define another module say dlg_info.py with its frm_info.py

Its usually best to put each significant window/dialog in its own
form.
It makes them easier to reuse in other projects for one thing!

Code reuse is good

would import and call when needed generating its own QT
object and window.

Not sure how QT works so can't comment on that.

app = QApplication(sys.argv)

Are you sure there isn't a QDialog base class somewhere in QT?
Thats usually been the case in other GUI toolkits I've used.

Base class ? K you lost me - I will dig into the docs

Secondly my backend will take a while to run & I would like to
display a
status bar in the GUI. The only way i can see to do this is to
either

Sounds like a job for a thread

(2) pass info from the backend via a socket (yep know about them
now!) to a QT
script running in timerEvent()

You can do this but threads are less resource greedy.

I had not thought of a thread - thats a cool solution

Thanks for your suggestions, Its probably obvious for you old hands but its a
whole new world for us beginners :)

You have given me enough info to run with - I will give it a go & see what
happens

Dave

HTH,

Alan Gauld
Author of the Learn to Program web site

Tutor maillist - Tutor (AT) python (DOT) org