Re: [pygtk] Show command output (new IEs4Linux GUI)
On Thu, 2006-30-11 at 04:14 -0200, Internet Explorer Linux wrote: > Hi everybody! > > This is my first email to this list. My name is Sergio and I'm > IEs4Linux project's main developer (maybe someone use my program :-) > > I'm working on a pygtk user interface to my script. My GUI configures > some things and run an executable (IEs4linux installer, written in > bash). I need to open some kind of window to show the installer > output. > > I tried with TextView, but I don't know how to make it non-blocking. I > tried with Threads, but it waits until installer finishes to show the > output on TextView. I searched on Google and got some pages talking > about this (even with "solutions"), but I could not make it work. > > So, if anyone can help me with this thing I will be very thankful :-) > > Sérgio Lopes > From Brazil You can check out our installer gui app. The terminal is all python and does compiler message filtering, etc. There are 2 main areas that you should look at for how we handle the textview updates. 1) in terminal/terminal.py update() where we process the text and update the relevant textview buffers. 2) in readers/process_reader.py which reads the virtual terminal output (in a thread) and passes it back to the main gui for processing. There are other ways of handling it as well, but that one works well for us. If you look around you will also find out how to autoscroll the text as it is added, among other things. The link: http://porthole.cvs.sourceforge.net/porthole/trunk/ -- Brian <[EMAIL PROTECTED]> ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Show command output (new IEs4Linux GUI)
Hi everybody! This is my first email to this list. My name is Sergio and I'm IEs4Linux project's main developer (maybe someone use my program :-) I'm working on a pygtk user interface to my script. My GUI configures some things and run an executable (IEs4linux installer, written in bash). I need to open some kind of window to show the installer output. I tried with TextView, but I don't know how to make it non-blocking. I tried with Threads, but it waits until installer finishes to show the output on TextView. I searched on Google and got some pages talking about this (even with "solutions"), but I could not make it work. So, if anyone can help me with this thing I will be very thankful :-) Sérgio Lopes From Brazil ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Overriding GObject methods in Python
On Tue, 2006-11-28 at 20:55 +0100, John K Luebs wrote: > Don't you get it: If you have static traditional C structs with no > runtime based value marshalling and introspection, you HAVE TO HAVE > GLUE CODE. My point is that, if you design your own classes, you can add the necessary introspection subset which can be used by Python at runtime. That's what I was inquiring about. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Overriding GObject methods in Python
On Tue, 2006-11-28 at 14:34 +0100, Gustavo J. A. M. Carneiro wrote: > > The PyGTK approach requires writing a piece of glue C code for > every > > class whose methods need to be overridden. See the example of > > GtkCellRenderer. > > Yes and no: > > 1- Forget about GenericCellRenderer; it is old code, we have a new > better way of doing things; Thanks for the tip; what I didn't get at first is that the GenericCellRenderer is the exception to the rule. The PyGTK approach still requires compilation of new glue C code for each new GObject class added to the system, but at least the glue C code is (mostly) autogenerated, so it may be usable for this purpose. > The way of the future is the gobject-introspection module, but > unfortunately it is taking too long to be picked up by glib > developers :-( I agree that a general introspection facility would definitely resolve many issues raised by script bindings. For someone in a position to design his/her own classes, adding the necessary introspection to the classes may be the most straightforward path. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
