Opened 10 years ago

Last modified 9 years ago

#8692 new defect

purple_conversation_present doesn't seem to work

Reported by: darkrain42 Owned by: sadrul
Milestone: Component: pidgin (gtk)
Version: 2.5.5 Keywords:
Cc: jsravn, andrikos, praveenmarkandu

Description

pidgin_conv_present_conversation doesn't seem to actually present the specified conversation. The window is raised, but the specific tab isn't focused.

This was reported by cszikszoy (Chris Szikszoy) in #pidgin.

Assigning to sadrul because he committed [8634151bc256a59e79f8e27bac91eea90a4cd9e8] which contains the comment

+       /* Switch the tab only if the user initiated the event by pressing
+        * a button or hitting a key. */

Change History (12)

comment:1 Changed 10 years ago by darkrain42

And, to explain, he wants to use it to open a conversation and switch to it via dbus in gnome-do.

comment:2 Changed 10 years ago by sadrul

Disclaimer: I have no idea what gnome-do is.

The window-manager takes care of focus-stealing in the window-level, so if we are working on some other app (e.g. gedit, for whatever reason), and a _conversation_present call is made, the conversation window is not given the focus. But this doesn't work when we are writing a message in a conversation, and a _conversation_present call is made for a different conversation in the same window. It would be an unexpected behaviour if we change the tab at that point. So essentially, that piece of code is there to prevent focus-stealing in a tab-level.

pidgin_conv_present_conversation should (and I believe does) work if, for example, you double-click on a buddy in the buddy-list, because in that case the call to purple_conversation_present is made from a user-event callback.

This probably is a 'wontfix', unless there's a way to pass on the user-event from gnome-do to pidgin.

comment:3 Changed 10 years ago by jsravn

I recently ran into this issue. The use case I have is that the user intentionally wants to focus on a tab. For example, from the perspective of XMPP:

  • Typing /join room, I expect to get focus, but it opens a tab in the background.
  • Custom plugin that opens IM or chats when clicking on links generated in the chat message. It will not focus the new IMs and chats despite purple_conversation_present being called.

My humble opinion is that your previous change broke the contract provided by purple_conversation_present. We need some way to be able to focus tabs if we want to.

comment:4 Changed 10 years ago by darkrain42

sadrul:

gnome-do works via dbus and only in response to user input.

I agree that, for almost all situations, stealing the focus of the active tab isn't the right thing to do, but I also think there should be a way that other programs (in response to a user's input) can raise a specific conversation.

comment:5 Changed 9 years ago by andrikos

There is a bug associated with this behaviour with the pidgin-hotkeys plugin as explianed here: http://sourceforge.net/tracker/?func=detail&aid=1869956&group_id=121046&atid=689096

Any suggestion on which is the correct way to deal with it? Thanks!

comment:6 Changed 9 years ago by deryni

Anything that directly calls pidgin_conv_present_conversation should be able to call pidgin_conv_window_switch_gtkconv I believe, which is as "correct" a solution to this problem as I can imagine. I realize that this leaves core-only plugins at a loss currently but I can't see a good way to make this work (that doesn't entirely remove the focus stealing preventions we were attempting to provide, as much as I hate them, or that doesn't make the prevention so easy to avoid as to effectively remove the protections entirely).

The issue is that pidgin cannot control the calls to pidgin_conv_present_conversation but does feel that we shouldn't allow things to steal the conversation focus from users by doing so. So, we only focus the actual tab when we can tell that the user has explicitely requested the focus change. I'm not sure I agree with this policy (it feels very much like the focus stealing prevention code in window managers, like metacity and kwin, that I despise) but other than simply always moving the conversation focus the only other options are even more complicated.

comment:7 Changed 9 years ago by andrikos

So I see two ways to solve this: a) Call pidgin_conv_window_switch_gtkconv from where pidgin_conv_present_conversation is called b) Make sure that the check

if (gtk_get_current_event_state(&state))

(in gtkconv.c:2983) passes.

The first is easier but seems more liek a hack, what would it be done for the second to work?

comment:8 follow-up: Changed 9 years ago by deryni

Right, those are the currently available solutions to third-party code. a is less of a hack as it is perfectly valid use of the pidgin api, potentially abusive use of the api if you don't know your users really want their focus moved, but valid use all the same. b is significantly more of a hack (as it would likely require poking at GTK+ internals or manually simulating user mouse/key activity) and I'm not even certain that it is possible as I'm not familiar enough with that GTK+ function to know what it looks at offhand.

So, actually, we already allow any GTK+ plugin/code to circumvent our focus stealing prevention code at will we just don't let core plugins/code do so. This seems rather silly. I think we probably need to yank the protection and fix whatever places were causing issues to not call present_conversation (so nothing non-user initiated should ever call it).

comment:9 in reply to: ↑ 8 Changed 9 years ago by darkrain42

Replying to deryni:

I think we probably need to yank the protection and fix whatever places were causing issues to not call present_conversation (so nothing non-user initiated should ever call it).

Do you (or anyone) recall what those issues are?

comment:10 Changed 9 years ago by sadrul

At least one of the issues was botched focus after [auto-]joining IRC chat rooms. If an autojoin happens while typing in a different conversation, some of the typed text goes to the newly joined chat window.

There was also a case where focus would go to the entry-box in an unfocused tab (if the [auto]-join happened there, or if someone sent a message in that tab).

But as far as I remember, these bugs were relatively difficult to reproduce.

comment:11 Changed 9 years ago by sadrul

If we are still at least a couple of weeks from the next release, then I suggest we undo the changes in question and see if we still hit any focus issues (I would rather not change the behaviour if we don't have enough time to test its effects before a release). If some focus issues do pop up, there might very well be better solutions than this. Any objections?

comment:12 Changed 9 years ago by deryni

Yeah, the issues were all "focus-stealing" related. The wrong input area focus bug still happens with new tabs (at least it does to me on Windows, and I think we have tickets/reports about it) without this prevention code (though to be fair the prevention code may very well simply not be kicking in there).

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!