Not-So Awesome Update

Awesome 3.4 is available now so I decided to go through the update process once again. Aside from the change from the 2.3 version to the 3.x version (you know, where the config file became a program) this was the worst experience of the bunch. Actually, thinking about it- this upgrade was really the worst hands down. At least changing to the 3.x branch came with the excuse of having to learn a programming language.

It took me the better part of 5 days to get my system back to normal. I still can’t get my battery indicator located properly in the statusbar wibox. Here’s a list of the things I had problems with:

• Getting my battery widget to work again. The widget API is totally revamped as of 3.4 so I had to figure all that out.
• Dynamic tagging. I have my own version of dynamic tagging where I’ll launch a progam (mutt or uzbl) and it get’s its own tag. The “tag” API function has changed, but it isn’t at all clear how. The most I could tell was that I needed to pass it a table, but I can’t really tell for sure what the contents of the table should be. I scrutinized the code base to try and figure this out, but it just wasn’t something I was capable of deciphering. In the end, I think I have it working again, but I can’t be sure because the documentation is lacking.
• The “hooks” API has been replaced with signals. It looks like the good thing here is that the overall amount of code required for configuration dropped. Unfortunately, it isn’t entirely clear why. My sense is that more is going on behind the scenes than in prior version, but it’s also possible that the functionality has been moved somewhere else- like awul.rules or something.
• I couldn’t get uzbl to work properly for several days. I was unable to scroll pages. It looked like the window was being drawn to the actual size required to make the web page fit in 1 window without a scroll bar. So the majority of the window would be inaccessible. In the end, it seems that I needed to add “c.size_hints_honor = false” into the manage signal handler to make it work. I say “it seems” because I can’t be sure as I’m not entirely sure what this property (or whatever) is for. The only reasons I tried it is because I noticed it’s absence from the signal handler as opposed to the hook function in the 3.3.x branch. Adding it had the desired affect, but again, I have no idea why.
• I used to have mouse button bindings tied to my battery indicator that would put a pop-up on the screen so I could see exactly how much battery life I had left. I don’t for now because I can’t get it to work properly with the new API here.
• I can’t remember but there were other things. Hell, I ultimately had to install the stock rc.lua file to get it running and then manually compare files line by line to find ALL the subtle, yet significant, changes made.
• Oh- awful.tag. It returns a table of tags. Why? If I want a table, I’ll make a table in the rc.lua file. Why force this on me?
• Awful.rules- really, the name says it all here. If you’re going to create rules, why bother with leveraging the power of a programming language for configuration? I mean, wasn’t that the whole point of the 3.x branch in the first place? I had originally hoped that I could make things work without awful.rules. Unfortunately, awful.rules is required or clients won’t have buttons bound to them. Blech. Like I said- awful rules.
• As near as I can tell, the d-bus name is NOT org.awesome.naquadah. It’s org.awesome.nagaudah.awful- as created in the awful.remote module. If I try to connect to org.aweseom.naquadah I get errors that the service is not available.

My biggest quibble is the seeming cavalier attitude the developers seem to be exhibiting regarding the changes. I’m not sure I really see any kind of noticable advantage that justifies the fairly major upheaval they’ve created. Since the 3.x version of Awesome was originally launched, they have modified the key binding API twice, the widget API, the hooks API(now signals), the timer API, the button API and the CAPI. In the course of doing these changes, all previous incarnations were deprecated which basically meant users are forcred to tinker with the rc.lua constantly if they wish to remain current.

All of these changes seem to be centered around “beautifying” the code, as opposed to performance improvements. I could be wrong- there may be other reasons I’m just not privy to. But that would come back to some documentation to let us Awesome users know what the hell is going on. I’m also cognizant of, and symnpathetic to, the developers wanting to tinker and play with their baby. That being said, I wish they would be cognizant of and sympathetic to users who don’t want to spend large chunks of freetime rejiggering initialization files to get back to where we were prior to the upgrade.

Alright, rant over. I’m sticking with Awesome because in the end it is still possible to do a lot of cool things with it. Plus I’ve already invested a lot of time in maintaining it’s operation and I’m not keen on learning something new. Perhaps things will finally settle down at this point. Then again, I think that claim was made back when they upgraded from 3.2 to 3.3 so I won’t bank on it.