Determine if / how we should switch workspaces when focusing Thunderbird

Note that this issue is still also unsolved in evolution

Well,
in my opinion it is perhaps not the best idea to cite Evolution and argument that a requested feature in not implemented in Evolution, too. If you want the feature list of Evolution as your personal guideline, then perhaps you should think about the fact that Exchange support is still not present in Thunderbird. Still, hopefully Thunderbird will replace Evolution.

The fact that Evolution has a specific feature or rather, as in this case, the fact that it has NOT the given feature is not in any way an argument for not implementing this feature in Thunderbird.

It is highly confusing to click on an menu entry and nothing is happening. Furthermore, clicking on the launcher symbol of Thunderbird will always focus the Tbird window. Why not the same about the Messaging Menu entry?

Is it so hard to imagine what a normal every day user will expect from clicking on a menu entry? Well, I hope we agree that this normal user will at least expect *some* reaction when clicking on the entry. Doing nothing is certainly never the best way for offering a menu entry.
Certainly, there is the possibility to create menus with dozens of entries which all will do nothing, but hopefully this is not the intention here. One entry which sometimes does not react when clicked is already producing enough confusion.

Sorry, for being sarcastic here, but after the long and not very fruitful discussion in bug 733349 I am not in the mood anymore to discuss about things which, in my opinion, clearly have to be changed because normal human reasoning demands them to be changed. And pointing at another software's set of feature does not make my mood much better, because simply Canonical employees are not considering this line of argumentation valid I do not consider it valid, too. I mean saying "in software A or operation system B we also can find this feature", seemingly is no argument at all for Canonical employees. So please do not try to bring up this form of argument again. I suppose I will not be the only Ubuntu user who will get very angry when hearing this argument; especially after the way Canonical treats requests like the one mentioned in the bug above.

I never said it shouldn't be implemented, so I'm not sure why you assumed that we were using the fact that this doesn't work in Evolution as justification for not fixing it in Thunderbird. I just noted that the problem has never been solved in Evolution, and AIUI this is because of technical reasons rather than not wanting to fix it. For starters, there is nothing exposed from GTK (or in other toolkits AFAIK) that allows applications to switch workspaces. Individual applications either need to understand the EWMH spec (using something like libwnck) and gain the functionality to select workspaces themselves, or the default behaviour of the window manager(s) need to be changed to do this automatically when an application sends a _NET_ACTIVE_WINDOW message (this may have other consequences, but I'm not a WM expert). The first option is WM-specific, depending on whether the particular WM uses viewports (compiz) or virtual desktops (metacity).

> It is highly confusing to click on an menu entry and nothing is happening.

Well, something *does* happen right now, even if it's not ideal. Currently, the WM visualizes this in the same way as it would for an application that sets its urgent hint - in Unity, this results in the launcher icon wiggling, it's arrow turning blue and the blue triangle in the top-left corner of the screen appearing. In classic GNOME, it results in the Thunderbird icon in the taskbar flashing.

> Furthermore, clicking on the launcher symbol of Thunderbird will always focus the
> Tbird window. Why not the same about the Messaging Menu entry?

When you click on the launcher, the shell is responsible for focusing the application and changing the workspace (ie, Unity). When you click in items in the messaging menu, these actions are handled directly by the application rather than the shell, so the application becomes responsible for directly manipulating the window manager.

In future, please avoid jumping to incorrect conclusions and then posting rants on bug reports. Rants like this aren't really welcome here, and if you wish to do this then there are other avenues for you to do so which are less disruptive to our work (ie, posting in forums)

>In future, please avoid jumping to incorrect conclusions and then posting rants on bug reports. Rants like this aren't really >welcome here, and if you wish to do this then there are other avenues for you to do so which are less disruptive to our work (ie, >posting in forums)

I suppose "rants" are never welcome that is why they are called "rants".

My problem is what happened to bugs like 668415 or 733349. If you want public support to find bugs, then give people a fair treatment and deal with their problems as if you took them for serious. If you are a developer working for Canonical then try to deal with your colleagues and solve this issue (i.e. the way requests by more than 100 people are treated; see the bugs above). If you do not want comments to Canonical's way to deal with their users' responses then do me a favour and close Launchpad for the public: make it only accessible to employees of Canonical.

I never said that your comment asserts the bug will not be fixed. I only stated that I am annoyed by the fact that you referred to another software were the feature is not implemented either. If looking at different applications/software were a real argument for or against the implementation of a feature, then bug 733349 should be discussed again. In bug 733349 pointing out that the requested feature exists in every other OS but Ubuntu (with Unity), was seemingly no argument at all. Thus I think it is time to stop to treat those, who work for Canonical and those, who do not, differently if it comes to rate the importance of bugs and if it comes to discuss if a bug should be fixed or not. The normal users help you find usability issues, they help you to find bugs and they help you to save your time in searching the sources of these bugs (at least by pointing at specific symptoms of the bugs). Furthermore, we are the ones who use your software.
During the last 4 years I got two university departments to use Ubuntu as their Desktop OS, I got one company to use it as their main desktop OS and I convinced about 40 people to use it a the OS of their choice for their PC at home. I am the one who supports those home PCs. If I have an issue with features in Ubuntu at least part of these 40 people will have an issue too, because very often they point me at the issue at the first place. I suppose I am not the only one who helped to install PCs at some users' homes. Many of those posting bugs here will do so. Some only speaking for three or four people others for many more.

The problem I described in this given bug (808777) confused at least three people. All of them talked to me individually about the menu entry which sometimes does not work as they expect ( it does not work as I, myself, expect).

Besides that: if Toyota has a problems with their on-board computer which calculates the number of miles per hour wrong so that you always drive much faster than the display shows to you, then it is not funny to point out that Mercedes has the same problem in their new cars and that they have not solved the issue either. Nobody at Toyota would come up to the press and say "well, we know that there is an issue and will talk about how to fix it...

Can we please keep discussion focused solely on solving the problem? Long posts about unrelated things just adds noise and makes the bug tracker a less useful place to discuss the actual bug

Sam, what are your thoughts on this? This is a problem with everything in the messaging menu currently. It seems that compiz deliberately blocks focus if the window is on another workspace (if my understanding of PrivateWindow::isWindowFocusAllowed is correct), but then, this doesn't work in Metacity either...

Is there a reason for doing it like this, or could we change it? If not, is there a way we can work around it in Thunderbird? (and Evolution, Gwibber etc...)

> Well, something *does* happen right now, even if it's not ideal. Currently, the WM visualizes this in
> the same way as it would for an application that sets its urgent hint - in Unity, this results in the
> launcher icon wiggling, it's arrow turning blue and the blue triangle in the top-left corner of the
> screen appearing. In classic GNOME, it results in the Thunderbird icon in the taskbar flashing.

Actually that's not what I'm experiencing. The only effect of clicking on an unread folder entry is to
just clear that entry. It also decreases Thunderbird's unread badge icon in
the Unity launcher, from the same number of messages the entry accounted for. This all makes perfect
sense, the only missing part is focusing Thunderbird when it's on another workspace (which is, I believe,
a pretty common setup)

For some reason, this commit appears to fix this bug in compiz: http://bazaar.launchpad.net/~extension-hackers/messagingmenu-extension/trunk/revision/103

I've honestly got no idea why window.focus() causes the workspace to switch though, but it seems to work :/

Actually, scratch that. It does fix it if there are no windows on your current workspace, which I guess is still an improvement

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".