Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#5521 closed defect (invalid)

gtk_window_present unreliable for showing buddy list on tray icon click

Reported by: gagern Owned by: deryni
Milestone: Component: pidgin (gtk)
Version: 2.4.1 Keywords: tray icon, kde, gtk, focus
Cc: markdoliner


On KDE 3.5.9 with low focus stealing prevention, clicking the tray icon seems to have no when the buddy list is visible on a different desktop and task icons from other desktops are not shown. I would expect the buddy list to be displayed on the current desktop.

I had investigated this issue, traced it to gtk_window_present and found out this didn't work as I would have expected from the docs. Consequently I filed a bug with gtk which you might wish to monitor:

Recently that bug has been marked depending on a lengthy discussion about the intended behaviour for GNOME. It looks like the current behaviour of KDE will stay and be implemented in GNOME as well, and they are not what Pidgin would want for presenting its buddy list.

There is also some mentioning of a "show/hide trick" that might be better suited than gtk_window_present for what pidgin wants to do. As the rest of the discussion sounds like pidgin was a special cornercase, fixing the issue in Pidgin instead of the window managers might be the pragmatic solution, no matter what the standards say.

Also notice ticket:2968 pointing out that one can change the configuration of KDE to disable focus stealing prevention for pidgin, either the whole application or individual windows. The result of this, however, is that a click on the buddy list will change desktop, not move the pidgin window to the current desktop.

This ticket here is both a request to implement a blist display on the current desktop, no matter how you do it (although I'll attach a patch that seems to work well enough), but also to collect these links in one pidgin-related location for your information.

Attachments (1)

5521a.patch (683 bytes) - added by gagern 11 years ago.
add hide-show-deiconify to pidgin_blist_set_visible

Download all attachments as: .zip

Change History (9)

Changed 11 years ago by gagern

add hide-show-deiconify to pidgin_blist_set_visible

comment:1 Changed 11 years ago by datallah

  • Component changed from winpidgin (gtk) to pidgin (gtk)
  • Owner datallah deleted

comment:2 follow-up: Changed 11 years ago by deryni

  • Owner set to deryni
  • pending changed from 0 to 1

pidgin is not generally in the business of hacking around broken window manager policies, which is exactly what this patch is doing. The documentation for gtk_window_present is exactly what pidgin wants to have happen. Specifically it "[p]resents a window to the user" which "may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user's platform, window manager, and preferences". The issue here is that metacity has a policy you don't like, a policy that they admit doesn't work in all cases (possibly only not in the case of pidgin and other IM clients). The point here is that pidgin is doing the right thing and hacking around the metacity policy decision for gtk_window_present will explicitely disallow any other window manager from doing anything more intelligent on a tray icon click. It is exactly this policy-in-the-hands-of-the-application that the ewmh is supposed to help alleviate/prevent.

The only bug here is that metacity is a minimalistic window manager and that is therefore doesn't allow per-application/per-window policy decisions.

comment:3 in reply to: ↑ 2 Changed 11 years ago by gagern

  • pending changed from 1 to 0

I would agree that Pidgin is following the standard in using that GTK function and expecting it to behave as its documentation says, excepting the fact that the newer gtk_window_present_with_time would be more appropriate and better suited to cooperate with focus stealing prevention techniques.

However, it is not just metacity where this is an issue, but also Kwin (where I encounter it daily), and it is not only me being annoyed by this, but also people from RedHat bug 371161. Some comments on GNOME bug 482354 sound like they would expect a different behaviour for Pidgin as well.

Although I'm all for configurability, I'm also for sane defaults, meaning that users shouldn't have to reconfigure their WM in order to get the behaviour most people would expect. The clean approach might be some clarification or even extension of the EWMH specification, which reads a lot less certain than the gtk_window_present documentation at the moment. Depending on the direction of that change, either WMs or Pidgin might require changes.

I currently fear that Pidgin will forever claim to be doing the right thing, and WMs will keep current behaviour and state that other behaviour is easy to implement with a trick like this patch. That scenario should be avoided at all costs, and some direct dialogue between Pidgin devs and WM devs might help, instead of users like me passing bits of information around. So maybe you want to directly comment on those GNOME bugs?

comment:4 Changed 11 years ago by deryni

  • pending changed from 0 to 1

In order for pidgin to be able to use gtk_window_present_with_time it would need to be wrapped in an #ifdef block as pidgin is currently intended to be compatible with versions of GTK+ as old as 2.0.0 (at least in theory). Also, for the record, at this point gtk_window_present just calls gtk_window_present_with_time anyway with GDK_CURRENT_TIME as the timestamp; so I don't believe there would actually be any gain to using the newer call explicitely.

It doesn't matter where this 'issue' occurs, the fact is this isn't a pidgin issue. The heart of the matter is that pidgin has never had an intended policy for what *should* happen when someone clicks the tray icon; all pidgin wants is that the window be made available to the user (how that happens pidgin doesn't care). So ascribing to pidgin the belief that clicking the tray icon *should* mean moving the pidgin buddy list to the current workspace or the belief that the active workspace should be changed to the workspace with the buddy list is incorrect. A belief in either of those directions is entirely one that the user possesses (and that the window manager enables).

The fact that your desktop environment and/or window manager have changed what they interpret gtk_window_present (and the _NET_ACTIVE_WINDOW hint) to mean isn't a problem for pidgin, because pidgin doesn't care what they choose. You, the pidgin and de/wm user, care; and it is up to you to use a window manager that does what you want it to do.

There is no "behaviour most people would expect" for things like this, not as far as I can see. In fact there are two *very* specific comments in redhat bug 307581 which indicate that most of the people involved think applications should *never* switch workspaces (comment 6 and 12), which is exactly the feature you are asking for here. It is that very disagreement which is the problem (combined with the fact that metacity does not allow the user a great deal of freedom in controlling how it handles specific cases, kwin was supposed to be better at this but maybe not better enough). My window manager for instance allows me to have ignore _NET_ACTIVE_WINDOW for most windows and to control what it does for the windows I want it on for (on a per-window per-application basis).

Even if there was a "behaviour [that] most people would expect" in this case it would be the job of the window manager to do it correctly as pidgin would still be using the right function call (because pidgin still only wants the window presented).

The text of the EWMH states that _NET_ACTIVE_WINDOW is to be used when "a Client wants to activate another window" which is exactly what pidgin wants to have happen. It specifies nothing about what activating that window means and it is very clear that the window manager is free to ignore this request (and should use DEMANDS_ATTENTION in that case). So again, the issue here is that you dislike the way that metacity and kwin interpret "activat[ing] another window" and not something pidgin is doing wrong.

Hacking around the metacity/kwin policy decision is *not* a solution. Because, among other reasons, it enforces that policy decision on *all* window managers and removes the ability for the window manager and user to decide what action to take (not to mention disallowing the window manager from ignoring the request by forcing the showing of a new window thus triggering any focus stealing prevention code that might be in place).

When reasonable people disagree it is time to let them choose, I believe both of the above-mentioned behaviours are reasonable responses to the _NET_ACTIVE_WINDOW hint and should therefore both be allowed. In order for that to be possible pidgin needs to continue to use it and window managers that don't allow the user enough control need to either be fixed (which isn't likely to happen to metacity or kwin) or they need to stop being used by the people for whom they have stopped working.

No window manager developer should ever suggest that an application do anything like what this patch does to work around a wm policy decision. I am more than willing to discuss this with anyone who wants to discuss it with me, that being said I really don't think there is anything to discuss. pidgin is doing what it should be doing, your window manager is interpeting that in a way you don't like and doesn't give you a way to change that. This is entirely in their court to fix or make possible, or your court to cease using their software.

I would like to apologize if any of the above came off insulting or sounding mean, that was not my intention. I would also like to apologize if the above was overly redundant. This (and similar issues) are very tricky in a number of ways and I don't always think that the people behind the more recent EWMH additions and the policies/changes/decisions in metacity/kwin that they came from have thought things through all that well. In this case I happen to think _NET_ACTIVE_WINDOW is rather well designed and as such that pidgin is doing exactly what it should be.

comment:5 Changed 11 years ago by trac-robot

  • pending changed from 1 to 0
  • Status changed from new to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:6 Changed 11 years ago by rlaager

  • Status changed from closed to reopened

comment:7 Changed 11 years ago by rlaager

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:8 Changed 11 years ago by MarkDoliner

  • Cc markdoliner added
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!