[Pidgin] #5521: gtk_window_present unreliable for showing buddy list on tray icon click

[Pidgin]

#5521: gtk_window_present unreliable for showing buddy list on tray icon click
---------------------------+------------------------------------------------
  Reporter:  gagern        |       Owner:  deryni                    
      Type:  defect        |      Status:  new                       
  Priority:  minor         |   Milestone:                            
 Component:  pidgin (gtk)  |     Version:  2.4.1                     
Resolution:                |    Keywords:  tray icon, kde, gtk, focus
   Pending:  1             |  
---------------------------+------------------------------------------------
Changes (by deryni):

  * pending:  0 => 1

Comment:

 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
 [https://bugzilla.redhat.com/show_bug.cgi?id=307581 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.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/5521#comment:4>
Pidgin <http://pidgin.im>
Pidgin