Progress of NerdTool

As you know, Nerdtool hasn't been making much progress lately: the last repository commit was in the beginning of November. However, I have time to work on it now, so that's what I plan on doing! I am going to get a version out before Christmas for you all to enjoy.

Current Work

So far, I've been fixing lots of small bugs (check the tracker for specifics), most of which were minor. However, I've noticed that most of the bugs are small, and that the only big bugs/feature requests are from myself. As such, I'm focusing on what the community wants and leave the big ideas for another time. I'm sure you are all excellent readers, so you can go look at the bug reports yourselves; I will go ahead and tell you some more interesting things.

Efficient Toolbox

I've been looking at Conky and how they accomplish the similar task of displaying data on the desktop. In one of the documentation files, the developer states that direct shell executions (how Nerdtool operates) should be avoided whenever possible. Instead, he continues, a patch to the code should be created to add the desired feature. For example, instead of running top, you should use ${top processes}, where top processes is recognized by the program and the evaluated by the patch code (most likely in C).

I went very far into implementing something like this into NerdTool, for fetching memory, CPU time, and other system vitals. Though, I am torn as to how far I should go. Obviously, cutting out the shell is what makes the code execute faster, but I can't reimplement everything. The commands head, sed, and the almighty grep are all very useful for formatting output, but it would take time to implement those. Even if I did the implementation, what options of the command should I implement? It's a hard question, and is a perfect example of complexity over efficiency; using shell scripts is simpler but runs slower, and reimplementing is more complex but executes faster.

Say I don't implement these. You would be forced to deal with poorly formatted output, or you would have to sacrifice efficiency by having a shell script do the formatting for you (which I imagine as a using a chainsaw where intricate woodwork is being done). I don't have the numbers as to how much more efficient a direct C command is over a shell command, but I'm guessing it's pretty high.

Then again, the people concerned with efficiency would know to avoid the bash scripts and deal with the lack of formatting. Those who aren't concerned could do whatever they wanted with the efficient output, like color every `e' in the output red and every `o' blue.