Updates Suck (Part 2): KDE Plasma 5.5 breaks task manager minimized application display

If you’ve recently updated to KDE Plasma 5.5, you may have noticed that minimizing your applications no longer produces a noticeable effect in the task manager. (In actuality, the status effect of minimized versus non-minimized applications is limited to a thin, gray outline around the application title–hardly something that conveys application state well enough to process visually at first glance.)

The fault of this change lies with this bug report posted almost 3 years ago. After much discussion, it was decided that 1) the “disabled” state of minimized applications was a mistake, 2) the minimized state makes it too difficult for some people to locate the gray scale application icon, and 3) no one wanted to add a configuration option to enable or disable this feature, so the next best thing was to rip it out. Now, I’ll be honest: Maybe I just happen to have better-than-average pattern matching capabilities in my visual cortex (doubtful), but the gray scale icons for minimized applications really don’t bother me. What does bother me is this change: It takes me twice as long to find minimized applications on the task manager. To say nothing of the fact that two or three people complaining incessantly for 3 years can effect such a substantial change on the rest of us who actually liked the feature…

Humorously, I didn’t notice this change during the initial update. Since I spread my work out across multiple desktops, I don’t often minimize my applications. This explains, at least in part, why it took three days for me to discover this problem and make a post about it (and why I blamed it on plasma-shell’s propensity to crash all the time, although that seemed like a reasonable explanation in lieu of anything more substantive).

The good news is that I traced it down to this commit which turned off the minimized gray scale display. As expected, removing this patch returns the task manager’s display of minimized applications to its previous state. The bad news is that, yes, you do need to recompile plasma-desktop from source. If you happen to use Arch Linux, I’ve put together a PKGBUILD containing the fix based off the PKGBUILD in ABS (hence why I haven’t yet changed any of the credits–I should note that this is not an official package). I’ll keep this updated as best as I can until such time that upstream finally settles on a better idea than a 1 pixel gray outline for non-minimized applications.

The rest of you will have to apply the patch and build the sources yourself. Sorry about that.

No comments.
***

Updates Suck (Part 1): Firefox 43, HTML5 breakage, and more

Sometimes, updates are awful. They break things, they undo configuration options you were sure you had set at some point in the past (either resetting them to defaults or removing them entirely).

I updated my Arch install for the second time in two days in the hopes that some minor bugs would be resolved (more on that in another post), but I hadn’t noticed that Firefox was included in the update list (version 42 to 43). Sadly, not only did this break Firefox’s appearance using oxygen-gtk, but it also broke HTML5 video. Every video on Youtube refused to load following the updates unless Flash was enabled (I have it disabled), and I couldn’t figure out why. A new profile proved somewhat useful: Youtube would work–unless I copied my old profile over in bits and pieces.

After about a half hour of exploring, I found that the culprit was actually in the profile’s prefs.js. In particular, because I had found some instructions on enabling HTML5 under Linux, apparently there were some configuration options that are no longer used and conflict with Firefox 43, which enables many of these by default.

If you encounter a similar problem, the fix should be relatively easy. Simply remove:

user_pref("media.fragmented-mp4.exposed", true);
user_pref("media.fragmented-mp4.gmp.enabled", true);

From your prefs.js, restart Firefox, and verify that it still works. If not, try removing all of the media.* preferences. If that still doesn’t work and you’re a user of FlashBlock, try uninstalling it and removing any residual preferences (also from prefs.js).

I used to recommend using FlashBlock in combination with NoScript to reduce the browser’s attack surface, but as fewer and fewer sites I encounter actively use Flash, I find that disabling the plugin (settings, addons, plugins) works best for me. Unfortunately, the author included a new feature to block HTML5 video by default, and I’ve found that it tends to cause breakage with some sites, most notably Youtube. Since then, I’ve had the plugin disabled, but as I no longer have a need for it, why keep it around?

Hopefully, if you’ve encountered a similar problem with HTML5 video, the suggested fixes here will work for you. If not, feel free to leave a comment or pester me on Twitter (@zancarius).

(I still haven’t gotten Firefox 43 to play nicely with oxygen-gtk3, so I may eventually consider abandoning the theme–though I find breeze-gtk still contains a variety of display bugs that make it unpleasant to use.)

No comments.
***

Annoyances: vBulletin Version Check

I hate vBulletin. I really, really, really hate vBulletin, and as much as I’d like to pin it on their apparent disdain for K&R coding style (curly braces should, in my opinion, always be on the same line as the if statement to which they are bound) or their awful code in general, I’m afraid I can’t. Mostly, my experiences have been with vBulletin 3 and 4, but while I have no experience with vBulletin 5, I can’t imagine it’s any better.

vBulletin represents everything that is wrong with the PHP development community as a whole. Or rather, everything from the earliest, darkest ages of PHP antiquity that I’d rather just fade away. It’s 2015, and there’s absolutely no reason to continue encouraging people to do stupid, idiotic things when there’s plenty of fantastic documentation out there that would be much better reading for new developers.

Sadly, though, we have to contend with what have rather than what we want.

(Aside: XenForo isn’t much better, but at least they’re using the Zend Framework and provide at least something of a fa├žade that they might actually know what parameterized statements are.)

Today, I wasted about 15-20 minutes on a confounding problem with a vBulletin plugin. The version check URL wasn’t working–at all. Why? Well, there’s the rub, isn’t it? Here’s what I had done: I put an XML file containing the appropriate nonsense for plugin versioning (which would fail XML validation, but that’s besides the point) with nginx sitting in front, pointed vBulletin at the URL, and… nothing.

What the…?

After some fiddly rubbish, I finally ran Wireshark to see what was going on. Lo and behold, it was obviously much more work to host some simple version checking nonsense than to just throw in a static page:

POST /some/path/to/version.xml HTTP/1.0
Host: example.org
User-Agent: vBulletin Product Version Check
Content-Length: 0
 
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Tue, 28 Jul 2015 22:27:25 GMT
Content-Type: text/xml
Content-Length: 52
Last-Modified: Tue, 28 Jul 2015 22:21:13 GMT
Connection: close
ETag: "55b80059-34"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
 
<version productid="test_product">1.0.0</version>

Did one of their developers read somewhere that POST is somehow better than GET? Not only did this violate the principle of least surprise (for me at least), but it also flies in the face of HTTP verb standards. GET is generally expected to be used for repeatable requests with no side effects. POST is generally expected to be used for requests that create a resource or otherwise perform tasks that have side effects. A version check should not, in my opinion, have side effects since the only reason for doing such a thing is to check the damn version in the first place.

An even more egregious problem in this particular case is the lack of any post data. Seriously, look! Content-Length: 0. Nothing. Nada. Zero. Why would you do this? Do I have to write some kind of script just to handle a stupid version check that does nothing but look here, examine the number, and say “Oh, hey, guess I better not update. It’s still the same!”

No. Or rather, Hell, no.

I hate to abuse nginx’s config for something of this nature, but since I haven’t finished setting up a distribution framework for these plugins, all I wanted to do was push some static files indicating the current version somewhere. So, after a cursory search, here’s what I stumbled on:

error_page 405 =200 $uri;

If nginx would otherwise return a “405 Method Not Allowed,” we redirect it to the URL we were going to retrieve anyway, and return that. It’s a horrible workaround, and there’s probably better, but I shouldn’t have to do this in the first place.

I suppose I could understand it if you were passing along some sort of token with the version check, perhaps for client identification or similar, but in this case it’s just used to determine whether a plugin has outstanding updates ready. Let’s GET real, people. Stop abusing HTTP verbs.

Oh, and that tag (yes, you know which one) is an inside joke. I’m not allowed to repeat it in mixed company.

No comments.
***
Page 1 of 4912345...102030...Last »