This looks slightly more straightforward than thebodzio’s method, so I’m picking this as answering my original query for ”easiest”. For some reason both Colorify and Colorize have been translated as ”Väritä” in my (Finnish) locale, so it would’ve been difficult to realize it’s actually two different functions. They’re not particularly easy to tell apart in English either…
If the diamond you keep on your bathroom table is that huge, you must have basketball-sized ones in your living room.
Christopher, your test packages do indeed fix this, excellent! As I mentioned in the report, this was 100% reproducible with the packages from -proposed, and now with the packages from your PPA I could no longer reproduce it at all, during the multiple test logins I did.
Definitely not a showstopper for me Christopher, just a minor annoyance, so it’s a go-ahead from me. Thanks for asking!
Yep, that’s exactly the issue as it occurs here too. Thanks for looking into this Christopher! If you do get this narrowed down and need testing for potentially fixed builds, I’ll be happy to try them out.
Hi Christopher, sure. For the test user, I just go to the top right cog menu, select ”Startup Applications…” and ”Add” Firefox (/usr/bin/firefox). Firefox remembers the window size, so I start it once (manually), maximize the window and then close it. On the next login, it should start maximized.
Verifying that for both test cases the issue is no longer reproducible with the proposed packages. In other words, results with packages from -proposed are as described in ”Expected:” for each test case. (For both cases the issue was reproducible here with 1:0.9.7.0~bzr19-0ubuntu10.)
jani@saegusa:~$ LC_ALL=C apt-cache policy compiz-plugins-main compiz-plugins-main-default
compiz-plugins-main:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
compiz-plugins-main-default:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
I tested 5.20 from Shuduo’s PPA and for me it reproduces the issue just the same as -proposed. To be sure, I then went back down to release versions in all the other packages (so that the only change wrt. released is again just Unity being 5.20, just now from the PPA), and the issue remained. Downgrade Unity to 5.18 and it again goes away.
But this looks like a speed issue, so Unity may not be directly at fault: any apps started once the desktop is fully loaded open as truly maximized, so a workaround is setting autostarted apps to start after a delay. Perhaps Unity going from 5.18 to 5.20 here causes just enough delay for those apps to start before whatever the component is that should fuse the menus with appindicator. The autostarting facility should wait for that component, or the component should be also able to fuse menus for existing windows once it gets up and running.
Incidentally, any appindicator-related packages’ versions also don’t seem to matter for this once Unity is 5.20. I think I’ll try upgrading just those to their -proposed versions next (so that Unity remains at 5.18) just to cover all angles.