Re: [pygtk] How to pass the value to a function? (gtk.entry)
On 04/25/2014 07:18 AM, bakabonpapa wrote: Right now, I'm building a gui program using pygtk. And there is an entry box using gtk.Entry and its get_text. I'v been trying to pass its parameter to a function as a parameter, but strugling for long hours without succsess. Please describe what you actually want to accomplish. There is little use in calling get_text() on a newly created gtk.Entry, since the entry will certainly be empty. Passing its parameter to a function as a parameter doesn't make much sense, either - maybe you mean passing its return value? For example, functionA(self.entry.get_text()). But that should likely be done when the entry is changed or activated, again depending on what you want the program to do. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.idle_add, timeout_add gdk-thread-safe?
On 12/01/2013 10:19 PM, Tim Evans wrote: It's the GTK and GDK functions you have to be careful with. You don't need (3)/(4). You should still have (1)/(2), Why? I thought the whole point of using g_idle_add from the other thread is to have the callbacks invoked in the GUI thread (the thread that runs the GTK main loop). If the GTK API is only ever accessed from a single thread, then no locking should be necessary. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] gobject.idle_add, timeout_add gdk-thread-safe?
On 12/02/2013 09:50 AM, Dan wrote: Also, related to Hrvoje Niksic's comment, is it safe to use GDK calls from other threads at all (as long as you guard them with the appropriate incantations)? Or do you absolutely have to schedule all GUI work to the GUI thread? According to https://developer.gnome.org/gdk3/stable/gdk3-Threads.html, GDK calls from other threads are unsafe in non-X11 backends, even with locks around the calls. When using the X11 backend, the documentation warns that combining the GDK lock with other locks, such as Python's GIL can be complicated, and that such locking is deprecated in GTK 3. Judging by the documentation, it seems best to keep GDK calls to a single thread, unless you only use X11 and really know what you are doing. If the latter, then I also don't see the point of locking in the callback. Ah, so the point of locking in the callback would be to prevent a race condition between the GUI thread calling into GTK and other threads doing the same? But in that case, requirement for g_idle_add callbacks locking stands for *all* calls to g_idle_add in the application (including those performed by GTK itself, if any), not only those coming from another thread. After all, whichever thread g_idle_add is called from, the callback will end up running in the same thread, the GUI thread that runs the main loop. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] Help installing PyGObject
On 03/05/2013 09:20 PM, Vincent D. Brown wrote: I was wondering if anyone could help me with some installation trouble. I downloaded PyGObject 3.0.2 and tried running configure. It said that I don't have glib version = 2.24.0, so I found glib 2.24.2 and installed it. The configure still stops on the same error: checking for GLIB - version = 2.24.0... no What is the output of pkg-config --cflags glib-2.0? It should point to your newly installed glib 2.24.2, and not to the old glib present on the system. If this is not the case, you either need to put the installed directory on PKG_CONFIG_PATH, or see what went wrong with the installation. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject_new segfault
You need to call pygobject_init(-1, -1, -1) before using pygobject. You also need to call Py_Initialize(). Also, since you're using gtk, and not just gdk, you should call gtk_init(). With the first three lines of main() changed to: gdk_init(argc, argv); Py_Initialize(); pygobject_init(-1, -1, -1); and with -lpython2.7 added to the compilation line, the test program no longer segfaults on startup. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] PyGTK object escapes garbage collection
The problem you describe sounds like it might be related to this infamous PyGTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=546802 In our tests the problems show up when a Python object that participates in a cycle is referenced only through a GTK widget. When GC takes place, Python's cycle-breaker incorrectly concludes that the whole cycle is unreachable and runs tp_clear on all objects. The objects are, of course, still reachable through PyGTK, and unfortunately now quite broken. A number of workarounds are available: simply access the widget's __dict__, which forces it to switch to a different reference-counting strategy. Or store a reference to your object in a global variable or container. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] libglade bug?
Rob Brown-Bayliss wrote:
print =
print Count = + str(self.check_count)
self.check_count += 1
print self.wtree.get_widget(label_checkbutton)
print =
if self.wtree.get_widget(label_checkbutton).get_active():
some code cut
It has been working fine for a very long time, then I upgraded to ubuntu
9.04, and started getting this error:
AttributeError: 'NoneType' object has no attribute 'get_active'
It's very likely a case of bug #546802,
http://bugzilla.gnome.org/show_bug.cgi?id=546802
A known workaround is to access the dict of the widget, simply using:
self.wtree.__dict__
self.wtree.get_widget('label_checkbutton')__dict__
Does anyone know if the latest PyGTK has this bug fixed? We encounter
it frequently during in-house development.
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] Problem with the GC starting in the middle of _wrap_gtk_window_list_toplevels
Margarita Manterola wrote: I probably screwd up, because it didn't work. This is what I was left with: My code was not meant to be run verbatim, sorry I didn't make that clearer. For example, PyImport_Import takes a PyObject * argument, not a C string, use PyImport_ImportModule instead. This is why you got a crash when you tried to use the returned object (likely NULL or garbage). // error checking elided for brevity Please don't elide error checking for brevity in the code you're using for actual testing, include it! If you're not sufficiently familiar with Python/C, at least read up sections on reference counting and error checking of Embedding and extending manual. Maybe you're seeing a weird corner case of http://bugzilla.gnome.org/show_bug.cgi?id=546802 which is known to cause GC to prematurely break cycles which it shouldn't. I'd try applying the fix for that bug, maybe it helps. I applied that patch and it seems to have worked. No more segfaults, no calls to the tooltips_destroy. However, I have no idea what the patch does and if the bug is really fixed by this, or it's just a coincidence (being that it's a bug related to what might happen if GC runs, it's very difficult to check). The bug causes objects reachable only from GTK be erroneously trashed by the GC. The details are hard to understand because they involve interaction between two reference-counting systems (those of GObject and Python), but that would be the gist of it. It has bitten me in the past and I've reported a duplicate of it. What you saw could well be caused by that bug, but it'd be a good idea to verify it, for starters by confirming that the bug is caused in the GC, and then that the fix for 546802 fixes it. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] Problem with the GC starting in the middle of _wrap_gtk_window_list_toplevels
Margarita Manterola wrote: The garbage collector is called while the code is in the for loop, it removes one of the toplevel windows which is not in use anywhere, except that it's already on the list, thus after the GC returns and the loop tries to access that removed window, it triggers a segfault. I can think of one ugly solution, but no correct solution. The ugly solution would be to add extra checks everywhere, so that if a window was destroyed in the middle of the function, everything would still work. The correct solution would be to somehow prevent the GC from destroying the unused window which is still in the list, but I have no idea how. Any ideas on how to fix it? I'm not sure about a correct fix, but it's a bit worrying that the C backtrace is showing no signs of GC. Why not add code that disables the GC and reenables it around the loop? Something like: // error checking elided for brevity static PyObject *gc_module; if (!gc_module) gc_module = PyImport_Import(gc); PyObject *ret; ret = PyObject_CallMethod(gc_module, disable, ); Py_DECREF(ret); ... loop goes here ... ret = PyObject_CallMethod(gc_module, enable, ); Py_DECREF(ret); If this removes the crash, then it's a good confirmation that it's gc-related. A workaround could be to disable the GC as shown above. A correct fix should consider how it's possible for the GC to get triggered for an object that it's already on the list? The GC should only be invoked on objects that are only reachable by members of their cycle, whereas your object is clearly visible from the outside, because you're holding a reference to the list that leads to it. Maybe you're seeing a weird corner case of http://bugzilla.gnome.org/show_bug.cgi?id=546802 which is known to cause GC to prematurely break cycles which it shouldn't. I'd try applying the fix for that bug, maybe it helps. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] Signal handling
"Luca Minuti" [EMAIL PROTECTED] writes:
#!/usr/bin/env python
from signal import *
from gtk import *
def signal_handler(sig, frame):
print "Received signal %s" % (sig)
signal(10, signal_handler)
win = GtkWindow()
win.set_usize(100,100)
win.show()
win.connect("destroy", mainquit)
mainloop()
but if I write:
$ kill -s 10 pid
the program answer only after the mainquit.
I've hit this problem before[1], and it boiled down to a problem with
Gtk/Python interaction. You should know that in Python signals are
never really asynchronous. When the OS/C-level signal handler is
invoked, Python merely enqueues the Python handler to a special queue,
to be executed by the Python interpreter as soon as possible.
The problem with Gtk is that when the signal handler returns, it gives
back control to the Gtk main loop, not to Python, so the code that is
supposed to check for the signal-handler queue gets run only when the
interpreter exits.
The solution here is for pygtk to hook into the main loop with a
routine that gets run after the loop has been interrupted by a signal.
This routine would manually call the Python signal-handling
incantation. Alas, last time I looked, GDK main loop didn't have that
kind of hook. I asked about it on the Gtk list, but got no response.
James, have you looked into the features of GDK main loop recently?
Can you now specify a "post-signal" handler nowadays?
[1]
Before someone jumps with "don't use UNIX signals in a GUI
application", let me assure you that it was hard to do otherwise. My
Gtk program spawned off a bunch of child processes, and was interested
in their exit statuses. Apparently the only wait to find out when a
process has died is to handle SIGCHLD. I haven't found the solution
to the problem, and gave up the application entirely.
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Signal handling
"Luca Minuti" [EMAIL PROTECTED] writes: I think that the use of the signal is not the only possible solution for me. But I don't know others inter process comunication tecnique. My program must do this: if someone make some change to the data that the program manipulate other instance of the same program must update their own view. How do you know the PID's of the other instances? ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] PyQt/PyKDE Bindings
François Pinard [EMAIL PROTECTED] writes: Moshe Zadka [EMAIL PROTECTED] writes: As long as you're breaking things anyway, let me suggest one change: have the "Gtk" prefix stripped from the classes' names (GtkText - Text, etc) [...] For one, I would be happy to make that change, as well (partly because I've not that much written so far :-). ... I'm not sure of anything, beside the fact I would like to turn `GtkText' into `Gtk.Text'. That would be definitely cool. I tend to write `import gtk' rather than `from gtk import *' for two reasons: * It's a good idea in general to avoid `from FOO import *'. Many modules tend to clash in names, e.g. re.split and string.split, etc. * gtk specifically exports a whole bunch of unprefixed names. For example, I really don't want unadorned TRUE and FALSE in my namespace. Having said that, I often note that gtk.GtkWindow looks sort of ugly. In an ideal world, we'd be able to write: import gtk w = gtk.Window(...) w.set_foo(gtk.TRUE, ...) And so on. - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Anti-aliasing ?
Torsten Landschoff [EMAIL PROTECTED] writes: On Mon, Mar 13, 2000 at 02:05:39PM +0100, Hrvoje Niksic wrote: What version of gnome-python do you have installed on your system? 1.0.50-3 (Debian). Hmm, does anybody know if this feature is needed by a lot of programs? I have no idea what feature is in fact brkoen; I've only tried to run the program, and it doesn't work. In that case please file an important bug against python-gnome. I am working on new packages but they will not get into potato unless they fix a release critical bug. How typical. :-( To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Anti-aliasing ?
James Henstridge [EMAIL PROTECTED] writes: What version of gnome-python do you have installed on your system? 1.0.50-3 (Debian). To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Hello, and `pygtk' reminder
François Pinard [EMAIL PROTECTED] writes:
I suppose I should put in a message stating that the pyglade
module is deprecated. It is probably better to use the libglade
module, which uses libglade rather than being pure python. It
handles the default_width and default_height attributes
correctly.
However, I do not run Gnome, and would prefer to not ought to change
window managers as well. A new language and a new design spirit is
a lot already for the poor little me, I do not feel like embracing a
new religion as well! I tried both KDE and Gnome for a while, and
returned to my previous habits, probably because I merely failed to
quickly see the promised wonders. :-)
However, I repeatedly read on the `pygtk' mailing list archives that
PyGnome (whatever it is :-) is the way to go, yet the same lists
report a lot of build and unstability problems (but maybe I
misinterpreted them?).
François, please note that pygtk does not require PyGnome to be used.
PyGnome is merely a superset of pygtk, providing wrappers for
Gnome-specific stuff, such as communication with panel, and the
additional Gtk widgets provided by Gnome. (Also note that you needn't
switch window managers to run Gnome, but that's a different issue.)
I believe the glade bindings can be useful. Gtk programming is
basically fun -- you explain to the engine the layout you want your
widgets to have, you connect their actions to callbacks, and watch
things happen. With Python's lexical-scoping-like bound methods, it's
really not hard to get reasonable results.
The most tedious part of it all is configuring actual widget packing.
Take, for instance, a simple class that tries to configure a text
entry field along with "OK" and "Cancel". It's totally trivial, and
should look like this:
class OpenDialog(gtk.GtkWindow):
def __init__(self, dispatchfun):
gtk.GtkWindow.__init__(self)
# ... setup the widgets ...
gtk_entry.connect("activate", self.open, entry, dispatchfun)
gtk_entry.connect("changed", self.change_hook)
button1.connect("clicked", self.open, dispatchfun)
button2.connect("clicked", self.destroy)
self.show_all()
def change_hook(self, widget):
if widget.get_text() == '':
self.ok_button.set_sensitive(gtk.FALSE)
else:
self.ok_button.set_sensitive(gtk.TRUE)
def open(self, widget, entry, dispatchfun):
text = entry.gtk_entry().get_text()
if text != '':
dispatchfun(text)
self.destroy()
Nice and simple, isn't it? In reality, because I didn't bother to
learn to use libglade properly, it looks as below, a spaghetti of
getting the Gtk widgets to look nice. *All* the additional code could
have been done within libglade, based on an XML file that the users
can edit. My code would simply get the objects and work on them. The
real code follows:
class OpenDialog(gtk.GtkWindow):
def __init__(self, dispatchfun):
gtk.GtkWindow.__init__(self)
self.set_border_width(5)
self.set_policy(gtk.TRUE, gtk.TRUE, gtk.FALSE)
gtk.quit_add_destroy(1, self)
vbox = gtk.GtkVBox()
self.add(vbox)
label = gtk.GtkLabel("Enter a URL to download it with Wget.")
label.set_alignment(0, 0.5) # No centering
label.set_padding(0, 5)
vbox.pack_start(label, expand = gtk.FALSE, fill = gtk.FALSE)
hbox = gtk.GtkHBox(spacing = 10)
vbox.pack_start(hbox, expand = gtk.FALSE, padding = 3)
hbox.pack_start(gtk.GtkLabel("Open:"), expand = gtk.FALSE, fill = gtk.FALSE)
entry = gnome.ui.GnomeEntry("OpenDialog")
gtk_entry = entry.gtk_entry()
gtk_entry.connect("activate", self.open, entry, dispatchfun)
gtk_entry.connect("changed", self.change_hook)
#gtk_entry.set_flags(gtk.HAS_DEFAULT | gtk.CAN_DEFAULT)
#gtk_entry.grab_default()
hbox.pack_start(entry)
vbox.pack_start(gtk.GtkHSeparator(), expand = gtk.FALSE, padding = 10)
alignment = gtk.GtkAlignment(0.5, 0.5, 1, 1)
vbox.pack_start(alignment, expand = gtk.FALSE)
bbox = gtk.GtkHButtonBox()
bbox.set_layout(gtk.BUTTONBOX_SPREAD)
alignment.add(bbox)
button = gnome.ui.GnomeStockButton(gnome.ui.STOCK_BUTTON_OK)
button.connect("clicked", self.open, dispatchfun)
button.set_flags(gtk.HAS_DEFAULT | gtk.CAN_DEFAULT)
#button.grab_default()
button.set_sensitive(gtk.FALSE)
bbox.pack_start(button)
self.ok_button = button
button = gnome.ui.GnomeStockButton(gnome.ui.STOCK_BUTTON_CANCEL)
button.connect("clicked", self.destroy)
bbox.pack_start(button)
def change_hook(self, widget):
if widget.get_text() == '':
self.ok_button.set_sensitive(gtk.FALSE)
else:
self.ok_button.set_sensitive(gtk.TRUE)
def open(self, widget, entry, dispatchfun):
[pygtk] Threads with Gtk?
What is the current level of support for threading in PyGTK? Last time I checked, threading had problems because threads weren't enabled upon entrance to main loop, and in several other places. Specifically, how does Gtk's threading model mesh with Python's threading? Is it possible for the main loop to be running in a separate thread (and the application be responsive) while different Python threads do useful work and update widgets accordingly? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Panel applet taking button2
[ Please note that button2 is the *middle* button, not the right mouse button. Your question seems to imply that you think I want to change the behaviour of right-click, which I don't. ] Edward Muller [EMAIL PROTECTED] writes: 1) What do you want to do on the button 2 click? I'm writing an applet that you can drag URLs from netscape into, and it then calls Wget in a separate window. You can have several such windows, control them in various ways, etc. When you left-click on the applet, it asks you to enter the URL in a dialog box. I want button2 to do what it does in netscape. For those who don't know, in that case netscape will fetch the primary selection (if any), and go to that location. For me, that is a less known but incredibly useful feature that I want to copy. The reason why I ask this is that most of us have probably become accustomed to what happens when we right click on an applet, we get the standard applet menu plus any menu items the developer wanted to add to it. Right-click will work as before -- I don't intend to muck with it, apart from adding my own menu callbacks, as is usual for applets. If you really want to use my applet, and if you really want button2 to move it, I can add a way to disable the netscape-like feature, or move it to Sh-button1 or something. Additionally, it would be Really Really Nice if we could distinguish between a button2 *click* and a button2 *drag*, and assign them to different actions. A click could do as described above, while a drag could invoke the usual button2 drag. I deleted your second question because of the button2 confusion. This is not Windows. :-) To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Retrieving selection data
How do I retrieve the current X selection in pygtk? I'd like to, say, have it as a Python string, or as None if none is available. I've looked at the Gtk tutorial, but in this case, wasn't at all obvious how to convert the C code to Python. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Panel applet taking button2
Is there a way for a panel applet to have control of button2 clicks. Normally, when button2 is pressed, the applet is moved. However, I *really* want my applet to respond to button2 clicks. Any ideas? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Ruler in vbox doesn't work
Deirdre Saoirse [EMAIL PROTECTED] writes: #include rant on C code not being able to have abstract \ non-instantiable classes But we're using Python, aren't we? :-) I think the following check in "abstract" classes' __init__() would work: assert self.__class__ != GtkRuler James, what do you think? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] GtkTreeItem boggle
James Henstridge [EMAIL PROTECTED] writes: Now in order to have the same python object refer to a particular gtk object all the time, the gtk object would need to hold a reference to it (we don't want the python object to be freed while the gtk object is in use). This forms a circular dependency, It doesn't, since the Python collector knows nothing about Gtk objects. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Hooking into Gtk iterations
James Henstridge [EMAIL PROTECTED] writes: As for doing a python no op, I have no idea how python triggers the calling of signal handlers The signal handlers are queued up somewhere; Python will empty the queue as soon as it gets the chance -- I'm certain of that. A no-op would be quite sufficient for that. (does it have anything to do with the threading code?). I don't think so, no. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Hooking into Gtk iterations
Aaron Optimizer Digulla [EMAIL PROTECTED] writes: The only solution I see is to add a timer: def wakeup: pass timeout_add (100, wakeup) I know of this solution and I will not use it, because it disallows my program from ever being swapped out -- it continually consumes CPU instead of simply waiting in poll() when nothing happens. This is (for me) inexcusable. (does it have anything to do with the threading code?). I don't think so, no. Yes, that's the same. Threading doesn't work with the current implementation of Gtk because all Python threads are dead as long as Gtk waits in its mainloop for events (no Python code is executed - Python can't switch the threads). This is brain-dead on the part of Python, but that's another matter. :-( To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] 1:1 mapping between C and Python objects
I thought about this some more, and then returned to an earlier message of James'. I think I spotted a flaw in James' logic. Here is the excerpt: I looked at this a bit, but it is a little difficult. First of all, you want these two things to occur: - The C level GtkObject should not die while the python representation is arround (this is what currently occus). - The python representation should not get garbage collected while the C GtkObject is arround. Now, James proceeds to explain how this inherently implies a circular reference. However, I think the flaw in the logic is in the first clause. In my opinion, the Gtk object should very well be allowed to die while the Python representation is around -- it is only the second clause that is really necessary for things to function. Let me expand on this: 1) Every Gtk object visible to Python corresponds to exactly one Python object. 2) The Gtk object is registered as a "reference" to the Python object, increasing its refcount. When the Gtk object dies, the Python object's refcount is decreased, possibly destroying it. 3) As a corollary of #2, a Python object may continue to live after the corresponding Gtk object dies. Also as a corollary, the reverse is not true -- the Gtk object cannot live if its Python object is dead. 4) When the Gtk object dies and the Python object survives (because of being referenced elsewhere in Python), the Python object knows its Gtk object is dead and will raise errors if someone tries to use the contained dead Gtk object in any fashion whatsoever. 5) The Gtk object stores the corresponding Python object in an internal "data" field. No global dictionaries are necessary. I see no circularities here because the internal Gtk objects (which indeed contain a pointer back to the Python object) are not visible to Python's GC. Some of the possible cases follow... def somefunc (): window = GtkWindow () ... return Now, somefunc() creates a Python object and a Gtk object. Because there are no other references to the Python object, it will live as long as its corresponding Gtk object lives. If a callback is called, the same Python object will be passed (with all the user's attributes intact) because the Gtk object "knows" what Python object it belongs to. The second case is something like this: def somefunc (): window = GtkWindow () ... return window window = somefunc () ... window.destroy () Now, window can be referenced in many places in Python. The .destroy() callback will destroy its internal Gtk object, but this will merely decrement its refcount. After the Gtk object dies, the Python object knows it, so that something like this will raise an exception: window.show ()# oh no you won't, the Gtk object is dead Sorry for the length. James, if you think this won't work, I'd like to see what I'm missing. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Popup menus
Silence here is worrysome. Is it possible that noone has needed popup menus in PyGtk before? Or, is there an FAQ or a FM that I should read? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Popup menus
Thanks, this works like a charm. Note that there is still a bug when you attempt to actually use a function, whatever it's supposed to do. Test by supplying a dummy function; I get: SystemError: new style getargs format but argument is not a tuple It looks like a bug in gtkmodule. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] New snapshot of pygtk
James Henstridge [EMAIL PROTECTED] writes: I am not sure how to handle this problem. Does anyone have any ideas? Can you please try to recapitulate what exactly the problem is? I find it sort of hard to follow. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Selections in pygtk?
I'm stuck with this, and I'd really appreciate some help. I simply don't understand how to get the current X selection in pygtk. I don't understand the proper arguments to selection_convert(), and there seem to be no examples which I could copy. Is it possible that noone has need of this in pygtk? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Panel applet taking button2
James Henstridge [EMAIL PROTECTED] writes:
The deskguide applet has a special action for the middle button.
Maybe you could look at that code.
Thanks for the suggestion; however, desktop guide implements a new
widget, and I can't do that in pygtk. Specifically:
static void
gwm_desktop_class_init (GwmDesktopClass *class)
{
GtkObjectClass *object_class;
GtkWidgetClass *widget_class;
object_class = GTK_OBJECT_CLASS (class);
widget_class = GTK_WIDGET_CLASS (class);
[...]
widget_class-button_press_event = gwm_desktop_button_press;
And then in gwm_desktop_button_press() it handles button2 events.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
