Opened 10 years ago

Last modified 3 years ago

#1458 new patch

Single click on system tray icon should launch contact list

Reported by: Swifty Owned by: datallah
Milestone: Patches Needing Improvement Component: winpidgin (gtk)
Version: 2.5.2 Keywords:
Cc: PeterLairo, Dawudd, haridsv, Erendur, ollie27

Description

Most of my system tray icons launch their application with a single click. Pidgin doesn't. It doesn't seem to do anything with a single click, so this is an opportunity waiting to happen!

Attachments (2)

docklet_single_click.diff (1.6 KB) - added by phroggie 10 years ago.
docklet_single_click_dotnine_2.10.6.patch (3.0 KB) - added by renatosilva 5 years ago.
modern patch extracted from dotninesoft.de

Download all attachments as: .zip

Change History (44)

comment:1 follow-up: Changed 10 years ago by datallah

  • pending changed from 0 to 1

Is this on Windows?

comment:2 in reply to: ↑ 1 Changed 10 years ago by Swifty

  • pending changed from 1 to 0

Replying to datallah:

Is this on Windows?

Yes, Windows.

comment:3 follow-up: Changed 10 years ago by datallah

This has been discussed before.

I really don't care either way, but I guess there are now some Vista Guidelines that imply that a single-click should "Display whatever users most likely want to see".

I'm inclined to make the single-click do what the double-click does now (if there are pending messages, display them, otherwise show/hide the Buddy List) and to make the double-click always show/hide the Buddy List.

comment:4 Changed 10 years ago by datallah

  • Component changed from pidgin (gtk) to winpidgin (gtk)
  • Owner set to datallah
  • Status changed from new to assigned

comment:5 Changed 10 years ago by lazybones

Single click to show and hide the buddy list would be very full. I like the idea.

comment:6 Changed 10 years ago by Zsolti

Yep, would be good to have the normal one click systray interface!

Changed 10 years ago by phroggie

comment:7 Changed 10 years ago by phroggie

I certainly agree. The attached patch should fix this all up.

comment:8 in reply to: ↑ 3 ; follow-up: Changed 9 years ago by phroggie

For reference from msdn docs, the order of events we'd receive for a double click are: WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDBLCLK, WM_LBUTTONUP.

Replying to datallah:

I'm inclined to make the single-click do what the double-click does now (if there are pending messages, display them, otherwise show/hide the Buddy List) and to make the double-click always show/hide the Buddy List.

I agree with this, but can only think of two feasible ways to achieve this, given the order of events listed earlier, and limited time googling:

Option 1) Have the single-click callback wait GetDoubleClickTime() milliseconds before doing it's thing. In testing, even with an ultra quick double click speed on a fast machine, this seems really slow.

Option 2) Immediately process the first WM_LBUTTONUP, then undo it's effects when we receive a WM_LBUTTONDBLCLK and ignore the next WM_LBUTTONUP. I see this as rather sub-optimal, and would absolutely despise the dancing windows.

I strongly dislike both options, and think that the best way to use single clicks in the docklet is in the attached patch (single click and double click are treated the same).

comment:9 Changed 9 years ago by rlaager

  • Milestone set to 2.5.0
  • Type changed from enhancement to patch

Daniel, can this be applied or rejected?

comment:10 Changed 9 years ago by datallah

I was hoping for a better solution than the one attached (that would make the double click function differently).

comment:11 follow-up: Changed 9 years ago by rlaager

So should we mark this Patches Needing Improvement, or is phroggie right (that this is the best we can do)?

comment:12 in reply to: ↑ 11 ; follow-up: Changed 9 years ago by tdfs

Replying to rlaager:

So should we mark this Patches Needing Improvement, or is phroggie right (that this is the best we can do)?

How about this: when a WM_LBUTTONUP is detected we wait a few milliseconds (the time of a doubleclick). If doubleclick comes we go for it, otherwise, if we go in timeout we go for the single click action. Nobody will care about waiting a few milliseconds. What do you think?

comment:13 in reply to: ↑ 12 Changed 9 years ago by tdfs

Replying to tdfs: Ooops, this seems opting 1 suggested by phroggie. Ok... but i don't understand why that should take a lot...

comment:14 Changed 9 years ago by datallah

  • Milestone changed from 2.5.0 to Patches Needing Improvement

comment:15 follow-up: Changed 8 years ago by PeterLairo

Could someone please change the version to 2.5.2?

Is there a "target" or "priority" for this bug? This seems an easy fix for something users use frequently (i.e., every day).

Does the owner "datallah" still exist?

PS. What are "keywords" and where are they defined / explained?

PPS. Are there any plans to use better bug tracking software, like Mozilla's Bugzilla (http://www.bugzilla.org/)?

comment:16 in reply to: ↑ 15 Changed 8 years ago by datallah

  • Version changed from 2.0.1 to 2.5.2

Replying to PeterLairo:

Could someone please change the version to 2.5.2?

It doesn't really matter, but sure.

Is there a "target" or "priority" for this bug? This seems an easy fix for something users use frequently (i.e., every day).

No, there is no target or priority, and as you can see in the comments above it isn't necessarily an easy fix.

Does the owner "datallah" still exist?

Yes, but note the "Patches Needing Improvement" milestone which means that someone interested needs to submit an improved patch.

PS. What are "keywords" and where are they defined / explained?

They are just searchable criteria; there is no formal definition.

PPS. Are there any plans to use better bug tracking software, like Mozilla's Bugzilla (http://www.bugzilla.org/)?

No, we don't consider that better, it is far too complicated. Trac is perfectly fine for our uses.

comment:17 Changed 8 years ago by rlaager

Daniel: Why do you feel it's necessary for double-click to always open the buddy list? I don't think Pidgin behaves that way on Linux and I don't see the need. If that requirement were removed, could this patch be accepted?

comment:18 Changed 8 years ago by datallah

As I mentioned earlier, I don't feel too strongly about this, but I don't necessarily think there is any value in changing the current double-click to a single click.

comment:19 follow-up: Changed 8 years ago by PeterLairo

Value of single-click access:

  • single-click is only half the clicks of a double-click
  • Single-click is more discoverable (many users don't ever double-click)
  • Single-click currently has no function
  • There is no more important function than opening/closing the buddy list that the single-click needs to be reserved for
  • The taskbar items typically serve one of two functions: (A) to show the status of some program, or (B) to quickly access some common feature (e.g. volume). Opening the buddy list falls into category B.
  • It's silly to have to double-click when the single-click has no function. It seems like it's unnecessarily cumbersome. Poorly designed.

comment:20 in reply to: ↑ 19 Changed 8 years ago by Zsolti

Fully agree, thank you for the great summary.

comment:21 Changed 8 years ago by deryni

As a point of reference, of the applications I currently have in the notification area in Windows XP at work, none of them create or show a window on single click, most of them show a menu or do nothing. This includes a minimized process manager, the volume icon, the removable device icon, the power status icon, the Outlook icon, and a virus scanner.

A quick poke at a colleague's Vista machine indicates that the same is true (for most of the above icons) on Vista and in fact that a number of them may even do less on single click than their XP versions (for example the network status icon presents a dialog on single click in XP and presents a tooltip-style window in Vista).

Given that I would think we should likely cause the context menu to appear on single click as opposed to the buddy list or conversation window.

comment:22 follow-up: Changed 8 years ago by PeterLairo

The vast majority of your example programs either do little more than to show the status of some program (category A in my previous post), or provide inferior UI. None of those programs are an instant messenger. Take a look at Google Talk - one click to open & close the buddy list!

The context menu is activated via the RIGHT button. That's standard.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 8 years ago by Zsolti

or Miranda.

(and for a clear counterexample: Skype.)

comment:24 in reply to: ↑ 23 Changed 8 years ago by Swifty

Replying to Zsolti:

or Miranda.

(and for a clear counterexample: Skype.)

Just to add my side of the discussion:

EditpadPro: Lanches EditpadPro window
3m Postit Notes: Creates a new note
The Wonderful Icon: Opens menu of choices
Yankee Clipper II: Opens the application
Microsoft TimeZone: Shows defined timezones
Google Talk: Opens the application
AllChars: Does nothing
Apache Monitor: Opens top level of a menu
Process Explorer: Opens the application
Alcohol 52%: Does nothing
MOZY: Does nothing
Netlimiter 2 Monitor: Does nothing
Lotus Mobility Client: Does Nothing
Thinkbroadband meter: Does Nothing
Symantec Client Firewall: Opens menu
Creative Volume Control: Opens the volume control
Windows Defender: Does nothing
Symantec Antivirus: Does Nothing

So 8 of 18 do nothing. 7 of the 10 that do anything open up the most commonly used window belonging to the application.

I wonder what value people see in having a control which can respond to a single click, but which ignores it? For me, this is like those blank spaces on the dashboard of my car where, on a more expensive model, there is a switch that does something useful.

comment:25 Changed 8 years ago by rlaager

What does the attached patch actually do? I see it has some sort of double-click timeout that, from the diff, doesn't seem to do much.

comment:26 Changed 8 years ago by deryni

I don't think any specific behaviour here is better than any other behaviour. I do think we should try to do what is 'standard' or suggested.

As to the list of applications you provided Swifty, my breakdown is that eight do nothing, five open a menu/tooltip/direct-access control, and five open a window.

That puts pidgin squarely in the common case. I have no problem making pidgin display the context menu on single click (as long as that doesn't get in the way of what double click does now) and I don't really care if single click is made to show/hide the buddy list either. I just don't think the assertion that that is what pidgin *should* be doing has so far been backed up.

comment:27 Changed 8 years ago by rlaager

If we want to be able to both bring up the buddy list window and bring up a context menu, I'd say that right-clicking is the clear obvious choice for context menus. That leaves single click or double-click for bringing up the window. Vista apparently recommends single click and we do single click on Linux. I see no reason we shouldn't make this match our current Linux behavior: single click = open (active conversation or) buddy list, right-click = context menu.

comment:28 Changed 8 years ago by deryni

I see no reason to have the same behavior across operating systems for no other reason that consistency there if the operating system standards suggest otherwise. That being said, given that we probably should do something on single left click, and likely can't reasonably do something both on single and double left click (and even if we could it would be confusing), and that Vista seems to suggest we do something 'useful' on it, I'm not against making this change in theory.

I will say I think our policy of either focusing a conversation window or opening/displaying the buddy list depending on the current state of things is a bad one, and one I wish we didn't have.

comment:29 Changed 8 years ago by lazybones

Isn't Pidgin one of the only windows IM clients that DOESN'T do something useful on a single click?

If we are going to compair just any tray apps, here is the list on the current spare laptop I am using today under windows XP.

  • Outlook 2003 - Context menu
  • java update - Dialog
  • Virusscan - nothing
  • Windows Wireless - Dialog
  • Windows update - Dialog
  • Sound - Volume Dialog
  • Safely remove Hardware - Context
  • Intel Wireless - Context

1/8 do nothing on a single click.

comment:30 Changed 8 years ago by deryni

Yes, as I said, that is probably something we should fix (on Windows) if Windows guidelines currently suggest that tray icons do something on single click.

And the volume slider is not a dialog, it is all but a context menu.

comment:31 Changed 8 years ago by Gibbz

is this still going to be added? ive been wating for this for years :S

comment:32 Changed 8 years ago by deryni

This blog post has relevant information about the way Windows applications should handle this sort of thing.

comment:33 Changed 8 years ago by owenjm

I've been following this ticket for a while. As a linux user who's forced to use Windows at work, I greatly miss the ease of bringing up my buddy list with a single-click, and clearly several others feel the same way. To me, at least, it seems intuitive that left-clicking on a tray icon should do *something* ... otherwise, you're just wasting the left-click functionality.

But surely, if the left-single-click currently does nothing under windows, all one needs to do to make everyone happy is to have left single and double-clicks behave the same way. (I'm assuming that nobody randomly single-clicks on the pidgin icon for no purpose!) If both single and double-clicks on the tray icon can be detected by the toolkit, a double-click could be safely ignored and all single- and double-clicks on the tray icon will show the buddy list, to everyone's satisfaction.

And even if the Windows toolkit can't detect double-clicks (surely not!) a check to ignore another left single-click (i.e. the second click of a double-click) if it occurs, say, 500ms after the first would solve the problem.

Either way, those who want to double-click to show the buddy list can do it their way, and those who want to single-click to show the buddy list can do it their way ... what's not to like?

comment:34 Changed 8 years ago by velectronic

I can't believe really! Developers sleep or what? So necessary and easy to implement functionality not implemented over years! Oh My GOD! Why stupid and hard double-click open buddy list? Double-click should be changed to some less frequently operation. Single-click shoild be show/hide buddy list.

Developers, read little about HCI plz before implementing some new software again: http://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction

comment:35 Changed 7 years ago by Tobsen1981

Hi, I have the problem on my blog: http://blog.schmidt-tobias.de

comment:36 Changed 7 years ago by Erendur

Hi,

I created a hack for this problem inspired by the code above. Also the buddy list focus/on top problem is handled in my release. Changed windows pidgin.dll and source code included.

Features:

  • Single click on the pidgin system tray will open/close the buddy list like a double click
  • Single click on the pidgin system tray will close the buddy list if already focused or on top (full visible)
  • If the buddy list is hidden by another window, a single click on the system tray icon will bring it to the top

You can use my compilation or use the hack solo. It is also possible to build your own binaries with the changed sources.

Blog: http://www.dotnine.de
Single click hack: http://pidgin.dotninesoft.de

comment:37 Changed 6 years ago by datallah

Ticket #13553 has been marked as a duplicate of this ticket.

comment:38 in reply to: ↑ 8 Changed 5 years ago by renatosilva

As phroggie said, a double click timeout for single click callback could be annoying as well. Also, when both events are handled, single click should not disturb a possible double click event (for example focusing a GUI control), which is not possible for this bug. Therefore, responding to a single-click while ignoring next WM_LBUTTONUP messages within next GetDoubleClickTime() milliseconds, just like original patch, is the way to go.

This is the kind of thing that is only as irrelevant as dumb.

Last edited 3 years ago by renatosilva (previous) (diff)

Changed 5 years ago by renatosilva

modern patch extracted from dotninesoft.de

comment:39 Changed 5 years ago by renatosilva

I have extracted a patch from Erendur's 2.10.4 version and attached as above. According to my checks it should work in 2.10.6, but I haven't tried it myself.

comment:40 Changed 5 years ago by renatosilva

Related: #6331

comment:41 Changed 5 years ago by renatosilva

Last edited 3 years ago by renatosilva (previous) (diff)

comment:42 Changed 3 years ago by renatosilva

I have implemented this in my custom version of Pidgin. Feedback is welcome. Thanks to phroggie and Erendur for the patch.

Last edited 3 years ago by renatosilva (previous) (diff)
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!