RE: [pygtk] PyGTK+Thread problem (program freezes)
On Thu, 2003-08-07 at 12:22, [EMAIL PROTECTED] wrote: > I verified this by trying to write a PyGTK GUI in Red Hat 8 myself > and it would freeze until I removed the GUI stuff. The threading implementation that comes stock with Red Hat 8 has issues, and threaded apps seem to hang pretty regularly with it. Red Hat issued an errata to fix it, and with our threaded app we require the glibc errata as a packaging dependency to avoid the problems. As far as the rest of your email goes, the threading support in pygtk has come a long way since 1.99.14 or .15. I haven't seen any problems with it in a long while, and our app is a fairly complex threaded one (about 15k lines of python, another 1500 lines of C). Joe ___ 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
On Tue, 2003-07-01 at 04:41, James Henstridge wrote: > 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). The patch looks good to me and it worked fine in my limited testing. We snapshot HEAD pygtk, so I'm sure I'll be complaining loudly if it breaks anything. :) Joe ___ 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 applet and kde3
On Sun, 2003-06-29 at 09:49, John (J5) Palmieri wrote: > No, we switched from applets to the notification area. Applets only > wprk on the gnome panel, however applications which use the system > tray/notification area, work with the xemebed standard which will work > in KDE or GNOME. I don't know if there are any python bindings yet but > the specification is on freedesktop.org. There is a very simple binding in the rhn-applet as shipped in Red Hat 8.0 (and also probably 9). It is basically just a constructor which returns a GtkWidget. It's a terrible hack, doing an #include on a .c file, but it's probably the shortest path to getting something working. (And the notification area stuff is all still in libegg right now anyway) Grab the source RPM and look in the tarball. The relevant file is eggtrayiconmodule.c Joe ___ 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 & python versions
On Mon, 2003-03-24 at 13:39, Erik Williamson wrote: > Hi All, > > (Newbie Alert, watch out) > > I'm currently writing an application that needs to run on all releases > of RedHat from 7.0 to 8.0. My problem is that I'd like to write it > using pygtk2 - but take a look at what comes with the various releases: > > RedHat Release Python Version PyGTK Version > - > 7.0 1.5.2 ? > 7.1 1.5.2 ? > 7.2 1.5.2 & 2.1.1 0.6.8 > 7.3 1.5.2 & 2.2.2 0.6.9 & 1.99.8 > 8.0 2.2.2 1.99.12 > > Can you think of a nice way that I can write something to run on all > platforms? My only thought is that I could bundle python 2.2.2 & PyGtk > with the application... Honestly I am out of ideas. Expect pain. You'll not only have to ship python 2.2.2, you'll also have to ship all of the libraries below and including pygtk2. This includes gtk, atk, pango, and glib. We're in a similar situation because for an app we're developing we're taking advantage of threading fixes in 1.99.15, but due to API incompatibilties we can't update the pygtk on Red Hat 8.0 or else all of the Red Hat config tools will break. You might be able to get something like "freeze" working. We're using this: http://www.mcmillan-inc.com/install5_ann.html which will include a python interpreter, all your python files, and also the shared objects needed for modules written in C. Joe ___ 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] Crash with a gtkcellrenderer in python and threads
On Tue, 2002-11-12 at 17:15, Joe Shaw wrote:
> Maybe it should call pyg_block_threads() and chain up to its parent?
> I'll try it and send a patch if it works.
Sigh. Obviously this doesn't work, as I don't care about the parent's
properties. I care about the child's.
So I think the right thing to do is probably to add the
pyg_block_threads() and pyg_unblock_threads() to
pyg_object_set_property(), but I don't know how to fix the failed
assertion that I get ("Fatal Python error: PyThreadState_Get: no current
thread").
Anyone have any ideas?
Joe
___
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] Crash with a gtkcellrenderer in python and threads
Hi, I have a cell renderer written in python which derives from gtk.GenericCellRenderer. When I run my program with gtk.threads_init(), python crashes when I try to set a property on the cell renderer. It dies in a call to PyObject_CallMethod(). For other crashes I've seen like this, wrapping the calls in pyg_block_threads()/pyg_unblock_threads() fixes the problem, but when I try it this time, I get: Fatal Python error: PyThreadState_Get: no current thread The program crashes in gobjectmodule.c:pyg_object_set_property(), trying to call my object's do_set_property() method. I noticed that pygtkcellrenderer.c doesn't overload the set_property() and get_property() methods on GObjectClass. Maybe it should call pyg_block_threads() and chain up to its parent? I'll try it and send a patch if it works. Here's are a few frames from the stack trace: #8 0x40018861 in _r_debug () from /opt/pygtk/lib/python2.2/site-packages/gtk-2.0/gobjectmodule.so #9 0x401a7e37 in g_object_set_property (object=0x8424e88, property_name=0x84255e8 "value", value=0xbfffd0f0) at gobject.c:571 #10 0x404656b0 in gtk_tree_view_column_cell_set_cell_data ( tree_column=0x8425540, tree_model=0x841fe80, iter=0xbfffd1e0, is_expander=0, is_expanded=0) at gtktreeviewcolumn.c:2270 Joe ___ 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] Patch for pygtktreemodel.c
Hi,
None of the calls to PyObject_CallMethod() in pygtktreemodel.c is
wrapped with pyg_block_threads()/pyg_unblock_threads(), which will cause
python to segfault if you use gtk.threads_init() in your program. The
attach patch adds these.
I've filed this as bug #98344.
Joe
Index: pygtktreemodel.c
===
RCS file: /cvs/gnome/gnome-python/pygtk/gtk/pygtktreemodel.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 pygtktreemodel.c
--- pygtktreemodel.c 7 Jul 2002 12:45:45 - 1.9
+++ pygtktreemodel.c 12 Nov 2002 21:34:49 -
@@ -197,7 +197,9 @@ pygtk_generic_tree_model_get_flags(GtkTr
#ifdef DEBUG_TREE_MODEL
g_message("get_flags()");
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_flags", "");
+pyg_unblock_threads();
if (py_ret) {
guint ret = PyInt_AsLong(py_ret);
@@ -223,7 +225,9 @@ pygtk_generic_tree_model_get_n_columns(G
#ifdef DEBUG_TREE_MODEL
g_message("get_n_columns()");
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_n_columns", "");
+pyg_unblock_threads();
if (py_ret) {
gint ret = PyInt_AsLong(py_ret);
@@ -249,8 +253,10 @@ pygtk_generic_tree_model_get_column_type
#ifdef DEBUG_TREE_MODEL
g_message("get_column_type(%d)", index);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_column_type",
"(i)", index);
+pyg_unblock_threads();
if (py_ret) {
GType ret = pyg_type_from_object(py_ret);
@@ -280,8 +286,10 @@ pygtk_generic_tree_model_get_iter(GtkTre
g_message("get_tree_iter(%p)", path);
#endif
py_path = pygtk_tree_path_to_pyobject(path);
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_iter",
"(O)", py_path);
+pyg_unblock_threads();
Py_DECREF(py_path);
if (py_ret) {
@@ -318,8 +326,10 @@ pygtk_generic_tree_model_get_path(GtkTre
#ifdef DEBUG_TREE_MODEL
g_message("get_tree_path(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_tree_path",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
GtkTreePath *path = pygtk_tree_path_from_pyobject(py_ret);
@@ -354,8 +364,10 @@ pygtk_generic_tree_model_get_value(GtkTr
/* init value to column type */
g_value_init(value, pygtk_generic_tree_model_get_column_type(tree_model, column));
+pyg_block_threads();
py_value = PyObject_CallMethod(self, METHOD_PREFIX "get_value",
"(Oi)", (PyObject *)iter->user_data,column);
+pyg_unblock_threads();
if (py_value) {
pyg_value_from_pyobject(value, py_value);
@@ -380,8 +392,10 @@ pygtk_generic_tree_model_iter_next(GtkTr
#ifdef DEBUG_TREE_MODEL
g_message("iter_next(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_next",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
if (py_ret != Py_None) {
/* handle reference counting here */
@@ -420,8 +434,10 @@ pygtk_generic_tree_model_iter_children(G
#endif
if (parent && parent->user_data != NULL)
py_parent = (PyObject *)parent->user_data;
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_children",
"(O)", py_parent);
+pyg_unblock_threads();
if (py_ret) {
if (py_ret != Py_None) {
/* handle reference counting here */
@@ -457,8 +473,10 @@ pygtk_generic_tree_model_iter_has_child(
#ifdef DEBUG_TREE_MODEL
g_message("iter_has_child(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_has_child",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
gboolean ret = PyObject_IsTrue(py_ret);
@@ -485,8 +503,10 @@ pygtk_generic_tree_model_iter_n_children
#ifdef DEBUG_TREE_MODEL
g_message("iter_n_children(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_n_children",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
gint ret = PyInt_AsLong(py_ret);
@@ -516,8 +536,10 @@ pygtk_generic_tree_model_iter_nth_child(
#endif
if (parent && parent->user_data != NULL)
py_parent = (PyObject *)parent->user_data;
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_nth_child",
"(Oi)", py_parent, n);
+pyg_unblock_threads();
if (py_ret) {
if (py_ret != Py_None) {
/* handle reference counting here */
@@ -556,8 +578,10 @@ pygtk_generic_tree_model_iter_parent(Gtk
#endif
if (child && child->user_data != NULL)
py_child = (PyObject *)child->user_data;
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_parent",
"(O)", py_child);
+pyg_unblock_threads();
if (
Re: [pygtk] Patch for gtk.Menu.attach_to_widget()
On Thu, 2002-11-07 at 16:06, Joe Shaw wrote:
> +%%
> +override gtk_menu_attach_to_widget kwargs
> +static void
> +pygtk_menu_detach (GtkWidget *attach_widget, GtkMenu *menu)
> +{
> +PyObject *func;
> +PyObject *ret;
> +
> +func = g_object_get_data (G_OBJECT (menu), "pygtk_menu_detach_func");
> +g_assert (func);
Oops. Obviously, that should be:
if (!func)
return;
aside from that, I think the rest of the patch is still okay.
Joe
___
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] Patch for gtk.Menu.attach_to_widget()
Hi,
Attached is a patch to gtk.override which adds the attach_to_widget()
method to gtk.Menu.
I've filed this as bug #97963.
Joe
? gen-.defs.c
? gtk.override.real
? out
Index: gtk.override
===
RCS file: /cvs/gnome/gnome-python/pygtk/gtk/gtk.override,v
retrieving revision 1.152
diff -u -p -u -r1.152 gtk.override
--- gtk.override17 Oct 2002 03:13:18 - 1.152
+++ gtk.override7 Nov 2002 20:59:20 -
@@ -3274,7 +3274,6 @@ ignore
gtk_item_factory_set_translate_func
gtk_item_factory_create_items_ac
gtk_item_factory_create_menu_entries
- gtk_menu_attach_to_widget
gtk_menu_bar_append
gtk_menu_bar_insert
gtk_menu_bar_prepend
@@ -3875,6 +3874,70 @@ _wrap_gtk_menu_item_new(PyGObject *self,
}
pygobject_register_wrapper((PyObject *)self);
return 0;
+}
+%%
+override gtk_menu_attach_to_widget kwargs
+static void
+pygtk_menu_detach (GtkWidget *attach_widget, GtkMenu *menu)
+{
+PyObject *func;
+PyObject *ret;
+
+func = g_object_get_data (G_OBJECT (menu), "pygtk_menu_detach_func");
+g_assert (func);
+
+pyg_block_threads ();
+ret = PyObject_CallFunction (func, "OO",
+pygobject_new ((GObject *) menu),
+pygobject_new ((GObject *) attach_widget));
+
+if (ret == NULL) {
+ PyErr_Print ();
+ PyErr_Clear ();
+ Py_XDECREF (ret);
+}
+else
+ Py_DECREF (ret);
+
+pyg_unblock_threads ();
+}
+static PyObject *
+_wrap_gtk_menu_attach_to_widget (PyGObject *self, PyObject *args,
+PyObject *kwargs)
+{
+static char *kwlist[] = { "attach_widget", "detach_func", NULL };
+PyGObject *py_attach_widget;
+PyObject *detach_func;
+GtkWidget *attach_widget;
+
+if (!PyArg_ParseTupleAndKeywords (args, kwargs,
+ "OO:GtkMenu.attach_to_widget",
+ kwlist, &py_attach_widget, &detach_func))
+ return NULL;
+
+if (pygobject_check (py_attach_widget, &PyGtkWidget_Type))
+ attach_widget = GTK_WIDGET (py_attach_widget->obj);
+else {
+ PyErr_SetString (PyExc_TypeError,
+"first argument must be a GtkWidget");
+ return NULL;
+}
+
+if (!PyCallable_Check (detach_func) && detach_func != Py_None) {
+ PyErr_SetString (PyExc_TypeError, "second argument not callable");
+ return NULL;
+}
+
+if (detach_func != Py_None) {
+ Py_INCREF (detach_func);
+ g_object_set_data (self->obj, "pygtk_menu_detach_func", detach_func);
+}
+
+gtk_menu_attach_to_widget (GTK_MENU (self->obj), attach_widget,
+ (GtkMenuDetachFunc) pygtk_menu_detach);
+
+Py_INCREF (Py_None);
+return Py_None;
}
%%
ignore gtk_check_menu_item_new_with_label gtk_check_menu_item_new_with_mnemonic
[pygtk] Crash in pygtk_generic_cell_renderer_get_size()
Hi,
I came across a crash in pygtk_generic_cell_renderer_get_size(). It
doesn't check to see if the arguments passed in are NULL before passing
them to PyArg_ParseTuple(), which dereferences them and crashes.
I've filed bug #97436 about it, and attached this patch to it.
Joe
Index: pygtkcellrenderer.c
===
RCS file: /cvs/gnome/gnome-python/pygtk/gtk/pygtkcellrenderer.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 pygtkcellrenderer.c
--- pygtkcellrenderer.c 20 Jul 2002 05:44:37 - 1.2
+++ pygtkcellrenderer.c 1 Nov 2002 20:16:26 -
@@ -94,6 +94,7 @@ pygtk_generic_cell_renderer_get_size (Gt
gint*height)
{
PyObject *self, *py_ret, *py_widget, *py_cell_area;
+gint my_x, my_y, my_width, my_height;
g_return_if_fail(PYGTK_IS_GENERIC_CELL_RENDERER (cell));
@@ -117,13 +118,26 @@ pygtk_generic_cell_renderer_get_size (Gt
Py_DECREF(py_widget);
Py_DECREF(py_cell_area);
-if (!PyArg_ParseTuple(py_ret, "", x_offset, y_offset, width, height)) {
+if (!PyArg_ParseTuple(py_ret, "",
+ &my_x, &my_y, &my_width, &my_height)) {
PyErr_Clear();
Py_DECREF(py_ret);
g_warning("could not parse return value of get_size() method. "
"Should be of form (x_offset, y_offset, width, height)");
return;
}
+
+if (x_offset)
+ *x_offset = my_x;
+
+if (y_offset)
+ *y_offset = my_y;
+
+if (width)
+ *width = my_width;
+
+if (height)
+ *height = my_height;
/* success */
}
Re: [pygtk] libesd.la
On Sat, 2002-09-07 at 10:24, Anthony Tekatch wrote: > and got the following error: > libtool: link: `/usr/lib/libesd.la' is not a valid libtool archive > > After some digging I found that there is some sort of problem with the > esound package and its improper use of library links. I could not figure > out the details for correcting the problem. Some .la file is looking for libesd.la and not finding it. You're probably running a RH-Ximian hybrid which is causing it. You can find which one by grepping for it in all the .la files. Fortunately, you're on Linux and don't have a sucky linker. You don't need .la files, so go ahead and just delete them from /usr/lib. (Or just move them somewhere safe if that makes you jumpy) They don't buy you anything on Linux, and that's why we don't ship them, IIRC. Joe ___ 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] ANNOUNCE: pygtk-1.99.13
On Sun, 2002-08-25 at 11:52, James Henstridge wrote: > > Looks like I missed it. Will have to go in the next release. Please go > ahead and commit. Bummer. Okay, committed it. In the future, would you like patches sent to the list, put in bugzilla, or both? Thanks, Joe ___ 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] ANNOUNCE: pygtk-1.99.13
On Sun, 2002-08-25 at 10:27, James Henstridge wrote: > I have uploaded a new 1.99.x release of PyGTK at: > ftp://ftp.gtk.org/pub/gtk/python/v2.0/pygtk-1.99.13.tar.gz Does this contain the gsize/gssize patch I sent a couple of days ago? URL is here: http://www.daa.com.au/pipermail/pygtk/2002-August/003273.html Without it, GdkPixbufLoader is pretty useless. Thanks, Joe ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
