Re: GtkClist signals and double click
- From: "Timothy M. Shead" <tshead k-3d com>
- To: gtk-list gnome org
- Subject: Re: GtkClist signals and double click
- Date: Sat, 05 Aug 2000 00:33:00 -0700
Vlad Harchev wrote:
>
> On Fri, 4 Aug 2000, Salvador Ramirez wrote:
>
> Hi,
>
> > Hi,
> >
> > I would like to know why the double click event is not implemented
> > as a signal in some GTK+ widgets? I tried to make a GtkClist in which
> > the user could select a row either with a simple selection and then
> > pressing a button and with a double click over the row. It would be
> > far simpler to connect a supposed "double_click" signal with the same
> > callback (for example) connected to the button. But as this is not
> > so you have to connect the "button_press_event" with a more complex
> > callback where you have to ask for some other low level events (as
> > explained on the GTK+ FAQ).
>
> As for non-existance of "double-clicked": it's obvious that double click
> consists of two clicks, so in case of supporting "double-clicked" signal all
> mouse clicks would have to be handled with a doubleclick delay (in order gtk
> was able to determine what click it was - single click or double click). As I
> understand, gtk developers decided that this was not the right thing to do (I
> think they were right too).
In the widget's "button-press-event" signal, the GdkEventButton*
argument has a field named "type" that can be tested for the constant
GDK_2BUTTON_PRESS, which indicates a double-click. Of course, you still
have to deal with the first click - expect the following events when the
user double-clicks:
"button-press-event"
"button-release-event"
"button-press-event" with GDK_2BUTTON_PRESS set
Tim
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]