Christian Reis wrote:
It is my approach of event-driven applications. There is only one
responsible callback to show the dialog.
See, I don't understand what you mean by this. Why can't you have a
method called show_dialog() which is called by N different callbacks?
One of them could be a do
Christian Reis wrote:
On Tue, Apr 01, 2003 at 12:37:16PM +0200, Herr Maik HERTHA wrote:
I played a little bit without sense and found that the following
combination does work, but I don't know why? I put the signal
propagation in a idle-hanlder and it works.
idle_add() just makes your cal
/Hi Guys;
Hope I solved my problem and somebody could me explain why.
I have a button_press_event connected with a connect_after to a clist.
The callback should have a look if there is an already selected row and the
event was triggered by a left mouse double click. If so it raises a signal
to po
On Tue, Apr 01, 2003 at 06:07:29PM +0200, Herr Maik HERTHA wrote:
> >However, in your case I honestly don't think this complication is at all
> >justified. If all you want to do is pop up a dialog window on
> >double-click, why don't you just check double-click, select the row your
> >event object
On Tue, Apr 01, 2003 at 12:37:16PM +0200, Herr Maik HERTHA wrote:
>
> I played a little bit without sense and found that the following
> combination does work, but I don't know why? I put the signal
> propagation in a idle-hanlder and it works.
idle_add() just makes your callback run when the GT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
>
> On Fri, Mar 28, 2003 at 08:29:45AM +0100, Maik Hertha wrote:
> > > Really? Can't you just use connect() and return True
> when a double
> > > click is performed (event.type == gtk.gdk._2BUTTON_PRESS)?
> > >
> > Then I need a little assistanc
On Fri, Mar 28, 2003 at 08:29:45AM +0100, Maik Hertha wrote:
> > Really? Can't you just use connect() and return True when a double
> > click is performed (event.type == gtk.gdk._2BUTTON_PRESS)?
> >
> Then I need a little assistance. The current situation is:
> - - the double-click propagates a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Maik Hertha wrote:
> >But, if the default handler do so, why I can have a
> >w.connect_after('button_press_event', cb ) and the signal is
> triggered
> >for middle and right button pressed signals an not for the
> left button
> >pressed signal
Maik Hertha wrote:
:: It sets the signal return value to the value returned by the last
:: handler. It then decides whether to continue the emission if the
return
:: value is False.
:: >>Most uses of stop_emit_by_name() can be converted to simply do
"return
:: >>True" now. You hardly ever n
:: It sets the signal return value to the value returned by the last
:: handler. It then decides whether to continue the emission if the
return
:: value is False.
:: >>Most uses of stop_emit_by_name() can be converted to simply do
"return
:: >>True" now. You hardly ever need to manually stop
Christian Reis wrote:
Can the class handler be run multiple times, then, if both _LAST and
_FIRST are set, for instance?
Yes, but they seldom do (I am not sure if any of the signals in GTK do so).
What are signals with return types?
Integer, boolean, etc. The type of the value returned by the s
On Tue, Mar 25, 2003 at 10:10:32PM +0800, James Henstridge wrote:
> >How does connect/connect_after relate to the `position' of the callback
> >in the list of handlers? Does connect() connect *before* the
> >GtkTreeView's `default' signal handler (can I call it default?) and
> >_after(), after? Wha
Christian Reis wrote:
On Fri, Mar 21, 2003 at 10:31:13AM +0800, James Henstridge wrote:
Stephen Kennedy wrote:
Plain "connect" works fine, but the "connect_after"
callback does not get called.
Or am I doing something wrong? See attached example.
For the standard widget event signal
On Fri, Mar 21, 2003 at 10:31:13AM +0800, James Henstridge wrote:
> Stephen Kennedy wrote:
>
> >Plain "connect" works fine, but the "connect_after"
> >callback does not get called.
> >Or am I doing something wrong? See attached example.
>
> For the standard widget event signals, a custom accumula
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> >The difference to the 0.6.x code is, that I include the return
> >statements in the functions with FALSE. If I do a
> signal_connect I get
> >a deadlock situation with the dialog window which is called via
> >Set_options_button.clicked().
> >
Maik Hertha wrote:
The difference to the 0.6.x code is, that I include the return statements in the
functions with
FALSE. If I do a signal_connect I get a deadlock situation with the dialog window
which is called via
Set_options_button.clicked().
Could it be a bug anyway ?
The behaviour was i
> For the standard widget event signals, a custom accumulator is set.
> When going through the list of handlers to call for the signal, the
> process goes like this:
>1. call handler
>2. if it returned True, skip the rest of the handlers in
> the list and return True
>3. otherwise,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Answer from Christian Reis
>
> Plain "connect" works fine, but the "connect_after"
> callback does not get called.
> Or am I doing something wrong? See attached example.
There might be a default handler that is returning TRUE somewhere that is runnin
Stephen Kennedy wrote:
Plain "connect" works fine, but the "connect_after"
callback does not get called.
Or am I doing something wrong? See attached example.
No bug here.
For the standard widget event signals, a custom accumulator is set.
When going through the list of handlers to call for t
On Thu, Mar 20, 2003 at 09:06:53PM -, Stephen Kennedy wrote:
>
> Plain "connect" works fine, but the "connect_after"
> callback does not get called.
> Or am I doing something wrong? See attached example.
There might be a default handler that is returning TRUE somewhere that
is running after y
Plain "connect" works fine, but the "connect_after"
callback does not get called.
Or am I doing something wrong? See attached example.
Stephen.
---
[EMAIL PROTECTED]
http://meld.sf.net#!/usr/bin/env python
'''Tree Model Test
This test is designed to demonstrate creating a new type of tree model
21 matches
Mail list logo
