Optionally start pidgin minimized

[Tim.]

Please add the option to start Pidgin minimized to the system tray.
This could either be added as a commandline parameter or as an option
under preferences.
This way one can use an operating system's ability to run Pidgin
- minimized to the system tray - on startup, eliminating the need
to manually minimize Pidgin each time the system restarts.
( Low priority, non-critical, but well-appreciated.. =) )

[nosnilmot]

Pidgin will start minimized to tray if it was minimized to tray when it was last exited. Isn't this sufficient?

[Tim.]

Though this works when I don't reboot in between closing and restarting Pidgin, it appears that at least on my setup (Pidgin 2.0.2 on Ubuntu 7.04) this behavior does not extend past a reboot..
It would be nice if Pidgin would return to starting minimized past a reboot aswell..

[nosnilmot]

Pidgin's behavior certainly doesn't change depending on whether you rebooted or not, but I suppose it's possible it could take longer to embed in the system tray when only just started or something like that.

There's also the Buddy List Options plugin available in the Plugin Pack that will allow you to force hiding the buddy list when it is initially created always, irrespective of whether it was showing when piding was exited.

[brettatoms]

I start Pidgin from my Gnome session startup programs to automatically start when I login. For me Pidgin doesn't start minimized regardless of its state when I reboot. I have a feeling the problem is that Pidgin starts up before the task bar's notification area finishes loading which means that Pidgin doesn't have a place to dock itself. Just a hunch.

[Tim.]

it appears that Pidgin maximizes just before closing under Gnome in Ubuntu Linux 7.04 (other versions not tested).. It could be that this behavior sets the closing-state to maximized, and thus makes Pidgin start maximized every time..
This occurs when selecting Quit from the sys-tray..

Can anyone have a look at this?

[Creak]

Replying to nosnilmot:

Pidgin will start minimized to tray if it was minimized to tray when it was last exited. Isn't this sufficient?

It works when Pidgin is launched manualy, but if it's done at GNOME startup, it doesn't work. I just wanted to say that it's the same in Ubuntu 7.10 Gutsy Gibbon. Anyone has a clue?

[dawg]

Place the following code into /home/yourAccount/bin/pidgin_tray, then change the command for the Pidgin startup item in sessions from pidgin to pidgin_tray:

#!/bin/bash # Wait for notification-area-applet to load before starting Pidgin

while true; do

if [ $(pgrep notification-ar) > 0 ]; then

pidgin; break;

else

sleep 1;

fi

done

[dawg]

Note that the formatting was changed when I posted the above code. For it to work properly, you will definitely have to enter a return after #!/bin/bash

[Creak]

I don't see any 'notification-ar' in the 'ps aux' output. The closest thing I have is 'notification-daemon'. But I'm under Ubuntu 8.04 now, maybe it has changed since. But I'm still wondering why all the other programs are loaded without any problem in the tray while pidgin if directly linked to the init process (as I can see with the 'pstree' output):

init─┬─gdm───gdm─┬─Xorg
     │           └─gnome-session─┬─bluetooth-apple
     │                           ├─compiz─┬─compiz.real
     │                           │        └─gtk-window-deco
     │                           ├─evolution-alarm───{evolution-alarm}
     │                           ├─gnome-panel
     │                           ├─gnome-settings-───{gnome-settings-}
     │                           ├─nautilus
     │                           ├─nm-applet
     │                           ├─python
     │                           ├─rhythmbox───7*[{rhythmbox}]
     │                           ├─seahorse-agent
     │                           ├─tracker-applet
     │                           ├─trackerd───2*[{trackerd}]
     │                           ├─update-notifier
     │                           └─{gnome-session}
     ├─gnome-terminal─┬─bash───pstree
     │                ├─gnome-pty-helpe
     │                └─{gnome-terminal}
     └─pidgin───{pidgin}

I cut a bit of the output, but you see the idea...

[dawg]

I don't see it in 'ps aux' either, but then again, I don't know anything about that command. I'm quite new to Linux :-)

If you are running Gnome, your "tray" is a process named notification-area-applet. You can see it in System Monitor. "notification-ar" just happens to be the first 15 characters, which is what pgrep needs to find.

[Creak]

Well it works, but with this test instead: [ $(pgrep gnome-session) > 0 ]. But I still think it's a workaround, you can't ask anyone to write a shell script to make it running as he would like.

[dawg]

Agreed, but I believe this is a really the result of a bug (or lack of intelligent functionality) in Gnome. In either case, I hope the developers here may add a small bit of code, like that above, to compensate for the problem.

[Garret]

Also with the script when i put this in gnome-session when my pc starts pidgin don't start minimized.

[Creak]

Replying to dawg:

Agreed, but I believe this is a really the result of a bug (or lack of intelligent functionality) in Gnome. In either case, I hope the developers here may add a small bit of code, like that above, to compensate for the problem.

If it's a Gnome problem, why all the other programs (like rhythmbox for example) do work? Halas, I'm not good enough at this to know where it come from :/

Replying to Garret:

Also with the script when i put this in gnome-session when my pc starts pidgin don't start minimized.

You're right... It was because I launched Pidgin manually that it worked on the second launch. I tested it too quickly, sorry. I'll retry with all the "notification-area-applet" stuff.

Stay tuned! :)

[Garret]

I tryed also with alltray program but nothing(also with -na and/or -nt option).

I thought that maybe if the pc is shutdowned with a pre-command like "killall -9 pidgin", then when the pc boots up pidgin should start minimized. I don't have tryed.

[Creak]

I've noticed that when I shut my pc down, pidgin always pops up for a brief moment... Like if the "quit" message was forcing pidgin to show on the desktop. And the fact that the last status of the window is "visible", maybe it'd explain why it's also visible at boot?

[dawg]

"If it's a Gnome problem, why all the other programs (like rhythmbox for example) do work? Halas, I'm not good enough at this to know where it come from :/"

Unless you have a different problem, it is only an issue that occurs at startup. It occurs when Pidgin loads faster than the notification-area-applet (after startup, the notification-area-applet is already loaded). You should notice that the Pidgin window appears before its icon in the notification area, and in fact, if you hit the close button before the icon appears, the program actually quits.

[Creak]

Replying to Creak:

Replying to Garret:

Also with the script when i put this in gnome-session when my pc starts pidgin don't start minimized.

You're right... It was because I launched Pidgin manually that it worked on the second launch. I tested it too quickly, sorry. I'll retry with all the "notification-area-applet" stuff. Stay tuned! :)

Well, I confirm that my code works well when I simply disconnect. Moreover, the pstree output shows that pidgin is a child of the gnome-session process. But it seems that there is still a problem when I reboot...

[Creak]

Ok, the script isn't really working... I commented out all the lines except the one launching pidgin. The pstree is still the same (pidgin is under the gnome-session process), and pidgin still doesn't work properly with Gnome.

Is there a developer here that could see this problem? It doesn't seems that Gnome is the only one to blame for this behavior.

[Creak]

I noticed that the buddy list is always showing up when exiting Gnome. Like if the signal sent by Gnome to the programs forced the buddy list to show up. Does anyone know which signal it is?

[marvanek]

Im on Ubuntu 7.10 and had the same problem with Pidgin not starting in sys tray. The Skript shown above didnt work for me either. But I discovered another solution.

1. I installed a pidgin plugin called pidgin-extprefs with synaptic. It has an option which forces Pidgin to start minimized.

2. I wrote a mini shell skript to be certain pidgin starts AFTER the notification-area-applet has been started:

#!/bin/bash sleep 20 pidgin

saved it under ~/pidgin-tray(somewhere in my home directory) , made it executeable with chmod

3.then I made my skript autostart on startup in System ---> settings ---> sessions

It works fine now, no matter if Pidgin was or wasnt closed minimized before.

Best regards Marvanek

[Garret]

@marvanek: It doesn't work for me :(

[Garret]

Ok i tryed to varying the sleep time and now it seems to work :)

[Creak]

Well... This is not really a solution coz it depends on the computer perfs... I'll try it though, I'm bored with this window always opened. :)

[Tim.]

Looking back at these two messages:

I've noticed that when I shut my pc down, pidgin always pops up for a brief moment... Like if the "quit" message was forcing pidgin to show on the desktop. And the fact that the last status of the window is "visible", maybe it'd explain why it's also visible at boot?

I noticed that the buddy list is always showing up when exiting Gnome. Like if the signal sent by Gnome to the programs forced the buddy list to show up. Does anyone know which signal it is?

Could a possible fix lie in determining the source of this last-minute popup?

[Creak]

I think it'd be the best solution to clear it out. But unfortunately I don't have the time to understand all the pidgin code, even though i'm interested in it.

[karl]

Same in KDE. The BuddyWindow? opens briefly when shutdown and Pidgin always starts with that window open. I did not try the script yet but think that fixing is a much better solution.

[intersol]

I would consider this an implementation bug not an enhancement. Pidgin is always open the buddy window that is hide after 1-2 seconds and this is very annoying also it does change the focus.

[deryni]

Has it been determined that the issue here is not just that pidgin is starting up faster than the nofication area is starting and as such cannot remain hidden because no notification area icon can be created? If that is the problem there isn't much pidgin can really do about that. If something else is the problem then there is something that can be looked in to.

[Creak]

Well, even if it's that, there is no explanation why all the other applications (e.g. like Transmission which is far lighter than Pidgin) can launch in the notification area without any problem while Pidgin is the only one that can't do it properly.

Now, I think it's Pidgin that must be watched, not all the other applications, don't you think?

Does all the other applications wait until the notification area is launched? I don't know, but I think that if it was the case, gnome developpers would have told us, no?

[deryni]

Other applications may very well have a longer period during which they are ok with not having a tray icon embedded and as such are not bothered by the delay. A longer timeout (or a second try) for pidgin may not be out of line but doesn't make the problem a pidgin problem either. Here's an experiment, try launching an application that you have set up to start up in your system tray (like Transmission) when you don't have the notification area enabled and running at all and see what happens. Does it start up and display the main window? Does it start and display the main window after a noticable delay? Does it start up leaving you with no window at all?

What Gnome developers would have told who that random applications wait for the tray area? I'm not sure what you were getting at there.

[dawg]

Ugh... this drives me CRAZY.

The script I posted above no longer works for me. I've spent a good part of today (okay, the WHOLE day (I'm a total loser)) trying to work out a solution. Nada.

I've found that the buddy list will OCCASIONALLY hide itself correctly, but almost every other time it pops up on the desktop.

Please take another look at this bug :-/

[dawg]

This might be useful information:

I've done some testing by adding a new panel with a second instance of notification-area-applet. When I boot, it seems that whichever instance of notification-area-applet loads first is the one that actually gets used (when launching applications after booting, too), but that isn't the point I have to make...

I've found that if I remove the notification-area-applet from the new panel, the icons (Pidgin and Thunderbird) moved over to the other instance of the notification-area-applet. However, the buddy list window for Pidgin re-appeared! Thunderbird's window did not.

I thought maybe Thunderbird is just an exception, since I am using a plugin to get that functionality in the first place, so I decided to do more testing...

I re-added the second instance of notification-area-applet to the new panel and rebooted. Pidgin and Thunderbird are set to start with my Gnome session, so both icons appeared when I logged in (though, of course, Pidgin's window appeared on screen too, so I minimized it). Then I launched the following (list includes aforementioned pidgin and thunderbird): -rhythmbox -gdevilspie -gtk-gnuttela -transmission -opera -keepassx -pidgin -thunderbird

Then I removed the second instance of notification-area-applet. The result was that -- with the exception of pidgin, keepassx, and opera -- all of the tray icons moved to the other instance of the notification-area-applet and did not seem to be otherwise affected.

Pidgin's icon was moved, but as I said, the window re-appeared on the screen.

keepassx and opera both simply disappeared. Their icons did not show up and their windows did not appear. I suspect the issue with these two programs has something to do with the fact that (I believe) bother are qt programs as opposed to gtk.

Hoping this information might be useful in tracking the cause of this bug :-)

[deryni]

Can you get Thunderbird to have its window be unreachable if you remove the last notification area when the window is minimized to it? What about the other applications?

[dawg]

I tested as prescribed above, and Pidgin is still the only one to show re-display the window. I've found that if I re-add the notification-area applet after this test, all 8 show up again in the new instance of the notification area.

It should be noted that the notification-area-applet, if it ever crashes (I've only observed this by ending the process from System Monitor), immediately displays a dialog asking if you wish to reload notification-area-applet. Upon reloading, all but Opera were still accessible from the tray.

[deryni]

The question was not whether the applications re-insert themselves into the tray once you reload it, but whether once the tray is gone entirely if the applications main window is thereby inaccessible. pidgin was explicitly written so as to not allow the main window to be hidden when the tray icon is not available, the question is whether the other applications do that or not. A secondary question is whether pidgin correctly handles a disappearing/reappearing notification area.

[dawg]

I answered the question.

[dawg]

Further testing reveals that Pidgin does not(!) reveal its main window if the Window List is removed.

Trying to accommodate for any potential failure not practical -- particularly when accounting for these rare (but RECOVERABLE) cases causes a relatively common and highly visible bug.

[dawg]

^{note that above was tested with the tray icon disabled, if that wasn't obvious.}

[deryni]

You mean if pidgin is minimized normally and the window list is removed pidgin doesn't un-minimize the window? That, despite looking virtually identical to the notification area case, is in fact not the same. pidgin doesn't provide minimization functionality, the window manger does. It is therefore the window managers job to handle the fallout from that case. pidgin however does handle the notification area (it needs to support using it, whereas it doesn't need to support being minimized), and so pidgin does need to handle that case.

Assuming pidgin does correctly recover if the notification area disappears (for more than just a moment, that is for potentially minutes at a time) that does in fact largely mitigate the need for pidgin to redisplay itself when the area disappears (but doesn't remove it entirely). It also doesn't mitigate the fact that when the tray icon is gone pidgin would (without this feature) leave its main window entirely inaccessible, which is absolutely not an acceptable thing for an application to do.

Back to my request for an answer, your answer was that pidgin was the only application which forcibly redisplayed its window when the notification area was removed.

That fact is not necessarily the same as whether pidgin was the only application whose main window was still accessible at that point.

If they are in fact the same then that is fine, and I would argue that the behaviour of every other application is flat out broken as leaving the user with the inability to access the main window of the application because an entirely unrelated application crashed is simply unacceptable.

Note that none of this gets us any farther into why pidgin believes it can't use the notification area for you at startup, or why pidgin seems more sensitive to notification area removal than other applications (the more-than-one notification area case).

[dawg]

Well, if you want to get technical, then the answer is no. All of the applications were still "reachable." It might take 2 clicks instead of 1 to get to them, but they were indeed "reachable," per the component of my original answer which you apparently did not think was relevant to the question.

An entirely unrelated application? Really? That's ridiculous. What if xorg crashes? What if Gnome crashes? What if the computer crashes? What if some problem comes about with GTK? What if the screen goes blank? What if the mouse loses its battery? What if some crazed lunatic chops off my hands?

All of these circumstances could make Pidgin "unreachable," yet I doubt that all have been accounted for, and they shouldn't be if it causes a likely problem to avoid one which is unlikely, and, like I said, RECOVERABLE.

[Creak]

Instead of arguing about the answers, I think maybe it'd be better to test on your PC and see what goes wrong, no? I think the test dawg has done is easily reproducible. So deryni you'll see exactly what you need to see.

Actually, I'd prefer an application that behaves normally and doesn't recover in case of another application's crash (I would understand), instead of an application that doesn't behave normally but does recover in case of another application's crash. IMHO it's good to prevent from crash, but not if it adds strange behaviors.

[deryni]

Creak: I don't use Gnome, nor even have it installed. My desktop environment does not have a taskbar, only occasionally have a notification area, and does not minimize windows. So, no, I can't easily test this myself.

pidgin isn't preventing anything from crashes, it isn't (specifically) protecting against crashes. What it is attempting to do is ensure that the user is always able to reach the buddy list window. This is not something I think anyone has any problems with in theory. It is merely the current problem that dawg (and a number of other people) are having that is the issue.

dawg: I still do not understand your answer to my question. When the notification area is entirely removed while applications are minimized to it how do you get to the main windows of those applications? Could you please explain what two clicks are necessary for this for most of the applications? Are you suggesting that most applications sprout taskbar buttons when the notification area goes away? Are you suggesting that most applications are run-once applications and that thus running them again brings them to the front? What exactly? Keeping in mind that until recently pidgin had no run-once protection built in and that running more than one copy of pidgin at a time is a perfectly reasonable thing to do (so that causing further runnings of pidgin to focus the existing buddy list window is not always reasonable).

As an example of what I am looking for the answers for pidgin are that when the notification area disappears pidgin makes sure that the buddy list window is made visible so that it will appear on the desktop and in any window list taskbars that happen to exist. It does this because without that there would be no way to cause the buddy list window to reappear (barring the more-or-less recent introduction of code which detects instances of pidgin that are already running and requests that the existing instance display itself).

And yes, the notification area applet is entirely unrelated to pidgin. The notification area does not depend on pidgin, or in any real way even know that pidgin is pidgin and pidgin most certainly doesn't depend on the notification area or really know which of the myriad notification area applications are running.

pidgin does in fact depend on an X server being running, and does depend on your X session not crashing out, it does not depend on your specific window manager, or any window manager for that matter (it would run perfectly well on a naked X session, though interacting with the multiple windows would be a nightmare).

As I indicated before I run pidgin perfectly well in an environment without a taskbar, without a menu system, without desktop integration, and without a notification area. The specific interaction between applications and notification areas is greater than the specific interaction between applications and window listing taskbars.

There is nothing that can be done when applications that pidgin depends on disappear (X, GTK+, etc.), there is plenty that can be done when applications that pidgin interacts with disappear (the notification area, the window manager in general, a sound service, etc.). This is a distinction that matters.

I will say once again for the record, I do not like the fact that this protection causes you problems, I would very much like for it to be fixed, but I do not for a single instant believe that removing the protection is the right solution.

[dawg]

I'm not trying to be disagreeable, so please accept my apologies if I have come off that way. I am indeed trying to answer your questions.

I don't have access to my Linux box again until tomorrow night, so I can't do any further testing right now, but I can clarify what I thought I stated earlier--

If the notification-area-applet fails, for whatever reason, there will immediately display a dialog which asks the user whether they want to reload it. Upon clicking "OK" or "Yes," or whatever exactly it says, the notification-area-applet reloads immediately. So the two clicks would be: "OK"->Pidgin icon.

In order to test this functionality, users of gnome with the notification area can pull up System Monitor and end the process named "notification-ar." The tray will close, and before you probably even realize it's gone, the dialog will ask if you want to reload it.

Let me know if there are any other non-testing questions I can address right now.

Nate

[ghfjdksla]

Just show the main window minimized when the notification area is gone and move to the notification area when it is back.

btw, i think that this talk is of concern for this lengthy discussion:

How to protect an Open Source project from poisonous people

[ghfjdksla]

(I don't want you to use SVN and i don't think that there's something wrong with putting names at the beginning of source files. But the talk is very interesting.)

[dawg]

Replying to ghfjdksla:

Just show the main window minimized when the notification area is gone and move to the notification area when it is back. btw, i think that this talk is of concern for this lengthy discussion: How to protect an Open Source project from poisonous people

That sounds like a reasonable solution

[deryni]

Your answer avoids the main point of my question and sidesteps the reason for the feature, that explains why you didn't understand my point you were misinterpreting my question. Your specific notification area may offer that feature, but it may not always work, and other notification areas may not offer it. Imagine those cases where you are now left with no currently running notification area. How do you get to Thunderbird? rhythmbox? transmission? opera? pidgin?

This reappearing buddy list feature was specifically added so that in that worst case scenario the buddy list window is accessible. If those other applications have other ways of keeping their main windows accessible I would like to hear them, as they may be things we want to consider as well. If they don't, then we are back at my previous point. I think that is an egregious flaw and one that I am glad pidgin avoids.

I would like to likewise apologize if my comments came off sounding too strong. Hopefully this last set clears things up so progress can be made.

ghfjdksla: Yes, minimizing the window instead of displaying it normally is certainly an option, but it is a solution that dodges the main problem (the main problem being that pidgin seems to be more sensitive to this case than it seems it should be). And yes, as I said before determining whether pidgin correctly re-trays itself after an extended notification area absence is something that would be useful to know. At a guess I would say pidgin likely does not do that, though it likely could be made to do so.

As good as that talk is, it doesn't have much bearing on the current discussion because despite what it may have sounded/looked like neither dawg nor myself was being actively unhelpful (just incidentally so).

[dawg]

With due respect, I didn't sidestep anything. I answered the question as it relates to my own desktop environment and the testing you asked me to do. If you have a point, you say it -- you don't "ask" to try to get someone to say whatever point you want to make.

[q41]

Just minimize and close any window you want on system startup. Then go to Preferences > Sessions > Session Options tab and press Remember currently running applications From now on, when you log in, most Gnome applications, including Pidgin, will restore to their current state. Voilá

[bernmeister]

Can this ticket be closed off?

[deryni]

No, I need to re-read the comments so I can properly explain my position and ask the question I was asking in a way that will not again be mis-interpreted.

[drzoo2]

Not to beat an old thread to death but, I think to clarify what is being requested, it needs to work similar to skype.

With skype installed, go to preferences > general > tick "start skype minimized to the systems tray"

Logout and back in. Skype starts minimized to it's own tray with no other windows open. z