Open apps (even basic system ones) can still be missing from Alt+Tab

[Mathieu L BOUCHARD]

After five years of Unity, it is still possible to have discrepancies between those three lists :

1. apps that are really open

2. apps that are marked as open in the dock

3. apps that are switchable from Alt+Tab

First bug : I just noticed that the Software Update app appears in (1) and (2) but not in (3). This also means that it's not possible to switch between its windows using Alt+backtick.

I report this as a bug in Unity instead of Software Update because I believe that this is a more general problem that affects several apps. I don't know Unity's APIs, but if apps are asked to report themselves so that they appear in the dock and Alt+tab, and if it's easy to get it wrong, then various apps will get it wrong, possibly even system ones (see also my other bug report, which is about menubars). But if ever it doesn't work that way and it's already fully centralised, then it's a bug in Unity anyway.

I distinguish the lists (1) and (2) because it's possible that they be different, and it could be considered as two other bugs if you will. Those problems happen more systematically instead of seeming like random mistakes in various apps' source code.

Second bug : it's possible and easy for an app to add one question-mark dock icon per window. This seems to be the default behaviour in Tcl/Tk, as the PureData app does this for every "patcher window" (document window) that is open (it doesn't happen with properties windows (though they're nonmodal) because they are marked as belonging to a specific document, so that Alt+tabbing to that document brings a group of windows at once.

Third bug : an app can have an icon associated to it but have the dock unable to figure out that the matching app has been launched. For example, if I launch PureData (/usr/bin/pd) from the dock or the app search, the "Pd" icon shows up blinking and looks like PureData is taking a long time to launch or has crashed during launch, but meanwhile (and very quickly) PureData's main window pops up and appears in the dock as a question mark. If I open PureData from a Terminal instead, I get no PureData icon and only the question mark icon. This whole problem could have a toolkit-specific solution (set the icon from the app instead of from a launch item) but it could also have a global solution involving an ability to get the name of the executable of the X11 connection that opened the app (obviously, it wouldn't work with remote X11 apps, but those are rare, so it would be ok). It would have to check for child processes, though, as PureData's gui is a child process of /usr/bin/pd.

I also stumbled upon that bug when making a launch item for a specific Windows app. When clicking on that app in the dock, the dock added a WINE icon to itself instead, and failed to recognise that the icon I had clicked on was for an app that had completed launching (it kept blinking, and the triangle did not appear there, because it appeared next to the WINE icon instead).

[Mathieu L BOUCHARD (matju)]

I had actually chosen a more general title than that (something like « Dock and Alt+tab can still have discrepancies about open apps (even basic system ones) »).

However, I did so in the 2nd form while writing the description, and Launchpad ignored it, and instead it took the original title I wrote in the 1st form. And now I can't even edit it. This looks like a bug in Launchpad (but I'm not in a position to confirm that bug without posting a dummy bug report... please, someone, report it for me, if you can test it).

[Mathieu L BOUCHARD (matju)]

By a strange coincidence, I just found a fourth bug, and I'm sure I've never seen this before. I started /usr/bin/mplayer from commandline, which opened a window (with default -vo setting), and it became listed as a window of /usr/bin/firefox in both Alt+Tab and Dock. It didn't happen again. You will probably not be able to reproduce it easily (I've never seen this despite doing this over 1000 times since I first installed Unity), but that's normal, that's the case of many race-conditions, and this looks like one. There is often no other solution than just reading source code to make sure it does no mistake about locking or atomicity (whatever happens to be needed in that area of the code).

In contrast, the second and third bugs (see description above) have happened systematically for years. For the first bug, I don't know, it's harder to notice.