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.

I left an old netbook to do an ”apt-get -y dist-upgrade” overnight, and when I returned to it the next morning, the upgrades were unfinished because libc upgrade was waiting for me to respond to ”Restart services during package upgrades without asking?”

It looks like the question is prioritized depending on whether the upgrade is done on desktop or not, and if it’s not, the priority is set critical. According to documentation [1], critical is for ”Items that will probably break the system without user intervention.” I don’t think restart-without-asking satisfies that condition.

* [1] http://www.debian.org/doc/packaging-manuals/debconf_specification.html#AEN101

”Kyselyyn pääset tästä” -linkki on rikki, se viittaa jonkun jo täyttämän lomakkeen kiitossivulle. Linkin pitäisi ilmeisesti viitata osoitteeseen https://www.tem.fi/banner/112#, josta kukin vastaaja saa oman, uuden lomakkeensa. (Lisäksi suosittelen yleensä linkittämään siten, että linkitetyt sanat kuvaavat linkityksen kohdetta, ei ”tästä”- tai ”tämä linkki” -tyylisesti. Tässä yhteydessä siis esimerkiksi sana ”Kyselyyn” lauseesta ”Kyselyyn voi vastata 26. helmikuuta saakka” olisi luonnollinen kyselyn osoitteeseen linkitettävä.)

• Combined screenshot of the ”System program problem detected” and ”Application problem” dialogs (50.6 KiB, image/png)

The two dialogs are very, very inconsistent: the dialog icon they use (DIALOG_QUESTION in one, the DIALOG_ERROR in the other), the dialog window title (”Application problem” vs. none), the dialog title and explanation style (brief vs. verbose), the ignore option missing from one… It’s almost as if the engineers behind the two dialogs have intentionally tried to make them as different from one another as possible. (No offence intended, I just think it’s funny although it is a genuine accessibility problem as well.) Also, one dialog seems to be minimizable whereas the other is not — though this doesn’t appear in Blair’s screenshot; it may be something introduced in Precise which the system my screenshot is from is running.

I’ve specified three different specific cases to demonstrate what I mean by the title, below. I could have filed three different bite-sized bugs, but all in all I believe they are part of the generic accessibility problem with the ’Revert’ button that could be fixed in one go. (If the developers think otherwise, I’ll be happy to split this into different reports.)

When you first run Software Sources, ’Revert’ is ghosted as it probably should, implying no changes have been made that could be reverted.

Issue #1:
Steps to reproduce:
When Download from: is pointing at main servers, change it to something else and ’Revert’ becomes active. Now click ’Revert’, and main servers are restored as Download from: site.

What happens:
’Revert’ stays active, implying there are still changes left to revert. Clicking it does nothing of course, as all changes have just been reverted.

What should happen:
’Revert’ should become ghosted once pressed after becoming active.

Issue #2:
Steps to reproduce:
Point Download from: to your local mirror (other than main servers). Close Software Sources. Start it again. ’Revert’ is now ghosted, implying there are again no changes to be reverted. Point Download from: to a third mirror, and ’Revert’ becomes active. Click ’Revert’.

What happens:
Download from: now points to main servers.

What should happen:
I’d expect it to point to my local mirror, which was the initial state opening the window.

Issue #3:
Perhaps ’Revert’ wrt the Download from: site means not reverting back to initial state of this SS session, but reverting back to the very initial state of pointing to main servers. But in that case, ’Revert’ should *not* be ghosted when Software Sources starts with Download from: pointing somewhere else, as it just did.

I think it’s worse than just that the icon doesn’t convey the program’s purpose: it looks way too much like a flatbed scanner. I appreciate the difficulty in crafting a descriptive visual representation of a BT client, but IMHO an icon should at least be sufficiently unique so as to avoid mistaking it for other apps of completely unrelated purposes. That’s where Vuze’s frog for example is better (as long as you’re not into Frogger clones). I’ve been running Transmission whenever I’m logged in for years now, and I still occasionally wonder why I have a scanning app running, when in fact it’s just Transmission’s… I’m-not-sure-what-it-is.

I realize this is not a very constructive argument so long as I don’t have anything better to suggest in the current icon’s place, but I promise I’ll start thinking of one right now and hopefully come up with ideas some day.

Ah, it seems I am able to bring up the menu 100 % reliably on the M4A78-EM as well by hitting and holding the shift *immediately after firmware initialization screens* (Asus’ boot graphic and ATA Security eXtension). So holding shift from power-up or from the boot graphic screen won’t work in this setup, but seems to work with others (such as my FS laptop). I’d expect it to work from power-up consistently across different setups.

To be even more Precise: you *can* quit RB when it’s playing, but only by using Ctrl-Q or the corresponding Quit item from the menu. What you *cannot* do is quit RB when it’s playing by clicking the window close button, even if you *don’t use the indicator*.

To be sure, I removed the indicator-sound package so that indicator-sound doesn’t appear in my indicator area at all, and still, RB’s window closing button while playing music just makes the window disappear; the music keeps on playing.

With the broadly defined title that bug #526552 has, I don’t think it’s completely fixed yet: the specification says a ”player’s own settings interface should also have a checkbox for whether the player should be present in the sound menu”, and RB doesn’t have that. I see no no way to disable RB’s sound menu integration.

Jep, nyt toimii, kiva!

Kappas vain, kiitoksia! Jätän merkittyjen versioiden käyttöliittymän toistaiseksi pois päältä, ja kerron mikäli ongelmia ilmenee.