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

Se on kokonaan pois päältä. Se on Bloggerin asetuksissa, uudessa Bloggerissa ’Muu’-välilehdellä, ”Salli blogisyöte” -kohta. Siinä pitäisi olla ”Täysi”. Vanhan Bloggerin vastaavasta asetuksesta olen onneksi kirjoittanut jo kauan sitten, niin säästyy sanoja tässä. :)

No johan, olen näköjään missannut melkein kuukauden postaukset täältä. Oletko ottanut syötteen pois päältä tarkoituksella?

Then I would rephrase this into a bug report as follows: currently, the toolbar navigational buttons (previous, next) are positioned to the right from the location bar. This is inconsistent with what most users probably expect, which is the way they are located in a web browser.

The three web browsers I currently have installed on this system position these elements as follows:

1. Epiphany 3.2.1: previous, next buttons above the left end of location bar.
2. Firefox 9.0: previous, next buttons to the left from location bar.
3. Chromium 15.0.874.121: previous, next buttons to the left from location bar.

From my personal anecdotal evidence, with this background, I say suddenly finding the navigational buttons from the right end of the location bar in one app is undly arduous. Thus this bug’s title should be: Move the navigation buttons to the left of the location bar.

(IIRC this was also how the buttons were back in Gnome 2. If there was some usability reasoning behind moving them to the right, I’d be interested in reading about it.)