Not reproducible in current 12.10, still reproducible in 12.04
Not reproducible in current 12.10 with gdm 3.6.0-0ubuntu4, still reproducible in 12.04 with gdm 3.4.0-0ubuntu15.
Avainsanana Unity
Scratch me off the list too
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 seems to have cropped up somewhere around release time
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.)
How to configure Unity/Compiz in 12.04 so that Update Manager opens maximized w/screen bigger than 1024×600?
In Precise, window auto-maximize is disabled on monitors with a resolution above 1024 × 600 [1]. I have a bigger resolution, but I prefer maximized windows anyway. I want Update Manager to start maximized.
What I’ve tried so far:
- In Compiz Config Settings Manager, I have Place Windows activated and ’Windows with fixed placement mode’ has windows matching the rule ”(name=gnome-terminal) | (name=update-manager)” set to ’Maximize’. With this, Gnome Terminal starts maximized, Update Manager does not.
- In Compiz Config Settings Manager, I have set a Window Rules [2] rule to match ”name=update-manager”. Irregardless of any rules set or not, activating Window Rules results in not being able to bring out Unity Launcher anymore, Alt+Tab window switching becoming slow or nonfunctional entirely and the screen sporadically freezing completely. Not a viable option apparently.
- I’ve installed Maximus [3] and started it. Update Manager ignores it (or vice versa).
I’ve not tried devilspie and would prefer not to. Having to configure something external for this would seem stupidly redundant with (the no-brainer) Maximus and all these Compiz options already available. I just can’t seem to make them work.
Scroll Lock key as screen lock hotkey does not work (works in U2D)
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.
Seems to be just U2D which I was testing earlier today
Ah, it seems to be just U2D which I was testing earlier today. I too can file all the bugs I want against ’unity’, but if I try `ubuntu-bug unity-2d` all I get is the ”third party package” error. Reproduced this also in a clean VM to be sure.
With Unity from PPA, you cannot file bugs against Unity using ubuntu-bug
With Unity updated from the PPA, you cannot file bugs against it using ubuntu-bug, you’ll just get an error message saying ”Please remove any third party package and try again.” You can still file bugs directly on Launchpad using the browser, but then the report won’t have the logs attached to it.
I linked Unity 2D where this problem still remains
I linked Unity 2D where this problem still remains. As a workaround, Shift+PrtScrn can be used to approximately select the desired window area to grab.
Here’s one somewhat reliable way to trigger this
From Bug #950645, here’s one somewhat reliable way to trigger this: after login, have some windows open (I have Chromium, Gnome Terminal and Transmission set to start on login, don’t know if this works if you start them manually), then use the workspace switcher. This causes the launcher to stick (i.e. autohide to fail). Interestingly, if I then killall unity-2d-shell, even this recipe then fails to trigger the issue until the next login. But it seems 100% reproducible right after login. (I’m just hoping that #950645 really is a duplicate of this one. For me the trigger’s always been something else in the launcher since I almost never use the workspace switcher.)
It seems especially prone to occur when I have multiple Gnome terminal windows open
I still don’t have a surefire recipe for reproducing this, but it seems especially prone to occur when I have multiple Gnome terminal windows open, or one with multiple tabs in it, in addition to other apps. I have a gut feeling it’s triggered 4/5 times by switching from something else into the set of Gnome terminal windows (with the mouse, via launcher).