OK, figured it out.
I was using
if event.state == gtk.gdk.CONTROL_MASK | gtk.gdk.MOD2_MASK:
and this worked under linux but not windows. When I changed it to
if event.state & gtk.gdk.CONTROL_MASK | gtk.gdk.MOD2_MASK:
if worked under both windows and linux.
On 07/06/2010 04:44 PM,
On 2010-07-07 13:26, Jason Heeris wrote:
> Tim Evans wrote:
>> GTK+ 2.14.4
>> PyGObject 2.14.2
>> PyGTK 2.12.1
>
> Mine is
>
> GTK+ 2.20
> PyGObject 2.21.2
> PyGTK 2.17.1
>
> A few things about your changes confused me -
>
> 1. You call glib.idle_add, but never called glib.threads_init - won't
> th
Tim Evans wrote:
> GTK+ 2.14.4
> PyGObject 2.14.2
> PyGTK 2.12.1
Mine is
GTK+ 2.20
PyGObject 2.21.2
PyGTK 2.17.1
A few things about your changes confused me -
1. You call glib.idle_add, but never called glib.threads_init - won't
this break on Linux?
2. You use BOTH gtk.gdk.lock and glib.idle_ad
Antoine Martin wrote:
> It means that most of your code is not using threads at all, only the
> bits that are *slow*
Those are the only bits that use threads anyway.
> I've lost track of your particular issue though, so maybe this is not
> suitable for your use-case? How much slow work do you do
I have this in my program
def on_window1_key_event(self, widget, event):
print event
It works fine under linux, the terminal prints out things like
I do other stuff with the key presses, but it works. When I try to run
the same program under windows, I get output like
On 07/06/2010 03:53 PM, Jason Heeris wrote:
> Antoine Martin wrote:
>> I don't know of any examples unfortunately and I must admit that I spent
>> quite a bit of time getting to grips with it, but in the end it is
>> remarkably simple (much more simple than I first thought too - so don't
>> let tha
Antoine Martin wrote:
> I don't know of any examples unfortunately and I must admit that I spent
> quite a bit of time getting to grips with it, but in the end it is
> remarkably simple (much more simple than I first thought too - so don't
> let that put you off):
> import gtk.gdk
> gtk.gdk.threads
Tim Evans wrote:
> Something worth noting is that if you're targeting Windows then 2.a. is
> your *only* option.
In fact, gtk.gdk.threads_init() will freeze straight off, you don't
need to wait for threads to start.
> I would also point out that "whenever it next feels like it" is almost
> always
