Confirming the issue of not being able to get rid of indicator-messages apart from uninstalling it system-wide, but not agreeing with stuffing the menu with another item just for solving this. IMHO Indicator-messages should be de-/selectable in Startup Applications preferences (like indicator-multiload for instance is).

According to an answer on Ask Ubuntu [1], blacklisting all message-providers should hide indicator-messages altogether, but this doesn’t seem to work in 12.04, apparently because status-providers (which are different from message-providers) are still using the menu. (U1 Control Panel also seems to still occupy it despite being blacklisted.)

I’ve even tried overriding indicator-messages’ dbus service file with a hackish solution [2], but the envelope still insists on appearing (though without the associated menu).

* [1] http://askubuntu.com/a/15616/34756
* [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544483#42

There are many windows that would benefit from having the maximize button available but don’t. I produced snapshots of the history window, the ’Downloading Package Information’ window and the ’Mark additional required changes’ window. IIRC, the downloading packages and installing packages windows are also affected, though I couldn’t produce snapshots of those right now without installing sh… numerous packages I don’t want. Software sources is also affected, I guess that should be marked separately.

All these windows tend to have huge listings in them, and scrolling through those listings in cramped space is difficult. They’re already resizable (as they should be), so why not allow easy maximizing as well?

Seems to happen every time I update package listings now, right after all downloads have finished. It doesn’t prevent upgrading however, because if I restart Synaptic after the crash, all the listing updates have been applied and downloading the upgraded packages doesn’t crash Synaptic.

I just had the brightest idea. Two actually:
1. Make the launcher fill itself automatically with the most frequently used apps.
2. Make the launcher infinite in size so that you could (theoretically, should you want to) scroll down to every app you’ve ever launched that the infrastructure knows of.

==Severity==
I’ll elaborate on the justification below based on my use case. Depending on whether it’s a common or a less common one, this report is to be read as severity ’wishlist’ for a system default or an optional feature (an add-on or whatever they’re called in Unity-land).

==Justification==
The way I currently seem to be intuitively using the launcher, manually, is to stack it with apps I use most, with the most used one on top and less used ones descending according to use-frequency down from there.

This is at least an implicit, sometimes explicit [1] use case for the launcher, and something at which computers are by nature better than humans. So why not make the launcher do this automatically?

* [1] https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes#Ubuntu_Netbook_Edition

==Requirements==
Sometime in the past (see Bug #893214), the dash seems to have had a ’most frequently used apps’ category, apparently based on Zeitgeist. So the basic infrastructure for this should already exist.

==Affected==
I’m filing this against unity-2d-shell, since that’s what I’m using, but I suppose this applies to 3D as well. Ayatana might be the abstract-level target.

@jsalisbury: Alright, thanks. I’m running 3.3.0-030300rc4-generic now. Let’s see how it works out!

This happened to me just now. I killed u2d-shell, because it was rendering wrong already: it left a white vertical column when hiding, obscuring the view to the app underneath. When it restarted, the launcher was only 7,5 icons high (looks like Lohith’s screenshot, though slightly higher). Neither of these symptoms have occurred prior to this.

A new `killall unity-2d-shell` fixed the issue for this session.

Forgot to mention I could reboot after the crash with Alt+PrtSc+REISUB (if that matters).

A crash that threw me (from the desktop) into the console to show the Oops. Hasn’t happened before as to my knowledge, looks different from bug #917668 (which I’m affected by), but similar to bug #886706 (and bug #495322), but kernel bugs are too much out of my league to tell for sure.

Wasn’t doing anything specific that I could reproduce this with currently. At least Chromium, Transmission and Rhythmbox were active during the time.

Syslog has some data, I’ll attach it manually if apport doesn’t bring it in automatically.

I’ll happily do further testing and/or log uploads at request.

@jsalisbury: On this setup, there were seemingly similar freezes before Precise (I was using Lucid until then), but being so far apart and without a reliable recipe for reproducing, I mostly just ignored the issue. To give a clue as to the rarity, an (again seemingly) similar freeze happened just now, for the first time since I reported the bug, so if it’s the same issue, it’s been in hiding for over a month.

Unfortunately the logs didn’t have anything about this crash, and I couldn’t ssh in either. As I have yet to gather any substantial data apart from the little I posted above, there’s no way of knowing whether it’s always been the same issue or not. The symptom on the surface has always been very similar, but I guess that’s true for most freezes are even if brought on by unrelated causes.

I’m not afraid of testing the mainline kernel per se, but I’m hesitant because with this occurence rate, wouldn’t I be trying to prove a negative? Would 2 months without the issue constitute a ’kernel-fixed-upstream’? 6 months? Also, should I install v3.3-rc2-precise as you suggested, or the more recent 3.3-rc4-precise now? If the more recent one, should I then stick to it, or keep upgrading as new mainline kernels are built?

After upgrading Unity to 5.4, the launcher regularly gets stuck on the side despite being set to hide automatically both in Appearance settings and dconf. It does hide initially as it should, but then eventually no longer does and just stays there on top, blocking that part of the app underneath it. It usually then freezes after some time, then crashes and restarts, after which the autohide again works for a while. Before the freeze it does otherwise work save for the autohiding.

This is the report generated from such a crash. I have a feeling the freezing/crashing can be triggered by scrolling the launcher contents (when it’s in the ”stuck” mode).