This was working for me during testing, but seems to have cropped up somewhere around release time. If I unmaximize all open windows, the left-side trigger works as intended, but at soon as I maximize one window, the launcher no longer appears no matter how hard I hit the left edge. Also, when this happens, Super just makes everything pale as if dash and launcher were opened on top, but they’re not. Doubly also, there is some gesture that makes things work again, but I have yet to pinpoint what exactly it is. (I just had it happen briefly after temporarily disabling autohide, but that alone wasn’t yet it.)

I’ve just hit the Oops (__ticket_spin_lock+0x9/0x30) with apw’s kernel. I’ll attach the syslog from after reboot to this comment. Had been running the apw build since Monday this week (7 days now) without problems.

Just to note here also that I’ve today switched to apw’s build of 3.2.0-23 [1] linked to from bug 922906. I had been running the upstream 3.3 for more than 7 weeks without hitting this (#917668). The GPU lockup I mentioned in #13 also never reoccurred since that one time.

I’ll report back, should #917668 resurface with the kernel I’m currently running.

* [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/922906/comments/11

Ctrl + 0, Ctrl + Plus Sign and Ctrl + Minus Sign are the designated keyboard shortcuts for controlling the zoom. This works on my setup.

Ctrl + Shift + Minus Sign seems to work identically to Ctrl + Minus Sign, but on my setup, Ctrl + Shift + Plus Sign does nothing, whereas Ctrl + Shift + 0 does what, given Minus Sign’s behaviour, I’d expect Ctrl + Shift + Plus Sign to do: it zooms in.

I’m guessing this is keyboard layout dependent. I’m using the Finnish/Swedish keyboard layout, in which the ’0’ key with Shift is the = character. In US keyboard it seems the Plus Sign has its own key, and that key with the Shift pressed becomes =. This is why Chromium thinks that I’m doing the ’zoom in’ combination when in fact I’m doing the ’reset zoom’ combination with shift.

I came across this while looking for a way to reset the zoom back to my custom default via keyboard. I figured if Ctrl+0 is ’reset to normal’, Ctrl+Shift+0 could be ’reset to default’. (I have yet to find such a keyboard shortcut. That’s a separate issue from the one I’m filing here. I’ll have to file a wishlist bug if said shortcut doesn’t exist.)

[[Special:ChangeEmail]] currently says: ”Complete this form to change your e-mail address. You will need to enter your password to confirm this change.”

The password field is located right after the ”New e-mail address” field and simply titled ”Password:”. The preface and this layout makes it unnecessarily easy to think it wants your ”password for your e-mail account” and not the current wiki. (I for one momentarily thought so despite being experienced enough to know it probably didn’t mean to.)

I suggest the ”Password:” header be changed slightly, to say ”Your {{SITENAME}} password:”

Bryce; no problem (and thanks for your working on this), for me the fbdev workaround is good enough to work and live with on this setup. If others affected by this feel differently, do take over with upstream.

Steps to reproduce:
1. In (gnome-control-center) Keyboard settings’ Shortcuts, set the shortcut for ’Lock screen’ to Scroll Lock.
2. Press Scroll Lock.

What happens:
Nothing (screen doesn’t get locked).

What I expect to happen:
For the screen to get locked.

What works:
* Setting ’Lock screen’ shortcut to Shift + Scroll Lock, Ctrl + Scroll Lock etc.
* Setting ’Lock screen’ shortcut to, for example, the Pause/Break key (which is right next to Scroll Lock on common keyboards).
* Setting Scroll Lock as the ’Lock screen’ shortcut in Unity 2D.

Other notes:
Pressing Scroll Lock does nothing whether set as screen locking hotkey or not, so it shouldn’t be tied to some other function either.

Should the first list include –quit too, as that one also doesn’t seem to work? It (2.96) doesn’t print a warning though, either:

jani@saegusa:~$ rhythmbox-client –quit
jani@saegusa:~$
jani@saegusa:~$ rhythmbox-client –debug –quit
(18:28:03) [0xc97800] [rb_debug_init_match] rb-debug.c:240: Debugging enabled
(18:28:03) [0xc97800] [main] rb-client.c:707: quitting existing instance
jani@saegusa:~$

I reported this on Launchpad [1] and was forwarded upstream.

Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu

What happens:
Nothing

What I expect to happen:
For the file to recover from trash to ~.

What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.

More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.

*[1] https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/973620

Strangely, with Chromium 18 I could no longer reproduce this with new profiles, but with my old profile it was still there.