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.

@Derkman96 No, looks like we’ve discovered this hidden gem of movie history independently. :)

@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.

Leike on elokuvasta Manos: The Hands of Fate, jonka tekijänoikeudet ovat rauenneet. Tekijänoikeusvaateen tehnyt ”Dance all Day” vaikuttaa Googlen hakutulosten perusteella väärinkäyttävän vaatimusmenettelyä monien muidenkin kohdalla.

@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?