Opened 11 years ago

Last modified 10 years ago

#6476 new defect

Pidgin adds --display to the wm's session information, breaking remote terminals.

Reported by: gdvieira Owned by: deryni
Milestone: Patches welcome Component: pidgin (gtk)
Version: 2.4.3 Keywords:
Cc: marga


Ticket #3137 adds a change that activates the --display option to the wm's session information.

As such, a session saved with this option can only be restored in the same display. This breaks if I restore a session in a alternative virtual terminal or in a terminal in another machine. As a result, pidgin never restores whith the rest of the session when I change terminals.

Checking all the programs saved in my session, pidgin is the only one adding --display to its session information.

The patch from ticket #3137 should be reverted.

Change History (10)

comment:1 follow-up: Changed 11 years ago by rekkanoryo

Reverting the patch will do more than simply solve your problem. It will also have the effect of no longer restoring pidgin to the correct display when the correct display is not the window manager's default. I don't believe we should be so quick to do this.

comment:2 in reply to: ↑ 1 Changed 11 years ago by gdvieira

Replying to rekkanoryo:

I don't believe we should be so quick to do this.

Absolutely! Let's ponder carefully the situation.

As of Sept 2007, Pidgin worked perfectly in my setup. I could save a session in a terminal, and restore the same session in another, Pidgin (and Ekiga, and Nautilus, and Evolution) would all be restored. Around this time, another user discovered a problem with his multi-display setup ( He proposed a simple fix, that was quickly applied.

The problem is, his fix is my problem, and my setup that worked perfectly now is flawed. A regression I would say. I totally support a fix for his problem, after all I may one day have multiple monitors, but a fix that causes regressions should be reverted.

It's a shame that it took me so long to notice this, as I use Pidgin as packaged by my distribution. But, I noticied it now.

It's also a shame that I can't propose a solution to the multi-display problem. However, I believe that Evolution is probably multi-display aware and it doesn't use the --display option. By the way, no application in my desktop uses that option.

Please forgive me if the bug report and my reply seem combative, but I hope my point is clear now.

Abraços, Gustavo

comment:3 Changed 11 years ago by deryni

I think we need to determine if other applications do in fact work correctly in the multiple display case, and if they do (without including the --display argument) we need to see how they do that. Barring that, I think that given my understanding of your problem (the display from the saved session is no longer correct and as such prevents pidgin from restarting) the best thing we could do would be to check the display argument in the pidgin getopt code (an argument we are watching for already, because of a hack around gtk_init_check for how we initialize some things) and remove it when the named display doesn't exist. I'm unsure if that actually captures the semantics of session management that everyone will want, though I have to imagine it would.

comment:4 Changed 11 years ago by gdvieira

I understand. Unfortunately, I don't know how to support session support for multi displays desktops. Actually, I don't even know what's the user expectation about session save/restore in such systems.

What I'm proposing is to revert Ticket #3137, and find another solution for the problem reported there. Ask the developer who proposed the patch, he should be motivated to find a more general solution.

As a final plea for my case, see what Linus has to say on the subject:

"So we don't fix bugs by introducing new problems. That way lies madness, and nobody ever knows if you actually make any real progress at all. Is it two steps forwards, one step back, or one step forward and two steps back? Different people will give different answers."

comment:5 Changed 11 years ago by deryni

Given the patch that causes your current problem it would appear that at least one person has the expectation that windows restore to the display they were last on. Which may or may not be what your expectation is (assuming it doesn't fail when that display doesn't exist).

You and the reporter of #3137 are likely going to be equally motivated to find the correct solution (in fact I'd argue you might even be more motivated as you said pidgin doesn't even start for you, whereas for them it does and just needs moving).

But neither of those things is materially relevant to this discussion. And while it is all well and good to say "we don't fix bugs by introducing new problems" and that regression is always worse the question now is how long does a change have to have existed for it to stop being a regression. (The patch was in the 2.2.1 release which is just shy of 11 months old at this point.)

Ideally someone who understands (and uses) session management stuff would find an application that tries to store display data (or find something that indicates applications shouldn't do that) and we would have a correct answer. Barring that, someone could (as I suggested in one of my previous comments) attempt to detect whether the display being requested actually exists and remove the argument when it doesn't (during an sm startup) in our getopt code.

comment:6 Changed 11 years ago by deryni

  • Owner set to deryni

comment:7 Changed 10 years ago by marga

I'm experiencing the same problem as the original reported. 7 months have passed and nothing has been done.

Pidgin used to be restored correctly on people switching displays. Think for example of gnome's option to switch user, this option adds a new display, so, if user A is using :0, and user B is using :20 when they save their session, pidgin won't restore if they switch orders.

Or think of two computers that mount their homes through NFS, if their installation is the same, logging in to one or the other should be exactly the same, but not for pidgin.

However, keep in mind that the proposed solution mentioned (check if the display actually exists) wouldn't really work. It's perfectly possible that the display exists, but the user that is launching pidgin is not using that display

I think that this is a nasty bug, and I agree with the original reporter that fixing a bug by breaking the system for other users is not a nice thing to do. The fact that time has passed (more time has passed now) only means that more people will get affected by this bug.

As the original reporter said, no other application does this. All the other applications that I use (evolution, xchat, gnome-terminal, etc) get restored correctly without having to stick a stupid "--display" to them.

Please, please, fix this.

Thank you, Margarita Manterola.

comment:8 Changed 10 years ago by deryni

Pidgin used to restore correctly for people for whom the display information changed and used to restore incorrectly for people who had it on non-primary displays. A patch was submitted to fix the latter bug, unfortunately it broken the former working scenario. A fix that covers both cases is what we really need, and what I asked for the last time I commented on this. Someone who actually uses and understands session storing/restoration needs to figure out how this is supposed to work (for both cases) and make pidgin do that.

Nothing has been done because (as far as I know) none of the developers use session restoration and thus we are not affected by this and are unable to test it and no one who does use it and thus is affected has come up with a solution which covers both cases.

Checking that the display exists would entail checking (to the best of our ability) that said display is the user's active display (I have no idea if this is even something that can feasibly be detected, I know we can test if the display is usable by the user but that isn't the same thing).

This is a nasty bug, and fixing it by breaking restoration for users (like the creator of the patch in #3137) who run pidgin on secondary displays is not a viable option (by your own logic mind you). Had we known about this breakage when the initial patch had been submitted we would likely not have applied it as-is, however we didn't and it has now been in place for a year and a half which (as far as I am concerned) places it squarely into the status-quo category.

Do any of the other applications you mention work correctly for the restore-to-secondary-monitor case? The case that motivated the patch in #3137 in the first place? Have you tried them? If they do in fact work for both that case and this case then please let us know so we can check to see how they handle it.

comment:9 Changed 10 years ago by bernmeister

Maybe set this to Pending...

comment:10 Changed 10 years ago by deryni

  • Milestone set to Patches welcome

This is a real bug and deserves a real fix, as such moving to Patches Welcome.

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!