Usability enhancement request

This would probably be sort of free once we implement sane launch
notification, no?

(note: I'm actually the submitter of this bug - don't ask why it's
under a different email address. ;)

This doesn't really help the problem I'm describing - the behavior I'm
seeing doesn't seem to be because users don't see the app launching
instantly, they double-click because they don't understand they don't
NEED to do so - people are so trained on the "double click" method for
opening programs that they apply it everywhere.  This goes for the
panel, web links... just about everything.  It's just that in the
panel, it's especially obnoxious because it opens some apps twice when
users do this.

I think what Jens is saying is that the pannel buttons should be
"debounced" more than they already are.

I think currently the threshold is .5 seconds. If you click at t=0s
and then at t=0.51s, though, you'll get two launches.

I'm not sure of a good way to fix this. If that threshold gets up
towards one second, users actually trying to open a launcher twice (an
admitedly a rare occasion) would get an unresponsive panel.

(I think the solution is really to have consistancy so users dont'
worry about single versus double clicking. Also, having the mouse
cursor become a pointing finger over single-clickable items would make
the single-click affordance more clear.)

target should be bumped up to 2.6!

I think the debouncing threshold shouldn't be a fixed number like 0.5
or 1 second, but the threshold used in the rest of the system to
difference between a double click and two single clicks.

Currently, that is the number stored in 
gconf:///desktop/gnome/peripherals/mouse/double_click

That way you have consistence with the rest of the desktop i.e, the
desktop uses always the same criteria to difference double clicks from
click click.

Created attachment 21889 [details] [review]
Patch for this.

I liked the idea of using
gconf:///desktop/gnome/peripherals/mouse/double_click and I found it
reasonable, so here's a patch implementing this.

It works well for me.

Created attachment 21892 [details] [review]
Updated patch

Arvind made some useful comments, so I updated the patch.

I don't get it. gtk+ already respects this GConf key:

  + gnome-settings-daemon translates this into the 
    "Net/DoubleClickTime" XSETTING and gdk (see gdkevents-x11.c)
    maps this into the "gtk-double-click-time" setting.

  + gtk (in gtksettings.c) sets this value in gdk again with
    gdk_display_set_double_click_time()

  + if you get two single clicks within that time you get a
    GDK_2BUTTON_PRESS.

There should be some better way of doing this patch using all
this, right ?

Also, why no do this in ButtonWidget ?

I don't get it either. 

The global double click treshold is meant to differentiate between
single- and double click. This is useful for people who can't click
two times rapidly in succession.

However the problem here is completely different. Users are double
clicking *on purpose* in the expectation to activate a panel object.
The undesired effect is a double activation of the object. That is
what this bug is about.

Although this is debouncing as opposed to counting two clicks as a
doublie-click, I think the timeout should be the same. A user is
double-clicking exactly when two clicks in the same place are within
double_click. Basicly the solution to this bug is the patch that was
posted, which essentially allows panel launchers to accept single or
double clicks and only launch once. 

Simple note: forget my previous patch. There's already such a timer in
ButtonWidget. But it waits for 400 ms. This is what needs to be fixed:
it should not be hard-coded.

*** Bug 128389 has been marked as a duplicate of this bug. ***

Setting patch 21889 obselete, marking patch 21892 needs-work based on Comment #14.

Vincent: grepping through the gnome-panel/button-widget.c source code revealed
that there is no such timeout.
Where is it located, if it still exists?

regs,
 Chris

Created attachment 33201 [details] [review]
Updated patch.

Just for reference, I updated the old patch but it should not go in. I think
Mark is right and there's a better way to handle this.

Hrm...
Mark: AFAICT, the activate event happens on BUTTON_RELEASE.

According to the doc:
"
Double and triple-clicks result in a sequence of events being received. For
double-clicks the order of events will be:

   1.GDK_BUTTON_PRESS
   2.GDK_BUTTON_RELEASE
   3.GDK_BUTTON_PRESS
   4.GDK_2BUTTON_PRESS
   5.GDK_BUTTON_RELEASE
"

Is remembering the last *_PRESS event a better way to handle this?

This would be something like:
  if (type == GDK_BUTTON_RELEASE && prev_type != GDK_BUTTON_PRESS)
    return;

Created attachment 33203 [details] [review]
The good way to do this?

Ok, this would look like this. I can't test it so I don't know if it works.

Comment on attachment 33203 [details] [review]
The good way to do this?

This patch doesn't work. I'm confused because there are three events involved
(pressed, activated, clicked). Need to look at this when I'll have more time.

This is still an active bug. Although I change the mouse preferences dialogue
for a one-second double click timeout, I can still launch two instances of
firefox when I doubleclick on the panel. 

Setting GNOME version to 2.9/2.10.

Vincent: Why merging single click behavour, and double click behavior (which is
not actually exist) or even triple click is not enough? 

Fixed in HEAD.