[pygtk] Re: gnome-python and gnome-session
On 27/12/2003 8:08 AM, Martin Grimme wrote: Hi, gnome-python does not fully support session management, e.g. methods like gnome_client_set_restart_command() are missing. There has been a patch for the missing functions around since the days of 1.99.11 and Redhat and (now also) Debian patch their gnome-python with http://www.lunar-linux.com/lunar/patches/gnome-python-client-command.patch I just wonder why this patch has never been integrated into gnome-python CVS up to now; it looks very clean and since it only adds lines, doesn't break anything. Sorry for not getting back to you (been on break, and still have a stack of mail to go through). The reason I hadn't ever applied the patch is because I didn't know it existed. I see you have put this in bugzilla now (bug 130164), so I'll take a look at integrating it. /me hates vendor patches that don't make their way upstream James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pyORBit and threading
On 30/10/2003 1:02 AM, Sebastian Rittau wrote: Hi! I'm trying to get pyORBit to work with threading. Unfortunately this does not seem to work. When starting the attached sample script, the script will print out numbers of up to ~100 and then stop. gdb reports that thread 1 is hanging in poll(), while thread 3 is waiting for a signal. Has anybody any ideas on how to proceed to track this problem down? Currently PyORBit doesn't support multithreading. In order to do this right, I would probably need to use the PyGILState_* functions from Python 2.3, and possibly require ORBit 2.8 which supports multi-threaded POAs (ie. allowing requests to be handled by other threads, rather than blocking or causing unexpected reentrancy).. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] PyGtk/C extension - segfault
On 10/11/2003 7:52 PM, [EMAIL PROTECTED] wrote: Hi, a few days ago, I've got a great help on gtk-pygtk objects wrapping. Thanks a lot. Now, I have the library but the application crashes on segfault. I've been thinking it is problem of mine or problem of Python but PyGtk seems to have own part of this too. My program looks like: /* python setup */ ... Py_Initialize(); ... /* module setup */ initcavfs(); // init C extension - module cavfs initpywrap(); // init C extension - module pywrap /* While cavfs does just Py_InitModule(cavfs, cavfs_methods); */ Now, on init_gobject() or import gtk I get a segfault which ALWAYS leads to a stack trace similar to: #0 0x4d8b07f3 in strrchr () from /lib/libc.so.6 #1 in cavfs_methods() #2 in init_gobject() loading /usr/lib/python2.2/site-packages/gtk-2.0/libgobject.so ... Please, note that cavfs_methods is a variable of type PyMethodDef. There's no such method and it isn't referenced elsewhere! Compiled library contains cavfs_methods pointer in a data part not code part. Does anyone faced the same problem? Or can you image where's the root of my problem? Why does cavfs_methods get called? Thanks a lot, Tobbi You didn't compile your cavfs module with debug info (or alternatively, you passed -export-symbols-regex to an unpatched libtool when linking your module). When this happens, gdb makes its best guess about what function the stack frame refers to based on what it finds in the dynamic symbol table. This often causes static functions to be mistaken for visible symbols defined near by. Without the debug info, it is a lot more difficult to diagnose the problem. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk.FileSelection source code... where?
On 7/11/2003 11:29 AM, David Bernard wrote: Hi ! Newby question: I want to make my own version of gtk.FileSelection, and I need to copy some functions from the original (ugly) one, where can I find it? Sorry for my bad english.. Like the other widgets in GTK, GtkFileSelection is implemented in C (ie. you won't find a Python source file for it). You can find the source code in gtk+/gtk/gtkfilesel.c. Note that GTK 2.4 will contain a new file chooser widget that you might hate less, so I wouldn't put too much effort into a hacked up GtkFileSelection widget. Among other things, the new implementation virtualises the file system access, allowing for different behaviours on Unix and Windows. This means that: * the file selector could show the shell file system layout on Windows, with Desktop as the root element, and pick up Windows file icons. * A gnome-vfs file chooser backend could be supplied so that when running apps under Gnome, things should match Nautilus's world view a bit better. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] My menubar disappear with mysql
On 4/11/2003 6:30 AM, mc collilieux wrote: Hello, I would continue a programm beginned with pygtk 1.99.13 and python 2.2 (which was working well) with python 2.2.2 and pygtk 2.0 and it is crazy... I have a top level window with : vbox ---vbox -- a menubar ---vbox -- a notebook Each choice of menu call a module which open and write a new page of Notebook and when inside this module, there is a onnection to MySQLdb, my menu is eaten by the new page of notebook. If my module has a line import MySQLdb but no connexion requested, it is good, but if the module as a line from %ySQLdb import *, without connection, it eat my menubar ! I can't understand the link between my menu and mysql ! I have try MySQLdb 0.9.1, 0.9.2 and 0.9.3 test, it is the same thing. Please, an idea ? The only thing I can think of is that when you import MySQLdb, the Python garbage collector gets run, causing some unreferenced object to get collected (in this case, probably a gtk.ItemFactory). You can easily check this by replacing the import statement with import gc; gc.collect() James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: pickling a TreeStore? Re: [pygtk] Creating a sortable model derived from GenericTreeModel
On 23/10/2003 3:00 AM, Eugene Koontz wrote: I'm in a similar situation that Don Allingham describes in his post Creating a sortable model derived from GenericTreeModel : I have a big TreeStore that takes a long time to load. My proposed solution is to have a compile-time step of pickling the store to a file, and then at run-time, loading the pickled store into a TreeView. Unfortunately, when I try to pickle a TreeStore, I get : TypeError: can't pickle TreeStore objects According to the pickle documentation ( http://python.org/doc/2.3.1/lib/node64.html ), objects can be pickled if they are at the top level of a module. Would it be possible for me to hack the pygtk sources to put TreeStore at the top level of a module? If so, which file in the source distribution should I look at? Thanks for any ideas, No widgets in PyGTK are picklable. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] TextView width depending on maximum number of character per line
On 23/10/2003 8:37 AM, Dàvik wrote:
Hi!
I need a TextView that changes its width depending on the maximum number
of characters per line that the user wants it to have. I need that the
user be able to configure it to have between a number of characters per
line and that it changes its width to have exactly the maximum number
they choose.
I mean it for a courier-type font always of the same size.
Is there any way to do it?
Do something like the following:
context = widget.get_pango_context()
metrics = context.get_metrics('font name, 12')
width = pango.PIXELS(metrics.get_approximate_char_width() * n_chars)
For a monospaced font, this should be quite accurate. You can then use
widget.set_size_request() to set that as the minimum width for the view.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: right clicking on a GtkTreeStore row
On 29/09/2003 11:51 PM, Christian Reis wrote: On Mon, Sep 29, 2003 at 04:49:49PM +0100, Stephen Kennedy wrote: On Mon, 2003-09-29 at 16:01, Christian Reis wrote: On Thu, Sep 25, 2003 at 10:57:23AM +0100, Stephen Kennedy wrote: path, col, cellx, celly = treeview.get_path_at_pos( int(event.x), int(event.y) ) Question: Aren't event.x and event.y always integers? Actually in pygtk-2.0.0 they're floats. I found this out when upgrading to python2.3 - it gives warnings when passing floats to c functions taking an integer. We have subpixel resolutions now? Some input devices give subpixel accuracy, such as some graphics tablets (which might also give tilt and pressure information about the pointer). GTK 1.2 was the same. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Showing an inconsistent state with CellRendererToggle?
On 25/09/2003 4:23 AM, David Moore wrote: Is it possible for a TreeModel to tell a CellRendererToggle that it is in an in between (inconsistent) state??? I have a TreeModel class derieved from GenericTreeModel. Each node in the tree can be in one of three states yes, no, or maybe. Can a CellRendererToggle show this or do I need a custom renderer? e.g. class MyModel(gtk.GenericTreeModel): def on_get_value(self, node, column): if column == 0: return node.Yes_No_Maybe elif column == 1: return gtk.TRUE else: raise AssertionError(no column %i % column) The gtk.CellRendererToggle has an inconsistent property, similar to the active property. If it is set to True, then the cell will display in the inconsistent state. You can either have a column in your model that maps to the inconsistent property, or use a cell data function to set the property based on some other condition. The C documentation lists the properties: http://developer.gnome.org/doc/API/2.0/gtk/GtkCellRendererToggle.html James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Problems compiling current CVS head on Win32.
On 23/09/2003 5:08 PM, Alif Wahid wrote: Hi folks, I've had some problems compiling the current CVS head of PyGtk-2.1.x on Win32. So I've submitted a patch on bugzilla to fix that. Basically there are some undefined symbols in the official Gtk+-2.2.4 binaries. So I've added empty function stubs to the gtk-fake-win32.c file. Also updated the setup.py file to reflect newer dependency versions and no support for GtkGLArea. Which new functions do not exist on win32? As with pygtk 2.0.x, I would like the new version to build out of the box on win32 as well. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Trouble building Python-Gnome 2.0 on Mac Os 10.2
On 18/09/2003 5:28 PM, [EMAIL PROTECTED] wrote: I am trying to compile python-gnome 2.0 on Mac Os 10.2.6 to port the newest gramps and gcompris to mac Os X. I am using fink and I manage to create a package for pygtk 2.0 but I cannot compile python-gnome 2.0. I end up with the following error message : generating symbol list for `gconf.la' /usr/bin/nm -p .libs/gconf_la-gconfmodule.o .libs/gconf_la-gconf-fixes.o libs/gconf_la-gconf.o | sed -n -e 's/^.*[]\([BCDEGRST][BCDEGRST]*\)[ ][ ]*\(_\)\([_A-Za-z][_A-Za-z0-9]*\)$/ \1 \2\3 \3/p' | /usr/bin/sed 's/.* //' | sort | uniq .libs/gconf.exp grep -E -e initgconf .libs/gconf.exp .libs/gconf.expT mv -f .libs/gconf.expT .libs/gconf.exp sed -e s,#.*,, -e s,^[ ]*,, -e s,^\(..*\),_, .libs/gconf.exp libs/gconf-symbols.expsym gcc -bundle -flat_namespace -undefined suppress -o .libs/gconf.so .libs/gconf_la- gconfmodule.o .libs/gconf_la-gconf-fixes.o .libs/gconf_la-gconf.o /sw/lib/libpopt.dylib -L/sw/ lib /sw/lib/libgconf-2.dylib /sw/lib/libORBit-2.dylib -lm /sw/lib/liblinc.dylib /sw/lib/libgmodule- 2.0.dylib /sw/lib/libgobject-2.0.dylib /sw/lib/libgthread-2.0.dylib /sw/lib/libglib-2.0.dylib /sw/ lib/libintl.dylib /sw/lib/libiconv.dylib ld: multiple definitions of symbol __PyGObject_API libs/gconf_la-gconfmodule.o definition of __PyGObject_API in section (__DATA,__common) libs/gconf_la-gconf.o definition of __PyGObject_API in section (__DATA,__common) ld: warning multiple definitions of symbol _locale_charset /sw/lib/libiconv.dylib(localcharset.lo) definition of _locale_charset /sw/lib/libintl.dylib(localcharset.lo) definition of _locale_charset make[2]: *** [gconf.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Thanks for your help Could you report this in bugzilla please? We had a number of problems similar to this in other parts of pygtk, and it would be good to make sure it doesn't get lost. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk.Window.get_position()
On 19/09/03 16:37, [EMAIL PROTECTED] wrote: Hi to all, I've a Window with a TextView, and I want to display another window (a popup winow) near the cursor position of the TextView. So I've calculate the cursor position with the buffer_to_window_coords() method and then I try to use the method get_position() of the Window to obtain the window position on the screen. The problem is that get_position() alwais return (0,0) to me, why? The following piece of code is what I'm using buffer=self.text_view.get_buffer() iter=buffer.get_iter_at_mark(buffer.get_insert()) rectangle=self.text_view.get_iter_location(iter) absX, absY=self.text_view.buffer_to_window_coords(gtk.TEXT_WINDOW_TEXT, rectangle.x ,rectangle.y) print absX, absY self.window.show_all() winX, winY=self.popup.get_position() print winX, winY and it prints 43 32 #of course theese values can be different 0 0 Any ideas or suggestions? The position of the window is relative to the parent window. If you want the position relative to the root window, you can use the get_root_origin() method. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] scaling fonts
On 16/09/03 06:08, John Hunter wrote:
I am trying to scale my pango fonts with a DPI parameter for my
plotting library. I have two parameters, figsize (tuple in inches)
and DPI (int) and my figure size is a tuple in pixels given by the
product of these, ie, (figsize[0]*dpi, figsize[1]*dpi)
When I increase the DPI for hardcopy (rendering to a pixmap and then
saving as PNG) I want the fonts to scale with the rest of the lines,
rectangles, arcs, etc
I tried experimenting with the set_size parameter of the
FontDescription and the various pango scales, but there is not a wide
enough range of scales to go from screen displays to, say, hardcopy
resolutions of 600 dpi.
I create the font description as
# fontsize in points
font = pango.FontDescription('%s %d' % (fontname, fontsize))
and would like to be able to scale the fontsize by an arbitrary scale,
something like
scale = outputDPI/screenDPI
font.set_size(int(scale*fontsize*pango.SCALE))
But this will cause X crashes for large values of scale. If I use the
pango SCALE constants for scale aboce, as in
font.set_size(int(pango.SCALE_XX_LARGE*fontsize*pango.SCALE))
I don't get the crashes but I can't get my fonts large enough --
SCALE_XX_LARGE is only 1.2.
Any ideas on how to scale fonts? Is this possible with pango?
Alternatively, is there any true type font support that can be used
with pygtk?
Thanks for any help,
John Hunter
X crash with an arbitrary, large, scale factor:
The program 'histogram_demo.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 381 error_code 8 request_code 73 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Are you using the core X font backend or the Xft backend? What sort of
font sizes are causing problems? (an approximate figure would be useful).
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk+vtk again
On 18/09/2003 3:45 AM, Tim Newsham wrote: [In a blast from the past, John Hunter said...] BTW Prabu, the Lueb patch also exposes the hwnd attribute for win32 systems, which I think is the analog of the xid attribute. Hence it should be possible to port the GtkVTKRenderWindow code to win32 with the patched pygtk2. Something like def OnRealize(self, *args): if self.__Created == 0: # you can't get the xid without the window being realized. self.realize() if sys.platform=='win32': win_id = str(self.get_window().hwnd) else: win_id = str(self.get_window().xid) self._RenderWindow.SetWindowInfo(win_id) self.__Created = 1 return gtk.TRUE I haven't been able to test this yet. John Hunter I just did. It mostly works - When the gui first comes up you see some flickering, the background gray shows through, then the black render window pops over it and then the gray shows through once again. - If I start interacting in the render window, the black render window shows through again. - If the window loses focus, the grey backdrop is once again painted over the rendered data. - when I quit, the program crashes (that is, the python binary) during shutdown. If I do SetRenderWindow(None) on the renderer before quitting, I can avoid the crash (seems that the render window is destroyed twice during shutdown, once when the physical window goes away, and again when the renderer is destroyed). I'm no windows gui expert or gtk+ expert, but I'll probably try to bang my head against this anyway. If anyone has helpful pointers, they would be appreciated. Btw.. why not expose the xid and hwnd variables under the same name if their values are used in nearly interchangeable ways? Does the problem go away if you call self.set_double_buffered(False) during the creation of your widget? You are probably running into some problems with GTK's double buffering (you draw onto the window, then GTK blits the contents of a pixmap over the top right after). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Creating a new Pango Context
On 15/09/03 20:06, Nathan Hurst wrote: On Thu, 11 Sep 2003 12:15:32 +0800 James Henstridge [EMAIL PROTECTED] wrote: On 11/09/2003 11:38 AM, Nathan Hurst wrote: How can I create a new, or copy an existing, pango context? I am currently using the widget.get_pango_context() one, but I can't work out how to make a new one. If I use the one attached to the widget I have to restore everything after every use. widget.create_pango_context() should give you a new one. Thanks! Why doesn't pango.Context() work though? PangoContext is really an abstract interface. There are currently context implementations for core X fonts (already removed from the HEAD branch), Xft, Win32 and freetype. Widget.create_pango_context() will create a context appropriate for use with that widget, so you don't need to worry about these details. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] sys.excepthook and the gtk thread lock
On 12/09/2003 8:42 AM, Tim Evans wrote: I have created a routine that displays exceptions in a gtk dialog box, which I place in sys.excepthook. I have run into a problem when using this routine with threading. The sys.excepthook function can be run from all sorts of places, sometimes the gtk lock will be held, other times it won't be. The gdk thread lock is not guaranteed to be recursive (it's just a GMutex, not a GStaticRecMutex), so I can't just call gtk.threads_enter every time as it could deadlock. Does anyone have a solution to this? Does anyone else think it would be much easier if the gtk lock was recursive? GDK_THREADS_ENTER is a macro, so I don't think that the lock could be changed from a GMutex to a GStaticRecMutex without breaking binary compatibility. This is not going to happen. There are many bits of code that use the GDK_THREADS_ENTER/LEAVE macros, not just in pygtk and GTK proper. What you can probably do though is to queue an idle handler that displays the dialog. Next time the main loop is run, your idle handler will get executed, where you can create and display the dialog. Note that you will need to put in gtk.threads_enter()/leave() calls in your idle handler, because the lock isn't held when running an idle. Alternatively, you could ignore threading completely, and only use your excepthook with single threaded programs ... James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Creating a new Pango Context
On 11/09/2003 11:38 AM, Nathan Hurst wrote: How can I create a new, or copy an existing, pango context? I am currently using the widget.get_pango_context() one, but I can't work out how to make a new one. If I use the one attached to the widget I have to restore everything after every use. widget.create_pango_context() should give you a new one. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Install Problems
On 09/09/03 20:05, Shaffer, Chris wrote: Help!!! I'm having problems installing the latest gnome-python and PyORBit on my mandrake 9.1 box. I have python2.3 installed from src, as well as the latest-greatest pygtk2 (from src). Both work fine (at least with my apps)... When I try and install PyORBit, I get this: [EMAIL PROTECTED] pyorbit-2.0.0]# python setup.py build running build running build_py file CORBA.py (for module CORBA) not found file PortableServer.py (for module PortableServer) not found file CORBA.py (for module CORBA) not found file PortableServer.py (for module PortableServer) not found running build_ext building 'ORBit' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DORBIT2_STUBS_API=1 -I/usr/include/orbit-2.0 -I/usr/include/linc-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/local/include/python2.3 -c src/ORBitmodule.c -o build/temp.linux-i686-2.3/src/ORBitmodule.o src/ORBitmodule.c: In function `initORBit': src/ORBitmodule.c:424: `PYORBIT_MAJOR_VERSION' undeclared (first use in this function) src/ORBitmodule.c:424: (Each undeclared identifier is reported only once src/ORBitmodule.c:424: for each function it appears in.) src/ORBitmodule.c:425: `PYORBIT_MINOR_VERSION' undeclared (first use in this function) src/ORBitmodule.c:426: `PYORBIT_MICRO_VERSION' undeclared (first use in this function) error: command 'gcc' failed with exit status 1 And when I attempt to install gnome-python: [EMAIL PROTECTED] gnome-python-2.0.0]# python setup.py install Could not find PyGTK Aborting What am I missing? Thanks in advance! Try using the configure scripts instead: ./configure --prefix=prefix where python is installed make make install James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Install Problems
On 09/09/03 21:59, Shaffer, Chris wrote: Okay, that worked on PyORBit, but here is the output from running './configure --prefix=/usr/local' in the gnome-python folder: checking for pygtk-2.0 = 2.0.0... Package pygtk-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `pygtk-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'pygtk-2.0' found configure: error: Library requirements (pygtk-2.0 = 2.0.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. Do you have PyGTK installed? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Install Problems
On 09/09/03 22:13, Shaffer, Chris wrote: As far as I know. My PyGTK apps work, and when I look in /usr/local/lib/python2.3/site-packages, I have a gtk-2.0 folder, as well as pygtk.py file... I installed PyGTK from the latest source on the PyGTK homepage... In that case, take the following bit of advice: Perhaps you should add the directory containing `pygtk-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'pygtk-2.0' found In your case, you probably want to do the following before running configure: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig export PKG_CONFIG_PATH James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] CVS branches and plans for the future.
On 07/09/03 14:27, John K Luebs wrote: Currently, pygtk seems to be supporting both Python 2.2 and 2.3. What does 2.3 have that 2.2 does not have that would warrant ditching support for 2.2? If it ain't broke... Well, there is one feature found in Python 2.3's C API that could be useful, and is not found in 2.2: the PyGILState APIs I mentioned earlier. We will probably want to use them eventually, as they should help pygtk interoperate better with other thread aware extensions. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Missing about icon in menu
On 06/09/03 03:05, Benjamin Liblit wrote: James Henstridge wrote: I just left a note in the bug report you filed about this. I can't find that report in GNOME bugzilla. Link? http://bugzilla.gnome.org/show_bug.cgi?id=121158 James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] CVS branches and plans for the future.
On 06/09/03 14:58, Andrew P. Lentvorski, Jr. wrote: On Wed, 3 Sep 2003, Malcolm Tredinnick wrote: My only real request is to continue supporting Python 2.2. I was one of the people in favour of requiring 2.2 early on, so this risks sounding hypocritical, but the changes between 2.2 and 2.3 are not as large as from 2.1 to 2.2 and there will be a lot of installations with no plans to upgrade for some time. Would you allow PyGtk 2.1.X (or PyGtk 2.2.X if the convention of even major release numbers being the stable version is followed) to require Python 2.3 and Gtk 2.4 since Gtk 2.4 will break binary compatibility? Since when will GTK 2.4 break binary compatibility? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Warnings issued by get_property
On 4/09/2003 8:00 AM, Michael McLay wrote:
I received an odd warning when testing the use of get_property. Accessing the
'child' property for a button returns the message:
(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property id 3
for child of type `GParamObject' in `GtkButton'
c.get_property('child')
(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property id 3
for child of type `GParamObject' in `GtkButton'
Here's the code that caused this to happen.
the GtkContainer::child property is write-only, which is why you get
weird results when trying to read it. The other cases are most likely
similar.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: PyORBit 2.0.0
PyORBit 2.0.0, the Python binding for the ORBit2 CORBA ORB, is now available at: http://ftp.gnome.org/pub/GNOME/sources/pyorbit/2.0/ PyORBit provides both client and server side CORBA bindings, and aims to follow the standard Python language mapping for CORBA (http://www.omg.org/cgi-bin/doc?formal/02-09-07). PyORBit is capable of calling in process servers implemented using ORBit2, and being called by in process C code. This makes it ideal for use in the Gnome environment, and is used by the gnome-python Gnome bindings. PyORBit requires ORBit2 = 2.4.4 and Python = 2.2. Questions about PyORBit can be directed to the PyGTK list: http://www.daa.com.au/mailman/listinfo/pygtk Bug reports should be filed at the Gnome bug tracker: http://bugzilla.gnome.org/enter_bug.cgi?product=pyorbit James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: Gnome-Python 2.0.0
Gnome-Python 2.0.0 is now available at: http://ftp.gnome.org/pub/GNOME/sources/gnome-python/2.0/ Gnome-Python provides bindings for the Gnome 2.x development platform libraries. It builds on top of PyGTK, and includes bindings for the following: * the GConf configuration database * the Bonobo component system * the Gnome-VFS file access library * support for writing panel applets and Nautilus views * the GtkHTML2 widget. * the Gnome-Print print libraries. Gnome-Python requires PyGTK, PyORBit, Python = 2.2 and the Gnome 2.x development platform to build. Questions about Gnome-Python can be directed to the PyGTK list: http://www.daa.com.au/mailman/listinfo/pygtk Bug reports should be filed at the Gnome bug tracker: http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-python James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] CVS branches and plans for the future.
I have just branched pygtk, pyorbit and gnome-python in CVS. If you want to get the 2.0 branches, you will need to switch your branches over to the branches: cd pygtk; cvs update -r pygtk-2-0 . cd pyorbit; cvs update -r pyorbit-2-0 . cd gnome-python; cvs update -r gnome-python-2-0 . Development on the HEAD branch of pygtk will look at adding support for new GTK 2.2 APIs. It shouldn't take anywhere near as long to get the 2.2.0 release ready. If no one complains, I would also like to remove the GtkGLArea bindings from PyGTK. Since GtkGLExt seems to have an active maintainer and Python bindings, there doesn't seem to be too much need for it. If it is needed, the binding could easily be moved to GtkGLArea itself. For gnome-python, it probably makes sense to focus on Gnome 2.4 as it is very close to release, since it includes a number of improvements relevant to the Python bindings. Among other things, it probably makes sense to kill the gnome.zvt binding. I don't have many plans for pyorbit enhancements, other than removing cruft needed to support older ORBit2 versions. Any comments? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Missing about icon in menu
On 1/09/2003 3:07 PM, Colin Fox wrote: For some reason, when I create a Gnome project, and add a Gnome app window, the yellow star beside the About menu doesn't show up in my program. It shows up in the glade editor, though. All the other icons in the menus are fine. Just the about star is missing. Is anyone else getting this, or is there something strange about my setup? I just left a note in the bug report you filed about this. The bug is in libgnome, and has been fixed in CVS (both 2.2 and 2.4 branches). There have been tarball releases on the 2.4 branch since then, but not 2.2 branch. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Can anyone do a status on OSX + PyGTK?
On 29/08/2003 3:58 AM, Scott Prive wrote: Hi, I am using PyGTK2 on Windows and Linux. Has anyone built a package for OS/X? I understand from a few weeks ago's threads that there were issues building under OS/X, but they should/might be cleared up now. Is there perhaps an un-official or experimental fink package? PyGTK should be buildable out of the box on MacOS X provided you have the required libraries and headers installed. The build process should be pretty much the same as on other Unix systems. There were some bugs in older versions of pygtk that have since been cleaned up (they were real bugs, but only seemed to cause the compiler to error out on OS X). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pygtk-FAQ entry 13.25 (sequence APIs for TreeStore andListStore)
On 27/08/2003 7:47 PM, [EMAIL PROTECTED] wrote: Hi again, The sequence API as described in the pygtk FAQ entry 13.25 http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq13.025.htp does not work, the TreeStore and ListStore objects do have a function __getitem__, but no __setitem__. Where has __setitem__ gone? pygtk-1.99.15 on win32, gtk-2.2.2 please upgrade to a newer version of pygtk. I think the functionality you want was added later on. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Can't get key-press-events..
On 27/08/2003 6:58 AM, alejandro david weil wrote: Hi. I'm using python-gtk21.99.17-3 on debian. The problem is that i can't get keypress events, and, i'm getting the button-press-events in right way. I'm tryng to get them, on a subclass of gtk.DrawingArea. The code is this: self.connect(expose-event, self.area_expose_cb) self.add_events(gtk.gdk.BUTTON_PRESS_MASK) self.add_events(gtk.gdk.KEY_PRESS) self.connect(button_press_event,self.someevent) self.connect(key_press_event,self.someevent) #self.connect(key-press-event,self.keyevent) I'm not too familiar with python-gtk, i make all the tests that could help. the first: button-press-event works correctly. I tried without the button_press.. Also i tried wrapping my DA subclass on a gtk.EventBox.. but keeps failing. Well.. any help would be appreciated. Now i'm going to check te value of gtk.gdk.KEY_PRESS. key press events are sent to the widget with the keyboard focus, which is not necessarily the same as the widget the mouse is over. You can mage a drawing area focusable like this: drawing_area.set_flags(gtk.CAN_FOCUS) You can then set the widget as the focus widget for the window like this: drawing_area.grab_focus() James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] extra_ivars assersion failure
On 28/08/2003 6:33 AM, Ben Liblit wrote: I'm having trouble subclassing a class from an extension module. When Python processes my subclass definition, and before any instances are created, it aborts with: python: Objects/typeobject.c:872: extra_ivars: Assertion `t_size = b_size' failed. The extension module is trying to coordinate no less than three different object systems (GObject, CORBA, Python). Let me back up and explain what's going on in there. In the world of the GTK+ GObject system, I've got a GObject subclass. (It's actually a subclass of BonoboObject, which in turn derives from GObject.) I can write C code that instantiates this GObject-derived class and all is well. I'm wrapping these GObject instances inside Python objects using h2def.py and pygtk-codegen-2.0. The .defs file looks good: there's a define-object construct with the right class name and parent class name. The constructor is detected and wrapped correctly. In the .override file I import bonobo.Object as PyBonoboObject_Type, and everything builds smoothly. I can write Python code that instantiates this wrapper class and all is well. What I cannot do is subclass this wrapper class in Python code. When I try to, I get the diagnostic message reported earlier: python: Objects/typeobject.c:872: extra_ivars: Assertion `t_size = b_size' failed. Does anyone know what deeper problem this message is symptomatic of? What am I doing wrong in my extension module that would allow it to work correctly when the wrapper class is instantiated directly, but which would cause this error when a subclass of the wrapper class is defined? It sounds like the size of your object (tp_basicsize) is smaller than the size of your base class. Python raises an assertion here because it would mean that methods of the base class may try to access unallocated memory when presented an instance of the subclass. Take a look at the examples in the Python descriptor intro document about how to subclass from something like list. That should give an idea of what to do in this case. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] GnomeAppBar and Glade
On 28/08/03 17:57, Lawrence Oluyede wrote: I'm reading a C-based tutorial to learn using Glade2, but I still have a problem. When I try to get the GnomeAppBar widget from the XML tree what the get_widget method returns is: gtk.HBox object (GnomeAppBar) at 0x40c12464 and when I try to use push() or set_status() method to put text into the app bar it raises an error since it doesn't find such methods. What I'm doing wrong? The HBox obviously doesn't have those methods but what if want to use GnomeAppBar widget with Python? Have you imported gnome.ui and called gnome.program_init() ? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: pygtk-1.99.18, pyorbit-1.99.7,gnome-python-1.99.18
I've just uploaded new releases of pygtk, pyorbit and gnome-python. You can download them from ftp.gnome.org and its list of mirrors: http://ftp.gnome.org/pub/GNOME/sources/pygtk/1.99/ http://ftp.gnome.org/pub/GNOME/sources/pyorbit/1.99/ http://ftp.gnome.org/pub/GNOME/sources/gnome-python/1.99/ Pygtk can also be downloaded from ftp.gtk.org and its mirrors: ftp://ftp.gtk.org/pub/gtk/python/v2.0/ These packages are quite close to what I'd like to release as 2.0, so I'd like to hear about any showstopper problems. If nothing goes wrong, expect 2.0 releases soon. Note that this is not the end of development -- I just need to get the release out and branch before moving on to 2.2. New in this release of pygtk: * Fix up a duplicate symbol bug in the atk module, that was causing build problems on MacOS X (hopefully the last such problem). * add gtk.glade.set_custom_handler() API, that provides more info to the custom widget callback. Deprecate set_custom_widget_callbacks(). * some other bug fixes. New in this release of pyorbit: * fix a problem with handling of exceptions that was uncovered by Python 2.3. * disable assigning to unknown attributes on stub instances. Saves a little memory too. * add CORBA.ORB.work_pending() and CORBA.ORB.perform_work() methods. New in this release of gnome-python: * Many improvements to the GnomePrint modules. (Gustavo) * Improvements to Bonobo bindings (Gustavo) * Improvements to the GnomeVFS bindings (Johan) * Fix some function names that still had gnome_ prefixes. * Possible fix for the os.popen() bug related to SIGCHLD handling. * Don't raise fatal errors during module initialisation. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Using Accessibility interface from PyORBit?
On 22/08/03 21:00, Tessa Lau wrote: Is it possible that you are running into this problem? http://bugzilla.gnome.org/show_bug.cgi?id=118990 Upgrading to pyorbit from CVS does fix the segfault, but it doesn't fix the problem. I still get a CORBA.NO_IMPLEMENT exception when I try to call registerGlobalEventListener on the Accessibility.Registry. The CORBA exception is raised on line 195 of pyorbit-servant.c, where it has just tried to look up an imethod named ref on the servant. The servant implements the Accessible.EventListener interface, and there is no ref method declared for that interface. So I'm not surprised it's raising an exception. But why is it trying to find a ref method in the first place? The Accessible.EventListener interface derives from the Bonobo.Unknown interface, which has a ref operation. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Using Accessibility interface from PyORBit?
On 21/08/2003 9:20 PM, Tessa Lau wrote: I'm digging into this further. I upgraded to Python 2.3 and pyorbit 1.99.6-4, as packaged by Debian unstable. The test script I posted the other day now segfaults in registerGlobalEventListener. Here's the backtrace: #0 0x080785d0 in PyObject_SetAttrString () #1 0x402f3ec8 in demarshal_value (tc=0x40332320, val=0xb550) at pycorba-marshal.c:482 #2 0x402f46b3 in pyorbit_demarshal_any (any=0xb590) at pycorba-marshal.c:676 #3 0x402f4f88 in pyorbit_check_ex (ev=0xb660) at pycorba-exceptions.c:39 #4 0x402f1bbe in pycorba_method_call (self=0x40383310, args=0x40389b94, kwargs=0x0) at pycorba-method.c:164 #5 0x402f262a in pycorba_bound_method_call (self=0x40383730, args=0x40389b94, kwargs=0x0) at pycorba-method.c:454 #6 0x0805b060 in PyObject_Call () #7 0x080a3f00 in PyEval_CallObjectWithKeywords () #8 0x080a3bbf in PyEval_CallObjectWithKeywords () #9 0x080a2250 in Py_MakePendingCalls () #10 0x0002 in ?? () #11 0xb7f8 in ?? () #12 0x080a14a8 in Py_MakePendingCalls () Line 482 in pycorba-marshal.c calls PyObject_SetAttrString with a NULL instance. The instance was created on line 465 by a call to PyObject_CallFunction, which returns NULL. Going up the stack, demarshal_value is called by pyorbit_demarshal_any with the first parameter a CORBA_TypeCode of NO_IMPLEMENT. I think this is the same problem I was seeing before, only the CORBA exception now causes a crash instead of being propagated as a Python exception as it did in my previous post (which was from a system that is still running Python 2.2.3 and PyORBit 1.99.6-3, and presumably an earlier version of Bonobo/ORBit). The CORBA exception is raised in pyorbit-servant.c:200, in pyorbit_servant_generic_skel_func, where imethod-name is ref and PyObject_GetAttrString(pyservant, ref) is returning NULL. I'm still not sure yet where this ref string is coming from. Any ideas? Is it possible that you are running into this problem? http://bugzilla.gnome.org/show_bug.cgi?id=118990 If so, the latest CVS should fix the problem. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Treeview Icons
On 11/08/2003 5:04 AM, Colin Fox wrote: On Sun, 2003-08-10 at 11:30, Doug Quale wrote: Here is a simple example using icons in a TreeView. Thanks! That's perfect. Just out of curiosity, how would I show different images for when the item is expanded and collapsed? According to the C documentation at: http://developer.gnome.org/doc/API/2.0/gtk/GtkCellRendererPixbuf.html You just associate a model column with the pixbuf_expander_closed and pixbuf_expander_open properties instead of pixbuf. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Using Accessibility interface from PyORBit?
On 13/08/03 04:52, Tessa Lau wrote:
Hi all,
I'm trying to use PyORBit to duplicate some of the functionality of
AT-poke (the GNOME accessibility query tool). I haven't found any
documentation on how to use CORBA, much less CORBA with Python. So far
I've used orbit-idl-2 to process the Accessibility.idl file included
with AT-SPI, and created what I believe is an imodule (a .so file that I
can place in ORBIT_TYPELIB_PATH). I can then use
ORBit.load_typelib('Accessibility') to load it.
Then, from reading the IDLs, it looks like I want to get an
Accessible_Desktop instance, and then call methods on that such as
getChildCount(). How do I get one of those? The example at
http://www.daa.com.au/~james/talks/guadec2003/pyorbit/slide13.html
uses activation-client to find the IOR for a running Nautilus instance,
but I can't figure out how to use that to get me an IOR for an
Accessible_Desktop. Am I on the right path?
Note that you can use the bonobo.activation.query() method, rather than
forking activation-client to activate objects. I simply used
activation-client in my examples during the talk to demonstrate that the
bonobo bindings weren't doing anything behind the scenes to load up IDL.
From the look of it, to make use of the accessibility framework, you
need to activate the a11y registry. The query string for that would
look something like this:
repo_ids.has(IDL:Accessibility/Registry:1.0)
You can then get references to the Accessibility.Desktop objects using
the registry's getDesktop(n) operation (the getDesktopCount() operation
will tell you how many desktops are available).
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] bugzilla reorganisation
I have added pygtk and pyorbit products to bugzilla now, and had the associated bugs moved over (I got Luis to do this, so that it wouldn't send out loads of unwanted bugspam). The main reason for this was to allow better classification of pygtk bugs in the future. Also, a number of people missed the gnome-python product when trying to work out where to submit pygtk bugs, so this should help. If you have any stored bugzilla queries, you will probably want to modify them to also check the pygtk and pyorbit products. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [omniORB] Re: [pygtk] Conflicting omniORBpy and PyORBit
On 3/08/2003 3:18 AM, Duncan Grisby wrote: On Friday 1 August, James Henstridge wrote: The only issue for packagers is how to deal with the top-level CORBA (and PortableServer, etc.) modules. One solution would be to install them only if they are not already there from a different ORB. Yep, and that seems to be a problem for distributors wishing to package multiple Python ORBs. I am not sure what the right choice here is. One option would be for each ORB package to be split in two, one with the main distribution, and one with just the top-level CORBA.py etc. That way, you could choose to install several main ORB packages, and just one default ORB package or something like that. I was thinking a bit about this last statement of yours, and I don't think it is a very satisfactory way to leave things. I know of no Linux distributions which are in a position to make a decision about what their default ORB should be. They are more likely to package an ORB if they want to ship applications that use it. More over, if you are writing an application that uses a particular ORB, and you want to make it work on as many systems as possible you wouldn't be able to just type import CORBA, since your program would break on systems which picked a different default ORB. If importing CORBA isn't always going to work, is it ever a good idea to import the module? If it is never a good idea to import CORBA, then should ORBs ever provide a toplevel module by that name? This definitely sounds like a problem with the spec. I've got no idea when the next version of the standard is likely to be made available, so it might be worth coming up with some guidelines/clarifications we can agree on. In the above reasoning, I am assuming that applications will just run with any available ORB. I think this is a fairly safe assumption, since apps may: * include stubs/skeleton files generated for a particular ORB * rely on special features of a particular ORB * need to interoperate with other bits of code using a particular ORB (this is the case for gnome programs wishing to manipulate in process Bonobo objects, which is why it can't use omniORB). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Using Accessibility interface from PyORBit?
On 13/08/03 04:52, Tessa Lau wrote:
Hi all,
I'm trying to use PyORBit to duplicate some of the functionality of
AT-poke (the GNOME accessibility query tool). I haven't found any
documentation on how to use CORBA, much less CORBA with Python. So far
I've used orbit-idl-2 to process the Accessibility.idl file included
with AT-SPI, and created what I believe is an imodule (a .so file that I
can place in ORBIT_TYPELIB_PATH). I can then use
ORBit.load_typelib('Accessibility') to load it.
Forgot to mention that at-spi comes with a typelib already, so it
shouldn't have been necessary to recreate the typelib. The idea is that
the systems providing interfaces like Bonobo::* and Accessibility::*
ship typelibs, rather than requiring Python developers to compile them ...
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Conflicting omniORBpy and PyORBit
On 1/08/2003 4:01 PM, ml wrote: Hi, I want to have both omniORBpy and PyORBit installed in parallel. The first, because I use it for my own applications, the latter, because some GNOME programs depend on python-gnome2 and therefore on PyORBit. Unfortunately, both packages include a file /usr/lib/python2.2/site-packages/CORBA.py which leads to the conflict. What is the best solution? What does the standard say? How has this been dealt with in the past? Some ideas: Moving one of the files to a subdirectory seems an easy thing, but applications cannot find their CORBA.py without setting the PYTHONPATH or am I wrong? Setting the PYTHONPATH is not what users should have to do. Renaming one of the files would break application source code. Maybe one could rename CORBA.py to omniORBpy.py or PyORBit.py and do either import PyORBit as CORBA or import omniORBpy as CORBA That would break only one line of the application source code. A symbolic link from either omniORBpy.py or PyORBit.py to CORBA.py could be provide for people who don't care. After all this is standard CORBA, if I don't use e.g. omniINSPOA, why should I care? Cheers! See Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=202205 Providing a module called CORBA is part of the standard Python CORBA mapping: http://www.omg.org/cgi-bin/doc?formal/02-09-07 Before version 1.99.5, pyorbit just created a CORBA module as a side effect of importing the ORBit module. It now provides a dummy CORBA.py that will initialise pyorbit, to better follow the spec. Do any of the Python ORBs in Debian coexist? The standard language mapping doesn't address this problem at all. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [omniORB] Re: [pygtk] Conflicting omniORBpy and PyORBit
On 01/08/03 21:13, Duncan Grisby wrote: omniORB's CORBA module really lives in omniORB.CORBA, so you can do from omniORB import CORBA instead of just import CORBA. I believe Fnorb does the same thing, so it should be considered a de-facto standard. It would be good if pyorbit supported the same model. The standard Python mapping says An IDL module is mapped into a Python module. Modules containing modules are mapped to packages (i.e., directories with an __init__ module containing all definitions excluding the nested modules). An implementation can chose to map toplevel definitions (including the module CORBA) to modules in an implementation defined package, to allow concurrent installations of different CORBA runtime libraries. In that case, the implementation must provide additional modules so that toplevel modules can be used without importing them from a package. So omniORB and Fnorb's behaviour is permitted if not exactly mandated. That is what PyORBit is doing now too, with the exception that once you import one of the PyORBit modules, the modules named CORBA and PortableServer will point at the PyORBit versions. The only issue for packagers is how to deal with the top-level CORBA (and PortableServer, etc.) modules. One solution would be to install them only if they are not already there from a different ORB. Yep, and that seems to be a problem for distributors wishing to package multiple Python ORBs. I am not sure what the right choice here is. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: pygtk-1.99.17
I've just uploaded a new release of pygtk. The corresponding gnome-python release isn't ready yet, but should be in a few days (I still need to review a few more of the bug reports). You can download it from one of: ftp://ftp.gtk.org/pub/gtk/python/v2.0/ http://ftp.gnome.org/pub/GNOME/sources/pygtk/1.99/ Here is a summary of some of the changes: * Threading support is compiled in by default now. It is necessary to call gtk.threads_init() in order to make use of threading though. There have been a number of fixes to the threading support too. * Fix up some problems with multiple definitions of global variables in gobject module, that was causing problems on Mac OS X. * Wrappers for many new APIs (John Finlay, Naofumi Yasufuku, Johan Dahlin and others). * Improvements to the code generator to give better error messages. * Some fixes to property APIs to work correctly on 64 bit systems, and to handle ATOM type properties. * Fix copyright headers on source files. For a full list, please consult bugzilla. There are a few issues with the pygtk's interactions with the Python garbage collector. Since pygtk makes use of reference loops in order to link the wrapper to the underlying GObject, the GC needs to run for wrapped GObjects to be freed. In most cases this isn't a problem, but in some cases it can act as a memory leak. To solve this problem, either add gc.collect() calls where needed, or reduce the garbage collection threshold using gc.set_threshold(). I would like feedback on what sort of thresholds for the GC work well with pygtk apps. This is likely to be one of the last 1.99.x releases of pygtk before 2.0. After that, I'll create a branch for 2.0 development and then focus on doing a quick 2.2 release (which should be a much shorter release cycle). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: pyorbit-1.99.6
I've uploaded a new release of pyorbit at: http://ftp.gnome.org/pub/GNOME/sources/pyorbit/1.99/ The changes in this release are: * clean up base class list when building client stubs. This is needed in order for the stubs to work with Python 2.3. * fix some possible segfaults if the argument names are missing in the IInterface structures, which occurs when using ORBit.load_file(). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] .defs and .override
On 1/08/2003 1:17 AM, Jon Willeke wrote: I'd like to use the VTE terminal widget, but the Python bindings need a little work. I need to learn a little bit about how the .defs and .override files interact. I've read Ross Burton's article http://www-106.ibm.com/developerworks/linux/library/l-wrap/ the FAQ entries, and scanned the archives. As I understand it, the h2def program creates the .defs file, which combines with the .override file to create a .c file. My first task is actually quite similar to the situation in the article. The vte_terminal_feed() and vte_terminal_feed_child() functions take a length parameter. The binding specifies an s data parameter and an i length parameter that I want to change to a single s# data parameter. I can do this, as the article suggests, by modifying vte.override. Should I modify vte.defs to reflect the deletion of the parameter, or leave it, in case another language binding needs it? It seems that the PyGTK .defs are heavily edited to match the Python interface. You shouldn't need to do anything to the definition in the .defs file if you add an implementation in the .override file. My second task is to support the vte_terminal_get_cursor_position() function. It appears in vte.defs, but not in the generated vte.c. Why was the function not generated? Anyway, I'd like to change the two output parameters to a tuple return value. I think I need to write a function in vte.override (and optionally modify vte.defs). The code generator only handles functions where it recognises all the argument types. Currently it doesn't handle things like (glong *). Is it an integer out argument? Is it an integer array in argument? We could probably extend the defs format to annotate arguments like this, but I haven't done so. You will need to add an entry to the .override file for this method. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] converting an Numeric array to a Pixbuf
On 1/08/2003 4:46 AM, Anthony Joseph Seward wrote: On Wed, 2003-07-30 at 11:45, Christian Reis wrote: On Tue, Jul 29, 2003 at 09:27:45AM +1200, Tim Evans wrote: Anthony Joseph Seward wrote: I am trying to figure out a simple way of converting a Numeric array to a gtk.gdk.Pixbuf without depending on PIL. [snip] Assuming that you have a (n,m,3) or (n,m,4) shape 'b' type array of RGB or RGBA values called 'data', you would do this: w,h = data.shape[:2] hasalpha = shape.shape[3] == 4 p = gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, hasalpha, 8, w, h) p.pixel_array[:] = data Added as FAQ 8.3, thanks: http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq08.003.htp Take care, The PyGTK reference at http://www.moeraki.com/pygtkreference/pygtk2reference/class-gdkpixbuf.html says Attributes pixel_array Read A numeric ... So according to the reference pixel_array is a read only attribute. Is the reference in error? You can't set the pixel_array attribute, but you can modify the existing value. Note however that modifying the pixel data of some GdkPixbufs will cause a segfault (ones that are backed by a const string, such as the stock icons). Pixbufs you create yourself are safe to modify though. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] TypeError: destroy() takes no arguments (1 given)
On 31/07/2003 1:27 AM, Dusausoy Bruno wrote: Hi, I'm quite new to pygtk and I have a problem. I've connected the clicked signal to a button and it should normally call exit_window.destroy() function. But Python gives me this error: TypeError: destroy() takes no arguments (1 given) The first argument passed to a signal handler is the object that the signal was emitted on. the destroy() method takes no arguments, so you get the exception. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] PyGtk+glade2+gettext
On 28/07/2003 8:48 PM, Alexandr V. Demeshko wrote: First of all sorry for my poor English. Could someone explain me how PyGtk, libglade and gettext should work together? When I call from Python glade.XML(mygladefile, domain=mydomain) wrapper code does not use domain, instead passes it into libglade2 by calling glade_xml_new. And then libglade2 uses mydomain internally. But, AFAIU gtk requires that all strings are in UTF-8 encoding. Therefore libglade2 should contain call to bind_textdomain_codeset(domain, UTF-8). But it does not. And, of course, strings are extracted not in UTF-8 but in system encoding and I have error messages like Bad UTF-8 string. There is no problem when I use libglade from C - I just put call to bind_textdomain_codeset in my own code. But Python AFAIK does not use libgettext. Instead it works with .mo files directly. So I can't invoke bind_textdomain_codeset from Python. I've solved this problem for me by patching libglade2 - I've just added call to bind_textdomain_codeset and all works OK. But I'm not sure that this is right solution. Why such call is absent even in fresh version of libglade2 - 2.0.1 ? I don't believe that nobody use such tool combination before me. Maybe I misunderstand something? So please help me. Thanks in advance. Does calling gtk.glade.bindtextdomain(mydomain, /path/to/locale/dir) help? This should set up the translation domain with the C level gettext library that libglade uses. It will also set the translation domain to return UTF-8 strings like GTK needs. This function is provided by the library for the benefit of pygtk programmers, since the functionality needed isn't exposed in the gettext or locale modules in Python 2.2. The reason libglade doesn't call bind_textdomain_codeset() itself is that this would be unexpected behaviour. In many applications, some of the GUI is done with libglade and other bits are constructed manually. Usually the same message catalog will hold strings for both these parts of the GUI. A call to bind_textdomain_codeset() will change a global setting for that message catalog, which will change both uses of the gettext() function call. By making the user set up the catalog, the programmer will have to think about how they want to setup the catalog (the same way they have to call bindtextdomain() to bind the translation domain to catalogs in a particular directory). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] connect_while_alive() in pygtk2?
On 29/07/2003 7:15 AM, John Ehresman wrote: I'm wondering if a connect_while_alive() method would be useful in pygtk 2? The connect_object() is often mentioned as a replacement method, but it doesn't invalidate the handler until the object is collected by Python's cyclic GC at some indeterminate time after the object is destroyed. This means that a handler can be invoked after the object passed to connect_object() is destroyed and extra code needs to be added to either check if the object is destroyed or signal disconnection needs to be done manually. The connect_object() method is actually closer to g_signal_connect_swapped(). I don't think the functions in glib had finalized the names when I was writing that part of pygtk. We've been using connect_while_alive() with a signal system that mimics gtk 1's signals and have found it quite helpful to implement temporary handlers as methods on objects that can be destroyed -- it simplifies thinking about the object lifecycle to have a standard way of implementing temporary objects. I want to move some of this code to classes derived from pygtk 2 objects and it would be easier with connect_while_alive() or some equivalent method. I haven't wrapped g_signal_connect_object(), but it should be possible to get a similar behaviour pretty easily with some code something like the following (untested): import weakref class DisconnectHandler: def __init__(self): self.object = None self.signal_id = -1 def disconnect(self, wref): if self.object: self.object.disconnect(self.signal_id) handler = DisconnectHandler() handler.object = object1 handler.signal_id = object1.connect(foo, callback, weakref.ref(object2, handler.disconnect)) James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome.ui in SuSE Linux 8.2
Jon Willeke wrote: Sorry for not replying to the original message, but I only just subscribed. I was just looking into this, myself. I installed SuSE Linux 8.2 Personal, then installed a bunch of packages from mirror sites. I usually use Red Hat, so I'm a little out of my element. If you try to rebuild the python-gnome package, you'll get a message like this: The following modules will NOT be built: gnome.ui bonobo bonobo.activation bonobo.ui gnome.applet nautilus Note: PyORBit 1.99.4 or later is required by bonobo, gnomeui and nautilus bindings. It seems that SuSE doesn't ship PyORBit. The python-orbit-1.99.0 package is actually ORBit-Python 0.3.1. The python-orbit-1.99.0 is the port of orbit-python to ORBit2. Modern versions of gnome-python require PyORBit instead. If SuSE doesn't come with a PyORBit package, you will need to create one. The spec file included with pyorbit is fairly up to date, so you could use that as a starting point. I'm trying to rebuild the python-gnome package with gnome.ui support, but it's slow going. The spec files and configure scripts miss a lot of dependencies, so I have to decipher error messages from make and cc. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] segfault in gtk.glade.XML
Don Allingham wrote: I've been attempting to port pygtk-1.99.14 and gnome-python-1.99.14 to SuSE 8.2 because the packages SuSE shipped are rather broken (built without gnome.ui). I've been able to build the packages, but when I run my application, I get a segfault in the glade_xml_new call. At this point, I'm kind of stuck. I have a backtrace from gdb. If anyone can provide some insight, I'd appreciate it. (gdb) backtrace #0 0x40f9436e in gnome_app_get_type () from /opt/gnome2/lib/libgnomeui-2.so.0 #1 0x402d20e2 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #2 0x402bdc6f in g_object_constructor () from /usr/lib/libgobject-2.0.so.0 #3 0x402bd4ce in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #4 0x40b1d889 in glade_standard_build_widget () from /opt/gnome2/lib/libglade-2.0.so.0 #5 0x4121b52c in app_build () from /opt/gnome2/lib/libglade/2.0/libgnome.so #6 0x40b1df6b in glade_xml_build_widget () from /opt/gnome2/lib/libglade-2.0.so.0 #7 0x40b1cbba in glade_flags_from_string () from /opt/gnome2/lib/libglade-2.0.so.0 #8 0x40b1b023 in glade_xml_construct () from /opt/gnome2/lib/libglade-2.0.so.0 #9 0x40b1af7b in glade_xml_new () from /opt/gnome2/lib/libglade-2.0.so.0 #10 0x402af61a in _wrap_glade_xml_new (self=0x3, args=0x8545cbc, kwargs=0x0) at libglade.c:38 If there is no gnome.ui module, then it is not possible to initialise the libgnomeui library. libglade is not guaranteed to function if you do not initialise the libraries you use. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] segfault in gtk.glade.XML
Don Allingham wrote: On Thu, 2003-07-24 at 21:52, James Henstridge wrote: If there is no gnome.ui module, then it is not possible to initialise the libgnomeui library. libglade is not guaranteed to function if you do not initialise the libraries you use. I built the missing pyorbit (1.99.5) package, and rebuilt the gnome-python package so that it includes the uimodule.so library. Since the gtk interface is part of the pygtk2 package, I also rebuilt that package as well. Is there something else I could be missing? It is hard to tell from your stack trace. The stack trace has gnome_app_get_type() at the top of the stack. All this function does is call another function and return the result. This indicates that some stack frames are missing (probably because the libraries have been stripped, which most distributors do). I can't offer any suggestions here. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Caching list view/-model ?
Peter Schulte-Stracke wrote: Hi, I am in desparate need of a List/Tree widget that does *not* read the whole database / model, but only a portion of it, essentially what is displayed. This looks as an innocuous enough requirement, but I failed completely to get anything to work, or even to find a model implementation. The libgnomedb appears to contain something in this direction, however a.t.m. I am still searching for it :-) Anyway, it should not be that uncommon a requirement, because it is not uncommon to have large databases, and expensive per item processing. A minimum would be to disconnect the scrollbar from the listview, so that one could reflect the position in a data base of, say, 1 records in the scrollbar, but only display the first twenty records, say, at the beginning. Has anyone ever tried this? The reason why the text in every row is measured (which can take a while for a large model). However, you can set a fixed height for the text cells using the gtk.CellRendererText.set_fixed_height_from_font() method. It takes a single argument: the number of rows of text in the cell. That way it won't bother measuring the text to find the row height. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] busy-cursor? input_only gtk_window?
george young wrote:
[gtk-2.2.2, pygtk-1.99.16, python-2.3b2]
I want to briefly change my app's cursor to a 'watch' or some such while it's
thinking hard. I have a zillion widgets, so it seems like changing cursor
for one of them is not likely to be right. From the FAQ, entry 5.6:
http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq05.006.htp
I found a reference to:
http://www.daa.com.au/pipermail/pygtk/2000-October/000435.html
wherein it's explained how to create an input_only window overlaying
my entire app and change that window's cursor. Unfortunately, I can't get
this hack to work. It calls for:
gtk.gdk_window_new(gdk_window, attribs)
but I can't figure out how to get a new gdk window. Here's the code
[partially adjusted for gtk2]
gdk_window = my_gtkwindow.get_window()
attribs = { 'wmclass': gtk.gdk.INPUT_ONLY,
'window_type': gtk.gdk.WINDOW_CHILD,
'event_mask': 0,
'x': 0,
'y': 0,
'width': gtk.gdk.screen_width(),
'height': gtk.gdk.screen_height() }
cursor_win = gtk.gdk_window_new(gdk_window, attribs) ??
gdk_cursor = gtk.cursor_new(get.gdk.WATCH)
cursor_win.set_cursor(gdk_cursor)
cursor_win._show()
Am I completely off base here?
Note that if a window doesn't have a cursor set on it, then it will
inherit its parent window's cursor (remember that almost every widget
has a window, not just the toplevel gtk.Window).
So if you set the cursor on your toplevel gtk.Window, all the child
widgets will inherit it too.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: pyorbit-1.99.5
I have uploaded version 1.99.5 of PyORBit. I am doing this ahead of the pygtk and gnome-python releases so that there will be a tarball available that compiles with the ORBit tarballs found in the Gnome 2.3.x dev releases. Once ftp.gnome.org has synchronised, you will be able to download it from: http://ftp.gnome.org/pub/GNOME/sources/pyorbit/1.99/ It seems to have finished syncing on the Australian mirror though: http://public.ftp.planetmirror.com/pub/GNOME/sources/pyorbit/1.99/ The changes in this release include: * Work with latest HEAD branch (ORBit2 2.7.x). * allow importing of CORBA or PortableServer without first importing ORBit. This gives better compatibility with standard CORBA mapping. * None is not a valid string/wstring value. * accept strings for sequenceoctet. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] libglade + gettext
[EMAIL PROTECTED] wrote: Christian Reis wrote: On Fri, Jul 04, 2003 at 02:08:37PM +0100, [EMAIL PROTECTED] wrote: Also I'm wondering that since the gettext python module doesn't actually call any glibc functions, does this have any affect on libglade? I can't see where the textdomain() calls etc. are done for libglade. Isn't this in the FAQ? Python 2.3 will ship with a fixed version of gettext that does the standard glibc gettext setup; in the meantime, you'll need to use the intl package (the old version that Martin wrote) which is in C. It should compile just fine for any version of Python. feck another dependency... aha! I just noticed: gtk.glade.bindtextdomain() This should do the trick? Yes, that will do the right thing (it also sets the domain to use UTF-8 encoding, which is required for strings displayed by GTK. You can use the intltool program to extract strings from glade files (along with other files). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pygtk 1.99 on OS X
[EMAIL PROTECTED] wrote: has anyone been able to get PyGTK 1.99 to work on OS X? I have tried to compile it from source and I get this error: make all-recursive Making all in codegen make[2]: Nothing to be done for `all'. Making all in gtk /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -std=c9x -o _gtkmodule.la -rpath /usr/local/lib/python2.2/site-packages/gtk-2.0/gtk -module -avoid-version -export-symbols-regex init_gtk _gtkmodule_la-gtkmodule.lo _gtkmodule_la-gtkobject-support.lo _gtkmodule_la-gtk-types.lo _gtkmodule_la-pygtktreemodel.lo _gtkmodule_la-pygtkcellrenderer.lo _gtkmodule_la-gtk.lo _gtkmodule_la-gdk.lo -L/sw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv rm -fr .libs/_gtkmodule.la .libs/_gtkmodule.* .libs/_gtkmodule.* generating symbol list for `_gtkmodule.la' /usr/bin/nm -p _gtkmodule_la-gtkmodule.lo _gtkmodule_la-gtkobject-support.lo _gtkmodule_la-gtk-types.lo _gtkmodule_la-pygtktreemodel.lo _gtkmodule_la-pygtkcellrenderer.lo _gtkmodule_la-gtk.lo _gtkmodule_la-gdk.lo | sed -n -e 's/^.*[ ]\([BCDEGRST][BCDEGRST]*\)[ ][ ]*\(_\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* //' | sort | uniq .libs/_gtkmodule.exp egrep -e init_gtk .libs/_gtkmodule.exp .libs/_gtkmodule.expT mv -f .libs/_gtkmodule.expT .libs/_gtkmodule.exp gcc -r -keep_private_externs -nostdlib -o .libs/_gtkmodule.so-master.o _gtkmodule_la-gtkmodule.lo _gtkmodule_la-gtkobject-support.lo _gtkmodule_la-gtk-types.lo _gtkmodule_la-pygtktreemodel.lo _gtkmodule_la-pygtkcellrenderer.lo _gtkmodule_la-gtk.lo _gtkmodule_la-gdk.lo gcc -bundle -flat_namespace -undefined suppress -o ...libs/_gtkmodule.so .libs/_gtkmodule.so-master.o -L/sw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lc ld: multiple definitions of symbol __PyGObject_API _gtkmodule_la-gtkmodule.lo definition of __PyGObject_API in section (__DATA,__common) _gtkmodule_la-pygtktreemodel.lo definition of __PyGObject_API in section (__DATA,__common) _gtkmodule_la-pygtkcellrenderer.lo definition of __PyGObject_API in section (__DATA,__common) make[2]: *** [_gtkmodule.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I think I have fixed this problem in CVS now. It would be helpful if you could test this on your machine and report back on whether it fixes the problem for you. Try editing the gtk/pygtktreemodel.c and gtk/pygtkcellrenderer.c files, and remove the line `#include pygobject.h' in each file. After the change, pygtk should compile and link correctly. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] catching a window resizew event in pygtk2
Jean-Baptiste Cazier wrote: Sæl ! I am porting my code from gtk1 to GTk2, ie pygtk 0.6 to 1.99 (quite painful btw) I am stuck with the resizing manually of the window : everytime I resize the I want to update the drawing area it contains I used to connect to size_allocate signal in pygtk 0.6 window.connect(size_allocate,self.area_resize) But now this has the effect to call self_area_resize constantly So I changed to configure_event, to only call area_resize after changes in sizes, window.connect(configure_event,self.area_resize) But now the size allocation is not up-to date when I try to read it. What is the correct signal to use in order to perform an operation based on the size of the window when it is resizing Is there any more simpler way to catch the event that the window size is being changed by the mouse and obtain the new size ? Connecting to the size_allocate is the right thing to do. The new allocation should be passed as an argument to your handler. Eg: def area_size(self, widget, allocation): print allocation.width, 'x', allocation.height It shouldn't result in an infinite loop unless you are triggering a resize from your size_allocate handler (which would be a very bad thing to do). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: pygtk thread support bug
Elliot Lee wrote:
On Wed, 25 Jun 2003, Elliot Lee wrote:
The problem is that pygdk_block_threads assumes that an accompanying
pygdk_unblock_threads has previously been called, when in fact it hasn't.
This can happen in situations when a thread calls a non-thread-wrapped gtk
function that emits a signal (e.g. gtk_entry_set_text()), and that signal
is connected to a python function.
The attached patch seems to fix this particular problem.
On a related note, pygdk_{block,unblock}_threads should really call
gdk_threads_{leave,enter} for sanity's sake.
This still is an issue - I can't just put the calls into
pygdk_{block,unblock}_threads.
Thanks for looking into this. To be honest, I haven't really put that
much work into the threading support in pygtk HEAD. Most of the work
has been in the form of patches from people actually writing threaded
pygtk programs.
Eventually I want to see if it is possible to rip out half of the
threading hacks in pygtk and make use of the new PyGILState_Ensure() and
PyGILState_Release() functions that are in Python 2.3. These
essentially turn the global interpreter lock into a recursive lock.
Since these calls are at the Python level, a lot of the hacks disapear
and pygtk should work better with unrelated modules that happen to be
thread aware. This changes the wrapper for most callbacks to:
PyGILState_STATE state = PyGILState_Ensure();
/* do stuff */
PyGILState_Release(state);
Things like the gtk_main() wrapper can change to use the standard
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS pair.
Of course, I want to keep Python 2.2 compat for pygtk-2.0, so the
PyGILState changes will have to happen after branching.
For 2.0, it is probably a good idea to apply your patch, since it seems
to fix some problems and looks basically correct. It would be good to
hear what some other people think about the patch though (some of the
Ximian guys in particular, who have done some work with the threading
code recently).
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pygtk 1.99 on OS X
Jade Meskill wrote: On 6/30/03 10:29 PM, James Henstridge [EMAIL PROTECTED] wrote: --snip-- I think I have fixed this problem in CVS now. It would be helpful if you could test this on your machine and report back on whether it fixes the problem for you. Try editing the gtk/pygtktreemodel.c and gtk/pygtkcellrenderer.c files, and remove the line `#include pygobject.h' in each file. After the change, pygtk should compile and link correctly. James. gcc -r -keep_private_externs -nostdlib -o .libs/gobjectmodule.so-master.o gobjectmodule.lo pygtype.lo pygobject.lo pygboxed.lo gcc -bundle -flat_namespace -undefined suppress -o .libs/gobjectmodule.so .libs/gobjectmodule.so-master.o -L/sw/lib -lgobject-2.0 -lglib-2.0 -lintl -liconv -lc ld: multiple definitions of symbol _PY_TYPE_OBJECT gobjectmodule.lo definition of _PY_TYPE_OBJECT in section (__DATA,__data) pygtype.lo definition of _PY_TYPE_OBJECT in section (__DATA,__common) pygobject.lo definition of _PY_TYPE_OBJECT in section (__DATA,__common) pygboxed.lo definition of _PY_TYPE_OBJECT in section (__DATA,__common) make[2]: *** [gobjectmodule.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Arrgh. That's the other related problem I fixed since the 1.99.16 release. I believe what is in CVS should compile and run on Mac OS X now. If you don't want to use CVS, I think the other remaining change is to edit pygobject-private.h and change the line GType PY_TYPE_OBJECT to extern GType PY_TYPE_OBJECT. Thanks for the bug report though. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Adding an interface to a python-derived class
Austin Henry wrote: Ok, this could be a weird one (or maybe not, I haven't been reading this list long enough to know what's weird around here ;) I am trying to implement a custom TreeCellRenderer which displays text, and when edited brings up a combo box subclass that I've written in Python. This combo box does auto-completion from a set of values pulled from a database stored in a gtk.ListStore. Now, I have the cell renderer working happily (editing supplied by a gtk.Entry), and the DBCombo working happily too. The problem seems to be convincing the TreeView widget that it would like to use the DBCombo as the editing widget. Buried deep in the Gtk code (gtktreeviewcolumn.c, line 2606) is the following bit of code g_return_val_if_fail (GTK_IS_CELL_EDITABLE (*editable_widget), FALSE); which is on the code path that is followed when you ask to edit a TreeView's Cell. That code basically means that I can't just implement the interface in python, and have the calls be made with no one the wiser. I tried to declare my DBCombo like this: class DBCombo(gtk.Combo, gtk.CellEditable) but python complains: Traceback (most recent call last): File widgets.py, line 11, in ? class DBCombo(gtk.Combo, gtk.CellEditable): TypeError: multiple bases have instance lay-out conflict So, I went and read the C code for GtkEntry to see how officially adding the interface CellEditable to a GType is done. Turns out that the call is: g_type_add_interface_static(...) There's unfortunately no corresponding function in PyGtk. I'm at a loss. How should I go about adding the CellEditable interface to my little widget? I suppose I could write some C code that does the correct magic, then wrap that C code myself, but... It's not like I don't already have C code to compile in my project (BTW, I have a very primitive GtkHTML 3 wrapper if anyone should want it). Anyway, I'm rambling now. I'll stop. I've attached the code in question to this message. Astute readers of the list archives may recognise the origination of the MyCellRenderer code that I copied (and mangled) from http://www.mail-archive.com/[EMAIL PROTECTED]/msg05242.html GObject interfaces are not very language binding friendly on the implementation side as things are at the moment (at least, I haven't worked out a better way of handling things). There is no way of introspecting information about the interface, so it is impossible to do a generic interface wrapper (interfaces are essentially additional structures tacked onto the class that usually contain C function pointers). In the past, the support for interfaces has involved creating special purpose classes that implement the interface as a skeleton that calls methods of a related Python object. This doesn't give you the ability to add interfaces to random widgets, which is really what you want for things like GtkCellEditable :( Maybe I'll review things a bit after a pygtk-2.0 release (it is probably possible to do better than we are right now). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Cannot create GladeXML object
Haris Bogdanovic wrote: When I do gtk.glade.XML(filename.glade) I get the error Could not create GladeXML object. What is the problem here ? Is the file a valid glade file? If so, it should start with something like this: ?xml version=1.0 standalone=no? !--*- mode: xml -*-- !DOCTYPE glade-interface SYSTEM http://glade.gnome.org/glade-2.0.dtd; glade-interface ... If the DTD has been registered in the XML catalog, you should also be able to run it through xmllint to validate it against the DTD. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pygtk or py + tk ?
Jean-Baptiste Cazier wrote: Sæl ! I have been designing a couple of applications on my linux box based on python + gtk and they work just fine. But porting them to any Windows system is quite a pain because GTK is not straight forward to install on those platforms However, Tcl /Tk is very easy to install on both *nix and Windows platform. So why should I develop under gtk while I could use the more portable tk ? Coudl you please enlighten me with your pros and cons of both candidates or any third one Some of the reasons to choose GTK over Tk include: * GTK provides a larger range of standard widgets, so you are more likely to find a widget that does what you want. * GTK has full support for unicode and internationalised text (including BiDi). This fits in with Python's unicode support, which makes i18n a breeze. In right to left environments, the user interface of your app will even be flipped. * GTK has accessibility support through the ATK library. This integrates with the Gnome a11y tools. As many countries have laws about equal access or discrimination against disabilities, accessibility support may be required if providing a solution to governments. * Antialiased text. On X11, GTK uses the fontconfig and Xft libraries to provide client side font rendering, which results in much better quality, and can be faster than the old core X font system in some cases. * A PyGTK app will conform to your GTK theme, so will fit in well on a Gnome desktop. Apparently KDE will also set up a matching GTK theme for you, so your app should fit in well there as well. Through the standardisation efforts at freedesktop.org, your app should integrate better with either desktop as time goes on. * Tk apps generally look out of place on modern Unix desktops. I don't know if/when this situation will change. On top of this, I think PyGTK has a nicer API compared to Tkinter, but that is just an opinion. I suggest trying both out (make sure you try a 1.99.x version of PyGTK though, rather than the older 0.6.x versions). On the downside, documentation for PyGTK is not as extensive as Tkinter documentation. However, we have some reference documentation that has been generated from the C docs, and there are a number of tutorials available. Hope this helps, James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] how to attach a gtk.Layout to a gtk.Scrollbar
Lorenzo Gil Sánchez wrote: I read the pygtk2 tutorial[1] and have some problems with the Layout Container[2]. When i try to use a vertical scrollbar with my Layout container something weird happens: mylayout = gtk.Layout(None, None) myscrollbar - gtk.VScrollbar(None) adjust = mylayout.get_vadjustment() myscrollbar.set_adjustment(adjust) The thing is that if I click in the trough or if I drag the slider everything works but if I click in the scrollbar buttons nothing happens. Do I have to connect some signal in order to make it work? or is it a bug? The GtkLayout widget does not set the page_size property of its adjustments, so the scrollbars don't know what increment to scroll in. If you set this value, the scrollbar will work correctly. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] bug in the spinbutton?
Rob Brown-Bayliss wrote:
pygtk.require('2.0')
Is there a pygtk 2? I thought we were still doing the 1.99.x thing...
It refers to the platform version. You would still use
pygtk.require('2.0') when pygtk-2.2 is out, for instance.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] nasty ListStore(bool) bug?
george young wrote: [pygtk-1.99.15, gtk+-2.2.1, python 2.3.a1, x86 linux] I have used ls = ListStore(str, str, str) with success, but ls = ListStore(bool, str, str) fails with a nasty, misleading could not get typecode from object in a *subsequent* statement! If I change bool to gobject.TYPE_BOOLEAN, it works fine. Eeek, this took me a long while to debug! Are python type objects like str and bool not supposed to be used here? And why doesn't the traceback point to the appropriate offending statement? The problem with exception occuring in the subsequent function call has been fixed in more recent versions of pygtk (the constructor was returning NULL after raising the exception, when it should have been returning -1). As for using Python types to represent column types, the function that converts Python objects to GTypes does not handle bool (mostly because Python 2.2.x is the base requirement, and doesn't have a native boolean type). Making pygtk interpret bool as boolean sounds like a good idea though. The two options for implementing this are: 1. conditionally interpret PyBoolean_Type as G_TYPE_BOOLEAN if pygtk was compiled with Python 2.3. 2. look up bool in __builtins__, and treat that object as eqivalent to G_TYPE_BOOLEAN (bool will be a function on 2.2, and a type on = 2.3). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Python binding of Pango should accept 'None' as anargument.
Alif Wahid wrote: Hi, I'm one of the developers of GtkGLExt library on sourceforge, and we're providing a python binding to GtkGLExt (an OpenGL capability extension of Gtk). In the process of writing test programs we've come across a minor discrepancy between the Python binding of Pango and its C API. You see in Pango some functions are passed a NULL pointer to specify default behaviour. This doesn't seem to be the case in the Python binding, in other words we can't pass a None type object to achieve the same feat without generating unnecessary exceptions about the wrong type. In particular the method get_metrics(...) of a pango.Font derivative doesn't accept the None object and spews up a TypeError exception instead. On the other hand in the C API passing a NULL pointer to the same function simply means to do the default thing (that is to load metrics for the entire font, not language dependent). So as you can see Python binding should follow the same sort of Pango API conventions. I think it shouldn't be that difficult since as far as I and the other developer of GtkGLExt, Naofumi Yasufuku, can see all that's needed is to add '(null-ok) (default NULL)' in the argument specifications of the corresponding functions in pango.def file. We haven't tried this however, so we can be misleading. Anyway, keep up the great work with PyGtk. Cheers. Thanks for looking into this. Could you submit bugzilla reports for the cases where NULL arguments should be accepted but aren't? Go to http://bugzilla.gnome.org/ and file the bug reports. Use the gnome-python product for the bug reports. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] connect_after does not work for treeview
Maik Hertha wrote:
:: It sets the signal return value to the value returned by the last
:: handler. It then decides whether to continue the emission if the
return
:: value is False.
:: Most uses of stop_emit_by_name() can be converted to simply do
return
:: True now. You hardly ever need to manually stop the emission for
:: event
:: signals in GTK 2.x.
But, if the default handler do so, why I can have a
w.connect_after('button_press_event', cb ) and the signal is triggered
for middle and right button pressed signals an not for the left button
pressed signal (tested with a clist)?
Because the default handler for button_press_event on GtkCList claims to
have handled button-1 events, but not button-2 or button-3 events.
:: Why did we have to do it back in GTK 1.2?
::
:: Because 1.2 didn't use the above accumulator.
Hm, seems to me that some logic have to change if code is ported from
1.2 to 2.0. This makes the event propagation very hard to design. If I
want an action on a double-click at a (clist)row I have to do a lot of
extra work in 2.0. There are some other solutions?
Really? Can't you just use connect() and return True when a double
click is performed (event.type == gtk.gdk._2BUTTON_PRESS)?
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] GnomeFileEntry and non-ascii characters
Don Allingham wrote:
I'm using a GnomeFileEntry in a glade built interface. Any time I select
a file name with a non-ascii character in it (such as 'ä'), I get all
kinds of errors, and the full string is not displayed. Some of the
errors I get are:
Gtk-CRITICAL **: file gtktextbuffer.c: line 476 (gtk_text_buffer_emit_insert):
assertion `g_utf8_validate (text, len, NULL)' failed
WARNING **: Invalid UTF8 string passed to pango_layout_set_text()
Any ideas as to what is happening?
First of all, try running your program with the environment variable
G_BROKEN_FILENAMES defined to something:
export G_BROKEN_FILENAMES=1
python foo.py
That makes the g_filename_{from,to}_utf8 functions use the locale
codeset as the encoding for filenames. If things still don't work, it
is probably a bug in libgnomeui (which should be reported).
Of course, in the long term you should be using UTF-8 filenames ...
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Comments on the tutorial
Antoon Pardon wrote: Explain the difference between signals and events. As far I as a complete newbie understand the two are extremely similar to the point there is no reason to have both. Which makes it confusing to have them both without explanation about why having them both. Events are things sent to the application by the X server. Signals are a generic notification system used in GTK (and related libraries). GTK uses signals to notify your application when events come in. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] connect_after does not work for treeview
Christian Reis wrote:
Can the class handler be run multiple times, then, if both _LAST and
_FIRST are set, for instance?
Yes, but they seldom do (I am not sure if any of the signals in GTK do so).
What are signals with return types?
Integer, boolean, etc. The type of the value returned by the signal.
The signal framework imposes the restriction that signals with a return
value can't be RUN_FIRST only (so that connect and connect_after do
different things).
How does it work for signal emissions, and how does it differ from event
signals? I should write up a FAQ on this, the tutorial doesn't make it
nearly clear enough.
It is done with an accumulator (which most people never need to even
think about ...). An accumulator function is used to accumulate the
return values of all the handlers attached to the signal to give the
final return value of the signal emission. The one for GtkWidget's
event signals looks like this:
gboolean
_gtk_boolean_handled_accumulator (GSignalInvocationHint *ihint,
GValue*return_accu,
const GValue *handler_return,
gpointer dummy)
{
gboolean continue_emission;
gboolean signal_handled;
signal_handled = g_value_get_boolean (handler_return);
g_value_set_boolean (return_accu, signal_handled);
continue_emission = !signal_handled;
return continue_emission;
}
It sets the signal return value to the value returned by the last
handler. It then decides whether to continue the emission if the return
value is False.
Most uses of stop_emit_by_name() can be converted to simply do return
True now. You hardly ever need to manually stop the emission for event
signals in GTK 2.x.
Why did we have to do it back in GTK 1.2?
Because 1.2 didn't use the above accumulator.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Unsupported types
Yuri Vilmanis wrote: I've been using py-gtk for a little while now, and I have noticed one major deficiency: GTK+ types and structs which do not have a type feild cannot be imported by the py-gtk autogeneration script, rendering quite a few functions unusable. Off the top of my head, examples include GSList, PangoLayoutLine, PangoLayoutIter, and there are a large number of others specifically from the GTK+, ATK+ and Glib parts of GTK+. While this may not affect everybody, I need some of the advanced features which require these types. Any suggestions? Please file bug reports for the functionality you need. That will help prioritise the areas we work on. For things like GSList, you need some extra information about the argument (what are the values in the list? Who owns the list? Who owns the values in the list?), which often means a custom wrapper is needed. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] connect_after does not work for treeview
Christian Reis wrote: On Fri, Mar 21, 2003 at 10:31:13AM +0800, James Henstridge wrote: Stephen Kennedy wrote: Plain connect works fine, but the connect_after callback does not get called. Or am I doing something wrong? See attached example. For the standard widget event signals, a custom accumulator is set. When going through the list of handlers to call for the signal, the process goes like this: 1. call handler 2. if it returned True, skip the rest of the handlers in the list and return True 3. otherwise, continue to the next handler GtkTreeView handles button press events, so its handler will return True. If you have a handler further down the list, then it won't get called. How does connect/connect_after relate to the `position' of the callback in the list of handlers? Does connect() connect *before* the GtkTreeView's `default' signal handler (can I call it default?) and _after(), after? What about multiple connect()/_after()s? If this is true, then this exemplifies: The callback order is: 1. run the class handler if the G_SIGNAL_RUN_FIRST flag is set. 2. run all handlers connected with g_signal_connect() in the order they were connected. 3. run the class handler if the G_SIGNAL_RUN_LAST flag is set. 4. run all handlers connected with g_signal_connect_after() in the order they were connected. 5. run the class handler if the G_SIGNAL_RUN_CLEANUP flag is set Most signals only have the RUN_FIRST or the RUN_LAST flag set, and signals with return types are usually just RUN_LAST (such a signal can't have only RUN_FIRST set). Hence, all the *_event signals are RUN_LAST. My assumption is that if foo_event is emitted in the widget, these callbacks will be called in order, and that any return gtk.TRUE will stop the callback chain. Am I correct? Yes. That is what the accumulator for the event signals do (this isn't the default behaviour for signal emissions). One major confusion I note is when to use return TRUE and when to use stop_emit_by_name() inside the callback - when is one or the other to be used? Do we use stop_emit_by_name() to stop *other* emissions apart from the current (foo_event) one? Most uses of stop_emit_by_name() can be converted to simply do return True now. You hardly ever need to manually stop the emission for event signals in GTK 2.x. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
Michael McLay wrote: The Tkinter library in the standard Linux distribution is getting long in the tooth. It is in the standard distribution because it provides cross-platform portability and has a rich text widget. The rate of improvement in the Tk toolkit has slowed to a trickle and the marketshare of Tk continues to shrink. Is it time to look for a replacement that would be a comfortable fit within the standard Python library? I don't know. PyGTK is a fairly large extension compared to most other extensions distributed with Python (mostly due to the size of the GTK API). I don't know what the Python developers would think of something of its size. The other reservation I have is release frequency. PyGTK is still being improved with each release, and those releases are much closer together than Python releases. There are three major contenders in the cross-platform GUI race, PyGtk, wxPython and PyQT. Each of these options have strong Python support and a mature code base. Less mature technologies that could be considered include the anygui project and the IBM Eclipse library and IDE. The anygui project is very much in the early research stage, with a minimal set of widgets defined. It would be great as the standard GUI API because it would allow the user to select the underlying GUI toolkit at execution time. When anygui eventually matures it could be added to the standard library, alongside the Tkinter and whatever other GUI APIs find their way into the standard distribution. From a quick look at the anygui documentation, it doesn't seem to be a very interesting GUI programming API. It looks like it uses absolute positioning for pretty much everything, which is a big step backwards compared to the geometry management of GTK, Qt and Tk, etc. The IBM Eclipse GUI was written for Java, but the C language interface, which is a thin layer over native toolkit widgets, could be wrapped into a Python GUI package. The design goals described in the design methodology provide a well balanced tradeoff in Eclipse is to use the native widgets when they are available and build widgets that are missing from native components. This fixes the problems with the Java awt (lowest common denominator widgets) and Swing (draws all widgets using Java). While Eclipse looks attractive, it is not as mature as the other options and it has not gathered a strong following of Python users. In addition to the GUI, I think it is important to have a GUI Builder available for the GUI toolkit. This has always been a weakness of Tkinter and I think it has hurt the growth of Python that we did not have a visual basic like GUI interface for building applications. By selecting PyGtk, and including the libglade library, it would be easy to create an integrated development environment based on Glade and the XML glade files that it generates. Quality tools such as these need to be part of the standard distribution. If they are not then they cannot be counted on to be part of a Python installation. I have seen numerous programs written in Tkinter simply because the author did not want to impose the requirement of installing an alternative GUI library. Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package is probably the closest match to the Python coding philosophy and style. It is also closer to the Tkinter programming model. PyGtk is written in C and the widget library seems to be a superset of Tkinter. I also think James has done an excellent job of making use of the Python 2.2 API for creating classes. The library has a very natural Python feel to it. Would others on this list care to comment on this assertion? The case for adding a new GUI to the standard library will need to address the sticky point of why the GUI toolkit is appropriate for the standard Python library. An argument often posed for using wxPython instead of PyGtk has been that wxPython used native widgets to render applications on platforms. This allows the GUI themes of the native toolkit to be transparently used in the application. This helps make the application look closer to the users expectations for the GUI. There is merit to this argument, but the tradeoff is a more bloated GUI toolkit that places abstraction layers inbetween a native toolkit and the GUI API. It looks like some work has been done on making the native themes for Windows and Mac OS X [1] work under Gtk+ [2]. Is anyone on this list experienced with using these capabilities? Do they mitigate the theme problems of Gtk+, or will applications still need to manually adjust the themes to match the theme of their desktop? The gtk-osx project you mention here is not really relevant to PyGTK in its current form. Since the developers main aim was to have a toolkit to run filmgimp on OS X, they decided to port GTK 1.2. This means that the port is can not be used to port any modern GTK application to OS X (remember
Re: [pygtk] VTK
George A. Dowding wrote: Any help would be appreciated. I am trying to comple pygtk from cvs with patches to use VTK. My current problem relate to the more general issue of compiling pygtk from source. I tried following the directions from here http://www.airs.com/ian/configure/configure_2.html#SEC10 Try running this: ./autogen.sh --prefix=/usr (or whatever prefix you want to install it into). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] ANNOUNCE: pygtk-1.99.16, pyorbit-1.99.4 and gnome-python-1.99.16
I have just uploaded a new set of pygtk, pyorbit and gnome-python releases. You can get them here: ftp://ftp.gtk.org/pub/gtk/python/v2.0/pygtk-1.99.16.tar.gz http://ftp.gnome.org/pub/GNOME/sources/pygtk/1.99/pygtk-1.99.16.tar.gz http://ftp.gnome.org/pub/GNOME/sources/pyorbit/1.99/pyorbit-1.99.4.tar.gz http://ftp.gnome.org/pub/GNOME/sources/gnome-python/1.99/gnome-python-1.99.16.tar.gz Here is a summary of the changes in this new release: PyGTK: * various new functions wrapped. * More threding fixes (Jon Trowbridge) * Reworking of the single instance per GObject code to work better with the Python cycle GC. * more updates to the simplified Python tree model API. * fix error handling in constructors for GtkTreeStore and GtkListStore. * add some inline comments for the APIs for extending pygtk to handle other widget sets. PyORBit: * support generation of stubs at runtime from IDL files using the imodule service found in ORBit2 2.6. * fix marshalling of long long and unsigned long long values. * fix compilation problem with ORBit2 HEAD branch (2.7.x). gnome-python: * many updates to the gnome-print bindings by Gustavo * better handling of CORBA types as signal arguments for bonobo bindings. * crash fix in the gnome.applet module (Johan) Bugs can be reported at http://bugzilla.gnome.org/ or brought up on the mailing list. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] connect_after does not work for treeview
Maik Hertha wrote: The difference to the 0.6.x code is, that I include the return statements in the functions with FALSE. If I do a signal_connect I get a deadlock situation with the dialog window which is called via Set_options_button.clicked(). Could it be a bug anyway ? The behaviour was implemented in GTK 2.0. It is different to GTK 1.2, but it is not considered a bug. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] connect_after does not work for treeview
Stephen Kennedy wrote: Plain connect works fine, but the connect_after callback does not get called. Or am I doing something wrong? See attached example. No bug here. For the standard widget event signals, a custom accumulator is set. When going through the list of handlers to call for the signal, the process goes like this: 1. call handler 2. if it returned True, skip the rest of the handlers in the list and return True 3. otherwise, continue to the next handler GtkTreeView handles button press events, so its handler will return True. If you have a handler further down the list, then it won't get called. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Changing a SpinButton's maximum value
Greg Ward wrote: Hi all -- I'm trying to create a SpinButton whose maximum value can be changed later. (Actually, the value of one SpinButton becomes the maximum of another, but that's not really relevant.) From reading the GTK+ tutorial, it looks as though this: from gtk import * w = GtkWindow(WINDOW_TOPLEVEL) adj = GtkAdjustment(1, 1, 99, 1, 1, 1) sb = GtkSpinButton(adj, 1, 0) sb.set_wrap(True) w.add(sb) adj2 = sb.get_adjustment() adj2.upper = 5 adj2.changed() print adj2.upper = %r % adj2.upper print sb.get_adjustment().upper = %r % sb.get_adjustment().upper w.signal_connect(destroy, mainquit) w.show_all() mainloop() should work, ie. the SpinButton should have a max of 5 when it's actually rendered. But it doesn't; the damn thing always has a max of 99, and I cannot figure out any sequence of adj2.changed(), sb.set_adjustment(), sb.update(), etc. that make it work as expected. For pygtk-1.99.x, the above style of updating the adjustment will work (assigning to the attribute). I hadn't implemented that in the 0.6.x series which is why it isn't working. However, the following method will work: adjustment.set_all(value, lower, upper, step_increment, page_increment, page_size) This is a pygtk specific API that will set all the attributes and call changed() for you. Of course, if you are writing new code, I strongly recommend using the newer versions of pygtk. GTK 1.2 is obsolete (there have already been two more stable series released since GTK 1.2: 2.0.x and 2.2.x). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Changing a SpinButton's maximum value
Greg Ward wrote: On 21 March 2003, James Henstridge said: Of course, if you are writing new code, I strongly recommend using the newer versions of pygtk. GTK 1.2 is obsolete (there have already been two more stable series released since GTK 1.2: 2.0.x and 2.2.x). Never mind that, GTK+ 2.0 just *looks* so much prettier. Now that I've discovered the right Debian package name for pygtk 1.99, I'm on the road to GTK+ 2.0. Alas, I built my interface with glade 0.6, and to my shock and amazement, glade 1.1 cannot read the project file! I couldn't find any mention of this problem anywhere, or of any standalone conversion utilities. I've asked for help on the glade-users list, but if anyone here has a tip, I'm all ears. There is a program included with libglade 2.0.x called libglade-convert that will do a pretty good job at converting the interface file to the new format. You should be able to edit the file in glade 1.1 after that. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Is there a guide how to program with pygtk?
David M. Cook wrote: On Tue, Dec 21, 2004 at 10:29:17PM -0200, Michel wrote: Hi Guys! I want to program in pygtk but I didn't find a guide, I read the faq and some examples but I want a reference guide... See FAQ item 1.7. Tell me if the pygtk is very unlike tkinter... I used tkinter to make guis and I think it's easy to work, is the pygtk so easy? pygtk is not as easy as tkinter... This is quite subjective :) PyGTK is about as easy as Tkinter for many simple tasks. For many moderate tasks, PyGTK can be a lot easier, as it contains more widgets (which in Tkinter you may need to reimplement). In my opinion, it is also better for difficult tasks :) James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Specifying an alternate color for odd numbered rows inTreeview
CRIBBSJ wrote:
I searched the archives, docs, and faq, but did not find the answer to this.
I am using treeview and liststore in an application. I have 'rules-hint'
turned on so that I am getting every other row in a different color. The
only problem is that the alternate color is a dull gray. I want to be able
to pick a different color like 'light blue'. I read in the docs that the
treeview has a style property called 'odd-number-rows' or something like
that. I tried every which way I could think of to set that property to a
gdkcolor, but it didn't work.
I'm pretty sure I could set this in my default rc file, but I couldn't
figure out the proper syntax for that either.
Any help would be greatly appreciated.
These settings can be changed in the gtkrc file. Note however that the
settings are intended for theme authors. If you set them explicitly for
your app, then your app would not fit in with the rest of the apps on
the desktop (the user might have specifically picked their theme because
they like that shade of grey). Note also that set_rules_hint() should
only be used for multi-column lists/trees where it will actually help
the user line up items in the row.
The gtkrc directives would look something like this:
style mystyle {
GtkTreeView::even_row_color =
GtkTreeView::odd_row_color =
}
You could use this to create a custom theme if you don't like how trees
display on your desktop.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk/pango string width problem: needs realize?
george young wrote:
[gtk+-2.2.1, pygtk-1.99.15, python 2.3a1]
I want to have an Entry change it's width to exactly track the
width of it's string contents. What I have *almost* works: after
I click on the widget and change something, it's fine. But initially
only part of the string is shown. Here's my code:
import gtk, pango
def ch_cb(w):
l = w.get_layout()
w.set_size_request((2 * w.get_layout_offsets()[0]) +
l.get_pixel_size()[0], -1)
top = gtk.Window(gtk.WINDOW_TOPLEVEL)
top.show()
e = gtk.Entry()
e.modify_font(pango.FontDescription('monospace'))
e.connect('changed', ch_cb)
e.show()
h=gtk.HBox()
top.add(h)
h.show()
e.set_text('the rain in spain stays')
h.pack_start(e,gtk.TRUE, gtk.FALSE, 0)
gtk.mainloop()
If the set_text line is put *after* the pack_start, then it
works properly. It seems as if the font width info is incorrect
until there is a complete chain of parent widgets up to the top.
I tried e.connect(realize,ch_cb), likewise with map and show
but to no avail. Is there some event I can connect to that would
happen late enough? Changing the font via gtkrc file
fails the same.
Style information is not calculated until the widget is anchored in the
widget tree. Until that happens, it can't know which styles from the
gtkrc file will apply (which may even affect the size of the entry
widget). You could try ignoring text changes while not realised, but
explicitly make the change from a realize handler.
Of course, the fact that this is so hard to do may indicate that it
isn't a good idea :) No other GTK applications do this, so your app
will look and behave differently to them all. Is that intended?
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] GtkTree{Model,Store} API additions in PyGTK.
This email describes the API additions that have been made to the
GtkTreeStore and GtkListStore classes in PyGTK in order to make them
more friendly to Python programmers. It is cc'd to the GTK# mailing
list at the request of one of the developers, but should mainly be
useful to Python programmers.
The description below is of what is currently in CVS. Most of the
functionality is in released versions, but some is recent.
There is no special wrapper for GtkTreePaths in PyGTK. Since a tree
path is really just an ordered list of indices, we represent them as
tuples of integers. In places where a GtkTreePath must be passed to
GTK, the following Python types will be accepted:
* strings: these get parsed by gtk_tree_path_new_from_string(). The
syntax is like 1:2:3:4.
* tuples of integers: as described above.
* integers: treated as a path of length one. Useful for
GtkListStores, as will become apparent.
By accepting integers as length-one tree paths, the user can just pass
in integers for GtkListStore methods, and think of them as row numbers.
They don't even need to think about paths.
Sequence/mapping behaviour: GtkTreeStore and GtkListStore implement the
__getitem__/__setitem__ API. You pass in a tree path as a key and get a
row object as the value. The row object basically combines a pointer
to the tree model and a GtkTreeIter for the row. It in turn looks like
a sequence -- one item per column in the model. You can get and set
columns in the row through this interface. The best way to explain this
is with some examples:
liststore = gtk.ListStore(str, str, int) # create list store
treestore = gtk.TreeStore(int, str, str) # and a tree store
... # fill in some rows
row = liststore[42] # get the row object for the 42nd row in the list
print row[2] # print 3rd column in row
print liststore[42][2] # or the two operations can be combined
# print first column of first child of the second top level node
print treestore[1,0][0]
# assignment works too
liststore[42][2] = 42
# you can also assign to the entire row in one go
treestore[1,0] = (5, 'foo', 'bar')
# or delete rows
del liststore[42]
If you have a GtkTreeIter for a row, you can also get the corresponding
row object for it with store[iter]. As well as looking like a
sequence, row objects have the following attributes:
* next: next sibling row object
* parent: parent row object
* model: the GtkTreeModel for this row
* path: the tree path of this row.
* iter: a GtkTreeIter pointing at this row.
Iteration: tree and list stores implement the Python iteration API.
This means that you can easily do things like print the value of the
first column for every row in a list store:
for row in liststore:
print row[0]
For tree stores, this only iterates over the toplevel of the tree. Each
row object has an iterchildren() method that can be used to iterate over
the child rows if desired (if you directly iterate over the row, you
will get the columns).
Extra optional argument on append/prepend/insert methods: I added an
additional optional argument to the insert, insert_before, insert_after,
prepend and append methods. If passed, the additional argument is
interpreted as a sequence of values of the columns in the new row. For
instance:
liststore.append(('foo', 'bar', 42))
This makes the list store feel a lot more like the standard Python list
objects.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] GObject reference handling
James Henstridge wrote: If anyone on the list has experience with the Python cycle GC, I would appreciate it if you could read over my reasoning, and hopefully spot any obvious mistakes. If I can get this working, I would like to apply it for the next pygtk release. Okay. I found the problem (it was a fairly simple problem). There is a fixed patch on bug 92955 now. The main difference in behaviour with this change is that GObject subclasses with __del__ methods will not get released. This behaviour comes from the cycle GC, since __del__ methods aren't usually written to function correctly when the instance dictionary has been cleared, for instance. Is this likely to be a problem for anyone? In my opinion, the gains from such a change outweigh the losses but I would like to hear other people's point of view if they disagree. The patch is available here: http://bugzilla.gnome.org/showattachment.cgi?attach_id=14812 James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] TreeList check boxes
Jay Graves wrote:
I am trying to have a TreeList with check boxes in the TreeViewColumn
If you don't know what I mean look at the gconf-editor and click around,
you will see one.
Right now I have:
self.keyListModel = gtk.ListStore(gobject.TYPE_STRING, gobject.TYPE_STRING,
gobject.TYPE_BOOLEAN)
.
self.keyListModel.set_value(iter,0,eachKey)
self.keyListModel.set_value(iter,1,self.keys.get(eachKey))
self.keyListModel.set_value(iter,2,False)
.
self.col = gtk.TreeViewColumn(key id,gtk.CellRendererText(),text=0)
self.col1 = gtk.TreeViewColumn(name,gtk.CellRendererText(),text=1)
self.col2 = gtk.TreeViewColumn(allow,gtk.CellRendererText())
I have tried putting text=2 in the col2 gtkTreeViewColumn but that just
displays 'False' in the TreeView
Am I on the right track or way off base?
Does anyone know how to achieve this?
You want to use a gtk.CellRendererToggle() instead of a
CellRendererText(). You want to map active=2 to make the toggle display
the state of the 3rd column. If you want the toggle to update the state
of the tree, you will need to connect to the cell renderer's toggled
signal. Your callback might look something like this:
def cell_toggled(cell, path_string, model):
path = tuple([int(i) for i in path_string.split(':')])
row = model[path]
row[2] = not row[2]
model.row_changed(path, row.iter)
(I haven't tested the above, but it is approximately what it should look
like).
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pyorbit-1.99.3/configure
Bowie Owens wrote: Hi, I had some trouble with the configure script that comes with pyorbit on our Alpha at work. The problem is ./libtool --config reports export_dynamic_flag_spec=. This causes sed to exit with an error in the following line. PYORBIT_LIBS=`echo $PYORBIT_LIBS | sed -e s/$export_dynamic//` So PYORBIT_LIBS ends up being empty, which causes trouble later on. Wrapping an if around the above statement seems to fix the problem. if test x$export_dynamic != x; then PYORBIT_LIBS=`echo $PYORBIT_LIBS | sed -e s/$export_dynamic//` fi PS Thanks for the great python ORBit bindings. Python is an excellent language for experimenting at the client side and pyorbit seems to work quite well. Thanks for the bug report. That problem has been fixed in CVS, so shouldn't bother you in the next PyORBit release. The other feature people might like in the next PyORBit release is the ability to load up IDL files at runtime (as an alternative to typelibs). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] GObject reference handling
I have recently been looking into the problem of disapearing member variables on GObject wrappers: http://bugzilla.gnome.org/show_bug.cgi?id=92955 I have a fairly good idea of why this happens: the cycle GC system thinks that the only references held on the wrapper are part of cycles, as it doesn't know about the hack in pygtk to resurrect the wrapper, so asks the instance dictionary to clear itself. I believe the way to solve this problem is to get rid of the hacks in pygtk :) I outline my proposed solution in the comment on the bug dated 2003-03-05 06:16. I also have an initial patch to implement this solution. Unfortunately, things aren't quite working correctly. The garbage collector never seems to call the GObject wrapper's tp_clear() method, so the wrapper (and GObject end up getting leaked). If anyone on the list has experience with the Python cycle GC, I would appreciate it if you could read over my reasoning, and hopefully spot any obvious mistakes. If I can get this working, I would like to apply it for the next pygtk release. Thanks, James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] fatal problem with import gnome.ui
Rob Brown-Bayliss wrote:
Hello, I recently installed redhat 8 (fresh install - not upgrade) and
then installed the gtk and gnome bindings (1.99.15 and pyorbin 1.99.3)
Now when I run an app that previously worked with the 7.2 install of rh
I get:
Fatal Python error: could not import bonobo.ui
Aborted
so I go interactive:
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type help, copyright, credits or license for more information.
import bonobo.ui
Traceback (most recent call last):
File stdin, line 1, in ?
File /usr/lib/python2.2/site-packages/gtk-2.0/bonobo/__init__.py,
line 7, in ?
ORBit.load_typelib('Bonobo')
RuntimeError: could not load typelib
import bonobo
import bonobo.ui
Now I don't actually import bonobo or bonobo.ui in my app, so I try
this:
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type help, copyright, credits or license for more information.
import gnome.ui
Fatal Python error: could not import bonobo.ui
Aborted
You will need to get an updated version of the libbonobo package. The
one that came with RH8 was missing a few files (the Bonobo typelib is
the important one here).
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] tree/list widget question
[EMAIL PROTECTED] wrote: I have a few problems with the list/tree widgets. Before I forget, here is the version info python Python 2.2.2 (#1, Jan 15 2003, 01:45:57) [GCC 3.2.1 20021207 (Red Hat Linux 8.0 3.2.1-2)] on linux2 import gtk print gtk.gtk_version (2, 2, 0) My first problem is with creating a ListStore with a dynamic numbers of columns. The best thing I could come up with so far is this: args = [gobject.TYPE_PYOBJECT] + ([gobject.TYPE_STRING] * len(titles)) model = apply( gtk.ListStore, args) Is there a better way avoiding the use of apply? Try model = gtk.ListStore(object, *([str]*len(titles))) This uses the *args syntax introduced in Python 2.0. Second, I am trying to have different background colors for different row using the first column of of my model to hold the actual color: for index in range(len(titles)): renderer = gtk.CellRendererText() column = gtk.TreeViewColumn(titles[index], renderer, text=index+1) column.add_attribute(renderer,background-gdk,0) view.append_column(column) the values for the rows including the color rows are set here: def redraw_events(self): self._model.clear() for event in self._events: if event.get_type() == TYPE_REGULAR: fields = [self._color_normal] else: fields = [self._color_active] fields += self._viewer(event) iter = self._model.append() for i in range(len(fields)): self._model.set_value(iter, i, fields[i]) return When running the program I get a lot of warnings like: GLib-GObject-WARNING **: unable to set property `background-gdk' of type `GdkColor' from value of type `PyObject' And, of course, my color settings are ignored. How do I work around this? Make the first column type gtk.gdk.Color. Alternatively, you can make the first column a string column holding the colour name, and map background to the first column, rather than background-gdk. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Strange change in event behavior in PyGTK2
Bernhard Herzog wrote: While porting Sketch to PyGTK2 I came across a strange change in the behavior of event objects in PyGTK2. The sample program below connects to the button press, motion and release events and stores the event object of the button_press event in an instance variable. In the motion event handler the coordinates of the mouse in the saved press event are always the same as the coordinates returned by get_pointer()! I haven't followed all the C code yet, but it seems as though PyGTK reuses the same underlying gdk event struct. Storing an explicit copy of the press event works around the problem. This is unfortunately unavoidable. The event objects (and any other boxed types for that matter) passed to the signal handle do no actually own the underlying C object now (they use the same pointer as in the GValue for the argument). The object is not guaranteed to be valid after the signal handler has finished running. Copying the event object is the correct way to handle this case. The reason for this change is that some GTK APIs will not function correctly if the boxed value is copied (since they require modifying the original copy of the boxed object, which sort of violates the rules for boxed types, but is the way things turned out). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Strange change in event behavior in PyGTK2
Christian Reis wrote: Would it be correct, according to Python semantics, to pre-copy of the object then? And if so, what are the drawbacks of implementing things that way? The drawback is that a number of GTK APIs simply don't work if you copy the boxed arguments. We used to copy boxed arguments (which has the benefit that it is safe to keep references to boxed objects passed as arguments to signals), but we changed it for this reason. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] select_cursor_row
Anthony Tekatch wrote: GTK used to have a CList widget with a select_row signal that was sent when a row was click upon. GTK2 only has a TreeView select_cursor_row signal which I cannot get to do anything. I have had to use the cursor_changed signal which emits two signal on the first click because no row was initially selected. What TreeView signal can I use to replace select_row? Is there a place that I can read a description about what causes each signal to be emitted? With the new tree widget, the selection is abstracted as a separate object, which can be obtained with: selection = treeview.get_selection() (I think the original reason for this was to allow two views of one model to share a selection). For single selection tree views, you can call selection.get_selected() to retrieve the selected row. For notification of changes to the selection, connect to the selection's changed signal. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Python and orbit server
Xavier Ordoquy wrote: Hi, I would like to know if there is an example of client/server using orbit and in full python. I'm trying to get bonobo server working but I'm failing in generating python from orbit-idl. Any pointer about it ? Currently you need to generate a typelib. There is an example of this in pyorbit/tests/c-inproc. I still need to add support for dynamically loading IDL at runtime. This will require ORBit 2.6.1 (the functionality was built but not installed in 2.6.0), so won't help you if you have the Gnome 2.0 version of ORBit (2.4.x) James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] GtkSourceView wrapped
Ahmad Baitalmal wrote: Christian, first of all, I appreciate your friendly attitude. Sometimes I just give up on working on a project just because I don't want to deal with the rude comments I get back. On Wed, 2003-01-22 at 02:46, Christian Reis wrote: Hey Ahmad, nice work. I'll let Johan have a look at the code, but just as a tip, next time try to work with CVS and patches (generated with cvs diff -urN from the pygtk module root). It makes it a *LOT* easier to integrate code (I won't be surprised if Johan can't do it and has to ask you for the CVS patch) and it's standard in OSS work too. K, so I got a fresh CVS gtksourceview (builds/installs perfectly), and a fresh CVS gnome-python/pygtk (also builds/installs perfectly). Then I added my wrapper files to gnome-python/pygtk/gtk/ and builds perfectly also. With the 1.99.14 tarball, I make install and my gtksourceviewmodule.* are installed to /usr/lib/python2.2/site-packages/gtk-2.0/gtk/ and I just import gtksourceview and I'm in business. The problem I'm having with the CVS version, it builds and make install works, and I see the gtksourceviewmodule.* files in /usr/lib/python2.2/site-packages/gtk-2.0/gtk/ but python can't import the gtksourceview module? It just says 'no module named gtksourceview' If you put gtksourceview.so in gtk/, you will need to import it as gtk.gtksourceview. Might this be the cause of your problem? Try running python with the -v switch if you still have troubles. It will print debug messages when importing modules, which might also help. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] PIL - PyGTK
Andreas Kostyrka wrote: Hi! Is there any easy and fast way to convert from PIL image objects to a pixbuf? Not that I know of. Note that the CVS version of pygtk might help. If you have numpy, you can now get a reference to a numpy multidimensional array representing the pixel data in the pixbuf (MxNx3 or MxNx4 depending on the presence of an alpha channel). You can use this to edit the pixels of an existing pixbuf. I have also added wrappers for the draw_rgb_image, draw_rgb_32_image and draw_gray_image methods of the GdkDrawable class (which is the abstract base for windows and pixmaps), so if you can convert your PIL image to a pixel data string or buffer object, you could use them to display the image. I still plan to implement something like the pygtk-0.6.x draw_array() method for drawing a numpy array to a drawable, and a way to create a pixbuf from a numpy array. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk.gdk.Image from a gtk.Image
Pablo Endres wrote:
How do I obtain a gtk.gdk.Image??
I'm trying to paint an image on a Drawing Area with DA.draw_image
I can't use a gtk.Image. Any ideas on another way of painting it or to obtain this object?
I checked the FAQ and the tutorial. Int the first there is nothing usefull and in the second the
method is for pygtk 0.6.x.
A gtk.gdk.Image is a client side raster image. A gtk.Image widget is
used to display raster images from a number of formats (a gtk.gdk.Image,
a gtk.gdk.Pixmap, a gtk.gdk.Pixbuf, a stock icon, or an image file). So
your question doesn't quite make sense.
If you want to load an image file and draw it to a gtk.DrawingArea, I
suggest creating a gtk.gdk.Pixbuf object, and rendering it to the
drawable. Something like this:
pixbuf = gtk.gdk.pixbuf_new_from_file('filename.png')
pixbuf.render_to_drawable(drawingarea.window, gc, src_x, src_y,
dest_x, dest_y, width, height, gtk.gdk.RGB_DITHER_NORMAL, 0, 0)
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Freezing a treeview
Jesse Pavel wrote: Hello, I'm using a TreeView to display a list backed by a ListStore, and make many changes to the store at one time: how do I freeze and thaw the view to speed up these actions? I've seen the freeze_notify/thaw_notify methods in GObject, and the freeze_child_notify/thaw_child_notify methods in GtkWidget, but am unsure what to use. There is no freeze/thaw routines for the new gtk tree widget. GtkTreeView pushes updates to an idle function which means that multiple updates will result in a single update to the view. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Changing fonts in pygtk 1.9.x
Pablo Endres wrote: I'm trying to change the font size in pygtk-1.9.xWin32 because the default is absolutly to big, but it is not described in the FAQ or tutorial. I tryed changinf the gtkrc file.. but it doesn't do a thing. Create a .gtkrc file (in your $HOME directory, or maybe the profile directory), with the following line: gtk-font-name = Arial 12 (that will set the default font to Arial 12pt). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
