Monodevelop 4.0 and dark themes

Monodevelop 4.0 (or "Xamarin Studio" if you're one of the blessed Mac or Windows users) was released a fair while back with great fanfare as the new, awesome major re-designed version of Monodevelop. I think it's fair to say that I wasn't impressed.

Aside from the ever-present nightmare of building the damn thing (turns out you need to already have a version of monodevelop installed or the new version spews out a ton of errors when you build it), the folks behind Monodevelop managed to produce an IDE that was utterly unusable for me. Why? Because it only partially followed the system themes. Following themes is a really nice feature - it makes the application fit in with your working environment nicely and (if you're me) allows you to run it with a nice, dark look that doesn't give you a headache by lunchtime. I find the standard black text on glaring white background to be a great way to increase painkiller sales at my local shop.

Totally ignoring themes would be annoying, but hey, I can live with it. At least you can still get on and work, right?

Monodevelop 4 does neither.

Monodevelop 4 applies some of the colours to some of its interface. Which leads to the joy of trying to read light grey text (following my system theme) on a light grey background (ignoring my system theme). Some of the fancy new components that Xamarin have created to bling up the interface have partially hard-coded colour schemes. It's inexcusable, really; an inexplicable error to put in a supposedly polished, high(ish)-profile release. I can only assume that nobody ever thought to check what happened when you applied dark themes.

Maybe Xamarin have fixed it in later releases. Maybe not. I don't know, and I don't really care, because everything after 4.0 relies on having access to mono > 2.10.8.1 - and since Ubuntu (the platform I'm working on) hasn't had an update to mono in repos for the last three centuries or something I'd have to build mono to use it - but everything I work on needs to be capable of running on the version in repos. Yes, I could run parallel monos on my desktop, but just to fix a colour scheme? Really?

Personally I think it's totally understandable that those who use Mono/Monodevelop on Linux are beginning to feel like Xamarin has hung us out to dry. But that's an argument for another day. The point of this post is: You can hack the monodevelop sources to make your dark theme work enough to use 4.0. This isn't a fix as such; if you change the theme, you'll need to hack the sources again and recompile. I don't know my way around the monodevelop sources well enough to properly fix it (plus it's not my job to spend the time learning my way around and, fuck it, they don't see linux support as worthwhile, I don't see why I should spend my time fixing their shoddy engineering).

The Hack

To make Monodevelop usable with your dark theme (I use Nodoka-Midnight) you'll need to modify a few of the source files. The motherlode of hard-coded colours is in src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Styles.cs. I've used rather a blunderbuss approach, and some of the following changes may not strictly be necessary; feel free to apply them one by one and see which steps can be skipped:

• Swap over the values of BaseForegroundColor and BaseBackgroundColor (lines 33 and 34)
• Darken ThinSplitterColour (I set it to 31,31,31)
• Darken the TabBarBackgroundColor (I used 2e2d2d)
• Darken the BreadcrumbGradientStartColor (I used 484444)
• Darken all the DockTabBar... colours (I used variants on 45d / 255d, 44d / 255d, 44d / 255d and halved the numerators for the ...Shadow... colours)
• Similarly darken PadBackground, DockFrameBackground and BrowserPadBackground

That should get most of the interface at least usable. There's also a tab strip sitting under the main edit window in the default debugging layout which is almost impossible to read without changing its background colour, so in src/core/MonoDevelop.Ide/MonoDevelop.Components/Tabstrip.cs, line 40 darken BackgroundGradientStart to something like 45d / 255d, 44d / 255d, 44d / 255d

Now make & make install monodevelop and you should be able to use it with a dark system theme without half of the interface being illegible.

As I said, this is NOT a fix. It's a horrible hack. Monodevelop shouldn't be using hardwired colours at all - or it shouldn't be applying colours from the system theme at all. The way it's implemented is a textbook case of a half-baked feature being worse than none at all.

Asynchronous HTTP GETs being slow

Note to self:

If asynchronous HTTPS GETs from the same browser (in multiple tabs, say, or from an ajax site) seem slower than they should be - for example, if request roundtrip times get multiplied up by the number of tabs open - then it's very likely a bottleneck being caused by the browser cache. Firefox and Chrome at least (not tested any others) seem to only allow cache writing through a critical section or something. So the entire browser has a single, locked cache. And seems to lock it for the *entire* duration of the GET request. Which means aysnchronous GETs end up forming an orderly but very slow queue.

Turn off caching in the http request object and the problem goes away (though, of course, you don't get to cache anything any more).

Came as a surprise to me. Couldn't find an explanation for the behaviour when it cropped up - I assumed for ages our server was to blame. It wasn't.

Ill-Considered Smartphone Griping

My current phone, a Samsung Galaxy S, is the first smartphone and by far the most expensive phone that I've owned. And sometimes it hacks me off far more than any past phone. Let me start by saying that smartphones are amazing devices. They're so far beyond phones it's not funny. And that's sort of the problem; there's so much potential there, and the phone forces your expectations high by being so neat in so many way.

I'm likely to invest in a backup phone soon which is just a phone purely so I have a more rugged, less expensive phone with a less fleeting battery life. I just can't get comfortable heading out on the bike for a day with my SGS tucked in the back of my jersey. Aside from anything, if I didn't remember to fully charge it before setting out then who knows if it'll still be working when I need it late on after disaster has struck. But I think that's fair enough, and not really a criticism of the SGS - or smartphones in general. Complaining that a smartphone doesn't work well as a long battery life, cheap, bombproof emergency backup phone is like complaining that bread makes a lousy sandwich filling; simultaneously right and dumb.

Some of what annoys me about the SGS is probably device-specific. Some of it is probably OS-specific. And some of it isn't the phones fault at all. But I still blame it, because it's the point at which the annoyance enters my life. So where to start...?

I suppose at the beginning. The SGS, as delivered, was shit. When I first got the SGS, it rapidly became apparent that various bits of it just didn't work. Samsung had cunningly designed a device whose GPS performance was so flaky as to be useless. Use it to navigate and you'd find your apparent location hopping around between neighbouring streets. Recording routes showed similar problems. An entire feature of the phone was working so badly, it would have been a better experience if it hadn't been implemented at all. Several months later - somewhere between six months and a year - and the GPS was finally fixed enough to use. Another massive problem with the phone was the file system: In their wisdom, Samsung decided to use a half-baked in-house mess called RFS (essentially FAT with an attempt at journalling tacked on). It's utter shit, and very rapidly access times plummet to the point that the phone lags whenever accessing storage. The community cooked up various lagfixes fairly quickly, but the experience out of the box was significantly worse than one would hope for. On top of all that the official support software for the phone, the route used for official updates, was so bug-ridden that it took me hours (including hacking the registry) to get it to work at all. And, of course, I had to boot a Windows VM to use it anyway since there's no support for linux hosts. Again, the community stepped in and have provided a variety of functional alternatives.

There were other issues too, but those were the headlines. And here's the thing.

I cannot - absolutely cannot - understand how a flagship device was released in such a state, or how it was left for so long without being officially fixed. I can only assume that no one in Samsung ever bothered to test any of this stuff before release. It's inexcusable, in my opinion, for such fundamental and blindingly obvious problems to be present especially in an ostensibly high-end device. I have NO desire to go through a similar process of cobbling my phone into functionality over a period of months again. I don't mind hacking it to tweak it, but in my opinion the above isn't tweaking. It's getting the damn thing working in the first place.

Moving on. There are things about the phone that even now hack me off. The one that annoys me most regularly, oddly, isn't strictly the phones fault at all but the BBCs. When listening to catch-up radio on my phone.... LET ME TURN THE FRICKING SCREEN OFF. The Beeb, in their wisdom, implemented (and by "implemented" I mean "hacked together and pretended they'd thought it through") iplayer for Android in flash. Which (a) means my wifes phone can't use it *at all* and (b) means it's shit. I mean, it works, but it's hideously inefficient and also keeps the screen turned on whilever it's running. Even if you're just listening to the radio. Power drain much? It pisses me off *so* much that Android is stuck with this shit when Apple devices aren't. I know the Apple ecosystem more established, but it's the BBC for fucks sake. They should be providing the same quality of service to all the major smartphone platforms. Anyway. More annoyances: When the battery runs low, the phone turns the screen on to tell you. And pops up a popup. Which won't dismiss until you press the appropriate button. And keeps the screen on until you do. When the battery is low. WELL PLAYED SIR. Also, even without the shonky file system, for no reason I can figure out the device briefly becomes laggy and unresponsive. Then recovers. Given I've owned less powerful PCs (fairly recently) than this device, I expect more than groaning as it tries to render a webpage because it's doing whatever housekeeping in the background.

And moving towards a more general point... I think largely what annoys me with the SGS, aside from the specifics, is any time I notice it pretending to be a phone not a computer. I mean, honestly, it's a pocket computer. It should act like one. And this is where I think lots - if not all - smartphones are going wrong (for the likes of me). Whenever I want to do something to the phone but I can't because I'm not allowed... that hacks me off. I'm used to computers that I *own* (like I own my phone!). That I can do anything to because they're fricking MINE. Now, yes, you can root an android phone to get this fundamental right of ownership back. But why should I have to? It's MY DEVICE.

Updating the SGS seems far more difficult than it should be. Maybe apt has spoiled me, but what I expect from my device is, basically, that the OS and all the software on it updates with no faff. Every Android update has been a hassle, with some of them randomly stopping various applications from working (and you'll only find out if you try to run them). And there's always eother the threat or promise of data loss. Unacceptable! Sort it the fuck out. ESPECIALLY if you're going to lock down the system for the average user so it's hard/impossible to fix stuff if it does go wrong. In fact, why do I have to stick with Android? Why can't I pay for the OS of my choice? It's just a little computer, after all.

One of the big things I was interested in doing before getting an SGS was writing stuff for it. I figured once I've actually got a device I can have a think about what I want to do with it. Yet since getting the SGS I've written *nothing* for it. There are a few reasons for this, one good, one bad, one indifferent. The good reason is that there's an awful lot of stuff already out there. I didn't need to write many of the apps I wanted. That's nice. The indifferent reason is that I *hate* writing the same thing twice. And almost everything I've wanted to do that I CAN do (see below) has been better served by just writing a web app. Then I can use it from anywhere, on any phone. The bad reason really annoys me, and although I knew this when I was getting the SGS it's only become more annoying as I've used it. And this is the big one. Fix this, and I'll buy your phone:

GIVE ME USB HOST SUPPORT, AND LET ME WRITE STUFF THAT USES IT.

They're COMPUTERS. Think of what we could do if we could use them to control USB devices! IT WOULD BE AWESOME. There are *so many things* we could do. And I keep thinking of them, and having to dismiss them because mobile phone manufacturers are knobs.

I'm fairly sure there was other stuff I wanted to grouse about, but I thought a quick stream of consciousness rant that actually got written was better than a well considered, complete but nonexistent essay.