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/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] 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] 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] Pay on Performance! Search engine positioning.
James Henstridge <[EMAIL PROTECTED]> writes: > On Wed, 21 Jun 2000, Hassan Aurag wrote: > > > To hell with spam. All the maintainer has to do with mailman is to > > disable posting for non-subscribed. Sure this kindda annoying, if > > you are subscribed but post from another email address. It's not "kinda annoying", it's extremely annoying. It makes it very hard for people to just ask a question to the list -- they have to subscribe, ask the question, wait for the answers, and then unsubscribe. I had to do that several times over for various Redhat lists, and it was really tedious. Then you have the problem of discussions from the list cross-posted to knowledgable people elsewhere. With the restricted-post setting, those people cannot respond to the list. > > So solution: disable non-member posting. Cause then they'd need to > > subscribe and receive our emails ;) > > What do others on the list think of this? Please don't do that. That "solution" blocks at least two kind of legitimate mails. ___ 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] 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
>
> 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] pygtk extensionclass work
This sounds yummy, even if my understanding of the specifics is vague. Could you please explain what "extensionclass" is, and how it will affect PyGtk? - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
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] Anti-aliasing ?
Matt Wilson <[EMAIL PROTECTED]> writes: > On Mon, Mar 13, 2000 at 09:10:06AM +0100, Hrvoje Niksic wrote: > > % python a.py > > GnomeUI-Message: The antialiased canvas is buggy. Please do not use it unless you >know what you are doing. > > I know what I'm doing. ;) > > It's not bad in simple cases. You have to get very complex before > you see major problems, and they're usually minor. Hmm. > You saw the anti-alised line though, right? I didn't. I even said so, but it got joined with the "To unsubscribe" line. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Anti-aliasing ?
Matt Wilson <[EMAIL PROTECTED]> writes: > On Sun, Mar 12, 2000 at 11:36:22PM -0500, François Pinard wrote: > > The code below shows the case of a line needing anti-aliasing. > > Would someone knowledgeable tell me if/how I can, within `pygtk', > > produce an anti-aliased line, or else (:-), how I could handle an > > alpha channel for later display? And if you see anything else > > stylistically or logically wrong with this tiny program, also tell > > me, as I'm still learning how to do my first steps! > > The easiest way to do this by far is to use the canvas. The > "aa=TRUE" argument turns on anti-aliasing. It also does alpha > chanel for you. With your program, you would also have to handle > expose events and repaint the exposed area. The canvas does all > this for you. ... When I run your program, I get: % python a.py GnomeUI-Message: The antialiased canvas is buggy. Please do not use it unless you know what you are doing. A window opens, but no contents in it. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] X selection handling
Rick Ree <[EMAIL PROTECTED]> writes: > I know this has been asked before, but I haven't found an answer > IIRC. Neither have I. (I asked the question before.) If you find out, please let me know if it's not already posted to the list. 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, entr
[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] post-only list
"J.W. Bizzaro" <[EMAIL PROTECTED]> writes: > I would STRONGLY recommend using Mailman over Majordomo. We've used > it for nearly a year at The Open Lab, and not one spam message has > made it through the screening, and many have tried. It's very > simple to set up and administer too. Does Mailman allow normal, non-web-based subscription to its lists? 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]
Re: [pygtk] Panel applet taking button2
[ Has this response reached the list? I've sent it once, but I don't
see it in my inbox. Sorry if you're reading this twice. ]
James Henstridge <[EMAIL PROTECTED]> writes:
> >From what I remember, the button press events are redirected to the panel
> when you add the widget to the applet with AppletWidget.add(). I think if
> you do something like:
> a = AppletWidget('something')
> box = GtkVBox()
> a.add(box) # box's events get redirected to panel
> widget = GtkSomething()
> box.pack_start(widget) # widget's events do not get redirected
Does that actually work for you? I have slightly different code that
looks like this:
class DropHole(gnome.applet.AppletWidget):
def __init__(self):
gnome.applet.AppletWidget.__init__(self)
[...]
dnd_victim = gtk.GtkEventBox()
[...]
dnd_victim.set_events(GDK.BUTTON_PRESS_MASK)
dnd_victim.connect("button_press_event", self.mouse_click)
self.add(dnd_victim)
And self.mouse_click() still doesn't get called for button2. In fact,
it does when I click on it several times in succession. :-(
Any other thoughts?
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]
[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]
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] Ruler in vbox doesn't work
Hrvoje Niksic <[EMAIL PROTECTED]> writes: > vbox.add(gtk.GtkRuler()) # Error here! Should have been GtkHRuler() (and I meant GtkHSeparator anyway). Sorry for the noise. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Ruler in vbox doesn't work
Is there an explanation why this trivial program doesn't work? #!/usr/bin/python import gtk w = gtk.GtkWindow() vbox = gtk.GtkVBox() vbox.add(gtk.GtkRuler()) # Error here! w.add(vbox) w.show_all() gtk.quit_add_destroy(1, w) gtk.mainloop() The reported error is: --- working directory: /home/hniksic/python/ % ./x.py Traceback (innermost last): File "./x.py", line 7, in ? vbox.add(gtk.GtkRuler()) # Error here! File "/usr/lib/python1.5/site-packages/gtk.py", line 494, in add _gtk.gtk_container_add(self._o, child._o) File "/usr/lib/python1.5/site-packages/gtk.py", line 70, in __getattr__ raise AttributeError, attr AttributeError: _o Exit 1 04:39:54 When I comment out the "error here" line, or use a widget other than GtkRuler(), things work. 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]
[pygtk] GtkCombo.set_popdown_strings() should accept tuple
It would be nice if GtkCombo's set_popdown_strings() method accepted a tuple (it currently only accepts a list.) To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Hooking into Gtk iterations
Aaron Optimizer Digulla <[EMAIL PROTECTED]> writes: > Quoting Hrvoje Niksic <[EMAIL PROTECTED]>: > > > > > > (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. > > :-( > > No, actually it´s braindead of Gtk Python threads have the requirement that you always have access to the interpreter, because one thread appears to lock all the others while running. This is abominable, and is a direct result of the interpreter being non-thread-safe. Gtk has the requirement that all Gtk actions are done in the same thread, or that you implement semaphores on all Gtk entry-points. This is abominable, and is a direct result of Gtk being non-thread-safe. So IMO they're both brain-dead and there's little we can do about it. This is why I chose the SIGCHLD approach which also has its drawbacks, but appears to work in practice. 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]
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
James Henstridge <[EMAIL PROTECTED]> writes: > I suppose you could use an idle function. It would get called for > each iteration of the main loop, and should allow the signal handler > to be called. I tried that now, but idle functions suck for that purpose. They are called all the time when my program is doing nothing, consuming the CPU. I guess that in a sense "idle" functions are exactly the opposite of what I'm trying to achieve -- I'd like a no-op Python code to be run when something *happens*, in case a signal happened. Perhaps I should try to play with idle priorities? > Basically mainloop() runs this: > while quit_flag != TRUE: > mainiteration() > call_quit_handlers() Are quit_flag and call_quit_handlers() exported to Python? Should they be? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Hooking into Gtk iterations
As you may have noticed, I'm writing a program that tries to track several of its children. It gets notified of a child's death by SIGCHLD. The problem is that Python signal processing is synchronous -- while in the C signal handler, Python simply queues the routine to be run at a later time. In some cases, this doesn't matter because a callback gets run because of the file descriptors that got closed. But in other cases, such as exec-ing "sleep 1", the subprocess' death goes unnoticed until the first time a Python callback is invoked. I think this is fixable because of the fact that a signal will interrupt glib's poll. I'd love to be able to specify code to be run between iterations. The code would be a no-op, but it would be enough to let Python flush its queue. For instance: # Setup a dummy function that gives Python a chance to flush its # signal queues. iteration_add (lambda *args: TRUE) Since I haven't found a way to do this, I tried a different approach; writing a mainloop myself, using the blocking version of gtk_main_iteration(). It looks like this: class MainLoop: def __init__ (self): self.running = 1 quit_add (1, self.__reset) while self.running: mainiteration (block = TRUE) def __reset (self): print "called" self.running = 0 This code works nice as it is -- the death of "sleep 1" is now noticed. The problem is that the above loop never exits because calling mainquit() doesn't invoke MainLoop.__reset__! It was quite a shock to find out that mainquit() doesn't bother to call the stuff registered with quit_add(), even though mainiteration() is in progress. I wonder if that's a bug or a feature... To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] 1:1 mapping between C and Python objects
James Henstridge <[EMAIL PROTECTED]> writes: > Also, currently people can use the lower level _gtk module to write > GTK programs (and I know some people do use it -- they see it as a > good way of prototyping interfaces that can then be translated to C > very quickly). I wouldn't want this ability to be lost in any > changes. I don't think this ability would be lost by what I proposed. When I talked about "Python objects", I mostly meant the internal objects accessed by _gtk, although my examples didn't show it clearly. The connection of gtk.py to _gtk should hopefully remain unchanged. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] new snapshot of pygtk and gnome-python
Richard Fish <[EMAIL PROTECTED]> writes:
> Sam Tannous wrote:
> > So what am I supposed to do now?
>
> Use class attributes referenced from self, or lambda's to pass the
> class instance to your callbacks:
[...]
There is a third solution, kindly provided by Gtk:
def clicked_cb (junk, button):
print button.my_attr
button = GtkButton(...)
button.my_attr = "something"
... blah blah ...
button.connect ("clicked", clicked_cb, button)
I've used this kind of code with success. If all you wish to do is
embed something in an existing class, then my proposal is less
heavy-weight than inheriting from GtkButton and nicer than the lambda
hack.
If our 1:1 mapping ideas see the light of day, you should be able to
simply use the "junk" argument directly.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] 1:1 mapping between C and Python objects
Richard Fish <[EMAIL PROTECTED]> writes: > Hrvoje Niksic wrote: > > Sorry for the length. James, if you think this won't work, I'd like > > to see what I'm missing. > > I have a feeling it's not so much a matter of whether it will work > or not, but the amount of work involved. That's not the feeling I got from James' earlier messages, but you may well be right. James, if you think the scheme would function but are daunted by the amount of work, I'm also willing to help. 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] exit()-ing from a child process loses
James Henstridge <[EMAIL PROTECTED]> writes: > As you may know, X programs talk to the X server through a network > socket connection. :-) Yes, I know that. However, wouldn't it be nice if Gtk+ supported a "quiet shutdown" routine that could be called by the child process? I have a hard time seeing the fact that the child can totally screw up its parent by exit()-ing as a feature. > When one process exits with the exit() call, it will attempt to > clean up this file descriptor and shut down the network connection. > Since this is not what we want for the child process, we call > _exit() instead. Its not a bug, it's a feature :) (Anyway, it can't > be fixed in GTK). It can't, but if Gtk provided the "quiet shutdown" routine mentioned above, things would work for those who chose to call it, wouldn't they? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] GLADE support for PyGTK
James, do you plan to ever write a real code generator for Glade? I mean, the current glade support is a neat hack, but what I like about Glade and its ilk is that I can draw a picture of something, get a C program, and then modify it to my liking. I'd like to be able to do the same thing in Python. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] exit()-ing from a child process loses
James Henstridge <[EMAIL PROTECTED]> writes: > You would get the same problem if you wrote a C GTK+ program that > forked and you called exit(). In this case, you would call _exit() > which bypasses all atexit handlers. Should I raise this question on the Gtk+ list? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] exit()-ing from a child process loses
OK, here is another interesting problem which took several hours to
track. When a Gtk program forks off, it inherits the X file
descriptors from its parent. It seems that when I call sys.exit(),
Gdk gains control (either through atexit() or through a PyGtk cleanup
intercepting SystemExit), interacts with the X file descriptors,
totally hosing the parent. As a result, the parent's Gdk reports IO
errors and aborts.
The typical code where this problem bites looks like this:
pid = os.fork ()
if pid == 0:
# Child
try:
os.execlp ("foo", "bar", "baz")
except:
# An error occurred during execlp; exit immediately
sys.exit (127)
In a Gtk program, if the execlp raises an exception the *parent* will
coredump. If you replace `sys.exit(127)' with
`os.kill(getpid(),signal.SIGTERM)', no coredump happens because the
Gdk stuff never gets invoked.
Fixes/workarounds include, in the increasing order of usefulness:
1) The child closing all the file descriptors except the ones you're
interested in. This is a gross hack that looks like this:
for fd in range(32):
if not fd in (0, 1, 2, self.writefd):
try:
os.close (fd)
except:
pass # Ignore EBADF
2) The child closing only the X file descriptor. This would require
Gdk to somehow export the descriptors it uses, so that Python child
knows what to close. This is also a gross hack, but faster than
the above.
3) Making sure that random Gdk code isn't called at exit time.
4) Providing a function that cleanly shuts down Gtk/Gdk, *without*
messing with the descriptors (except for perhaps closing them), and
*without* calling any callbacks. This, cleanest solution, would
also assume that #3 is being done, for programs that don't bother
to call the function.
The test program is appended below. It forks off and exits the child
after a second's sleep. For me, the parent then coredumps with this
message:
Gdk-ERROR **: an x io error occurred
aborting...
If you uncomment the os.kill(...) statement, it works as expected.
#!/usr/local/bin/python
from gtk import *
import os, sys, signal, time
def fork_off ():
pid = os.fork ()
if pid == 0:
# Child
time.sleep (1)
#os.kill (os.getpid (), signal.SIGTERM)
sys.exit (127)
else:
# Parent
os.wait ()
return FALSE
w = GtkWindow ()
w.connect ("destroy", mainquit)
w.show_all ()
# Call fork_off() as soon as mainloop() starts.
timeout_add (1, lambda *args: fork_off ())
mainloop ()
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Inheriting from Gtk classes broken?
Aaron Optimizer Digulla <[EMAIL PROTECTED]> writes: > > - When a Python object is created, it get's added to an internally > > maintained dictionary that maps the Gtk object to it's Python object. > > This increments the reference count of the Python object. > > Why is this neccessary ? Isn't is sufficient to believe that all > python objects will be referenced as long as the Gtk object > exists ? No, it's not sufficient to believe that. In fact, I think that's exactly what the above dictionary is supposed to achive. > For example, when I add a button to a window, the Python Button > object must be added to the Python Window object (in order to be > able to find it again). Yes, but all other references to these objects can disappear. For example, I can do this in a function: window = GtkWindow () ... return TRUE Now, the only reference to the Python object is through a Gtk object -- when the latter is destroyed, so should the former be, not before (as is the case at the moment). The problem is that for that to work, the Gtk object must know which Python object it belongs to while avoiding circularities visible to Python GC. > > - When a python object needs to be returned to the user, it is fetched > > from the dictionary, rather than returning a newly created object. > > > > - When a Gtk object is destroyed, the corresponding Python object is > > deleted from the object dictionary, thus decrementing the reference > > count, possibly deleting the python object. > > :-/ Why are you sure that the python object *can* be deleted when the > Gtk object is ? He said "possibly", didn't he? Python object will be deleted only if its refcount drops to zero, which indeed means that it is not referenced by anyone else and that it may safely be deleted. > Eg. what happens if the Gtk object should be destroyed but the > Python object is still refd somewhere else ? Or the other way round: > What happens when I del the python object but the Gtk object is > still used somewhere in Gtk ? How can you "del" the Python object? You cannot do any such thing AFAIK. You can call its __del__ function, but that's not the same. For example, how do you explicitly "delete" number 3 or string "foo"? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Inheriting from Gtk classes broken?
Richard Fish <[EMAIL PROTECTED]> writes: > I think until we are able to pass the original python object to > signal handlers, we are better off just not having user-created > attributes available to the signal handlers. I think I agree with this. Fortunately, there are other ways of sharing data with signal callbacks, such as passing mutable objects to signal_connect, or using class methods as objects (which gives you `self' to access.) Otherwise, there really should be some way of achieving 1:1 mapping between Python and Gtk objects. I'll think about it some more. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Inheriting from Gtk classes broken?
Richard, this patch makes class variables behave correctly when inheriting from Gtk classes. Thanks. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Inheriting from Gtk classes broken?
Uh, I think I've found another problem with the new snapshot.
According to Python reference manual, I should be able to use class
variables as default values to class instances. For example:
class Foo:
home = os.environ["HOME"]
... methods in which the class instance can change the value of
self.home; otherwise, self.home will refer to $HOME ...
However, this doesn't appear to work with lateish PyGtk snapshots when
Foo inherits from Gtk classes:
import os
from gtk import *
class Foo (GtkWindow):
home = os.environ["HOME"]
def __init__ (self):
GtkWindow.__init__ (self)
def changehome (self, newhome):
self.home = newhome
foo = Foo ()
print foo.home
foo.changehome ("/")
print foo.home
I would expect this example to print "/home/srce/hniksic" and then
"/". However, it prints "/home/srce/hniksic" twice because
foo.changehome() doesn't change foo.home at all. :-(
If I change this trivial example *not* to inherit from a Gtk class (or
to inherit from any other class), it works as expected. It took me
almost two hours to track this nasty gotcha. Could you please revert
to the old behaviour where I believe this problem did not occur?
The quote from the reference manual which recommends this practice
follows (note the last sentence):
*Programmer's note:* variables defined in the class definition are
class variables; they are shared by all instances. To define
instance variables, they must be given a value in the the
`__init__()' method or in another method. Both class and instance
variables are accessible through the notation "`codeself.name",
and an instance variable hides a class variable with the same name
when accessed in this way. Class variables with immutable values
can be used as defaults for instance variables.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Wisdom of `from gtk import *'
Richard Fish <[EMAIL PROTECTED]> writes: > Hrvoje Niksic wrote: > > James, what do you think about such a scheme? > > I don't know about James, but I regularly (usually) use "import gtk" > rather than "from gtk import *", with no real side effects. Hmm. Yes. Then you don't mind writing gtk.GtkButton instead of gtk.Button, which looks slightly nicer? I guess not. I think I'll give that a shot. Anyway, the point remains that the file advocates `from gtk import *' pretty strongly. I am pretty confident that 99% of the new users will use that. 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]
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]
[pygtk] Wisdom of `from gtk import *'
It's probably late to raise this topic, but I'd still like to hear opinions. The thing is, `gtk.py' advocates `from gtk import *' as a good way to import the Gtk functionality and then uses the Gtk prefix to ensure namespace integrity. However, I'm not sure it really buys us much. I mean, importing stuff like GtkButton or GtkWindow to the global namespace is probably fine, given their common prefix, but I don't like getting stuff like atom_intern(), atom_name(), rc_parse(), idle_add(), events_pending(), new(), or, for that matter, TRUE and FALSE. Wouldn't it be nicer if the normal usage of the gtk module were to just do `import gtk', and the Gtk prefix were removed from classes. Then you would write something like: import gtk class MyWindow (gtk.Window): # instead of GtkWindow ... window = MyWindow () window.show_all () ... gtk.mainloop () James, what do you think about such a scheme? 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]
[pygtk] Popup menus
Has anyone succeeded in creating popup menus with PyGtk? I tried and
failed -- but then, I'm fairly new at Gtk, so I might be doing
something wrong on that front. Here is the extract from the code I've
tried to run:
from gtk import *
from GDK import *
class someclass (GtkWindow):
def __init__ (self):
GtkWindow.__init__ (self)
self.set_events (BUTTON_PRESS_MASK)
self.signal_connect ("button_press_event", self.display_menu)
self.menu = self.create_menu ()
def create_menu (self):
menu = GtkMenu ()
item = GtkMenuItem ("Change Directory...")
item.connect ("activate", self.menu_change_directory)
menu.append (item)
item = GtkMenuItem ("Exit")
item.connect ("activate", mainquit)
menu.append (item)
return menu
def menu_change_directory (self, widget, event):
pass # just testing
def display_menu (self, widget, event):
print event
self.menu.popup () # ! What do I put here?
return TRUE
someclass().show_all()
mainloop ()
I have little clue as to what 6 arguments menu.popup() expects -- I
intuited that the last two should be event.button and event.time, but
I still don't know about the rest. I ventured with `widget' as the
first one, but am still mystified about the second, and the callable
function is also strange. testgtk.py doesn't attempt to create popup
menus, either.
Can somebody please help?
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Types in pygtk
James Henstridge <[EMAIL PROTECTED]> writes: > I have fixed up the DnD target list problem. You should now be able > to use any sequence type for the target list. Thanks. I assume by "now" you mean in the next released version? > The string -> colour conversion may be a bit trickier, as it may be > difficult to know which colormap to allocate to. Hmm. It seems the obvious answer is to traverse the widget tree upwards until you find one with a `colormap' object. > Apparantly it does such conversions and also string -> font > conversions. Yes, that one would also be useful. There should also be a cache of the latter, so that expensive lookups don't have to be made. > I may also look at implementing the nullok tag for arguments in the > .defs files (which would fix the tooltips problem you bring up). I don't understand this. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Types in pygtk
I think the "upper" layer of pygtk should be more convenient about
types used in Python. Specifically, it should try not to imitate "C",
where you have to spell everything out, but take advantage of a
language where you can actually check the type of your arguments.
Let me illustrate this by several examples.
For example, when a function expects a color, it throws an error
unless it receives a type. Wouldn't it be nice if you
could pass it a string, and then for PyGtk to allocate the color for
you, and pass that to the raw function?
Another example: in "C", the TIP_PRIVATE argument to
gtk_tooltip_set_tips() can be passed as NULL, which means you don't
want any special queries or stuff assigned to the tooltip. Now,
wouldn't it be nice if PyGtk allowed me to pass None, and replace it
with NULL at the C level?
The example that really bugs me is pickiness with lists and tuples.
For example, the second argument to drag_dest_set() should be a list
of tuples. However, if I try to pass it a tuple of tuples (which is
only logical, because I never want to modify it), I get an error.
This works:
# Pass a one-element list
dnd_victim.drag_dest_set (DEST_DEFAULT_ALL, [("STRING", 0, 0)],
ACTION_COPY | ACTION_MOVE)
And this doesn't:
# Pass a singleton
dnd_victim.drag_dest_set (DEST_DEFAULT_ALL, (("STRING", 0, 0),),
ACTION_COPY | ACTION_MOVE)
This is a small thing, but it's kind of weird -- Python almost always
allow you to interchange lists and tuples, whenever interchanging them
makes sense.
I'm willing to write more about this and give more examples, as well
as contribute code, if others agree that these changes would be an
improvement.
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]
