Ah, scratch me off the list too (or rather, I will), can’t believe I didn’t realize this was for 2D. For us with 3D exhibiting this, there’s at least Bug #990639.

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

Universal Access in Control Center allows you to select a text size, though only from fixed preset values and not on pixel/point level.

Onko se tilapäistä, vai rikoitteko oikeasti taas kaikki entiset uutislinkit? Eikä tekstiversiota ole enää ollenkaan? Ei tässä uudessa sinänsä mitään vikaa ole, mutta ei tämä tekstiversiota korvaa alkuunkaan.

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.

If your theme has a searchform.php, you’re probably hitting Ticket #16541: get_search_form() ignores $echo if searchform.php exists.

Your workaround is fine if you’re just echoing the search form anyway, but if you need to capture the output in a variable, you can work around this with output buffering:

<?php ob_start();
get_search_form();
$my_search_form = ob_get_clean(); ?>

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

Sure, will do.

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:”