Gtk+'s application development pipeline mess

Look at this normal flow of things, in a normal day of work, in a normal programmer's life:

1. Design a great UI in a UI designer
2. Roll all the UI resources into a binary blob and link it to your code so that you dont have runtime dependencies (read as: you dont know where you'll be installed for example)
3. Ask the UI framework to instantiate the view, wire it up to a controller and get going with your awesome business logic.

Now, I thought, we had this sort of thing sorted out a decade ago. But apparently not with Gtk+. Glade works perfectly fine with external image resources. i.e. you can actually see how your UI will look with all the external images (non stock icons) loaded. And Gtk::Builder crunches that file perfectly fine too.

The problem comes when you want to roll them into a blob using GResource and link it to your binary. Glade does not understand GResources. Glade generates Gtk::Builder understandable xml files. This xml refers to your image files directly. But, GResource wants you to refer to every resource by its own 'resource:///' URI. Gtk::Builder can load an xml from a GResource URI. But the xml itself refers to other resources on the filesystem which sort of
defeats the purpose.

After that brick on my face, I started thinking about workarounds:

1. Manually fetch the external images from the GResource bundle and link them to the UI built by the Gtk::Builder. This means I cannot see my awesome icons in Glade when I am designing the UI.
2. Manually edit the xml and change the external resource references to GResource URI. I dont know whether this even works. Even if it works, I do know that the 'cannot see in Glade' problem exists.

This really sucks. Lets get the obvious things out of the way:

1. Moving to another 'oh so awesome' UI toolkit is not a solution for me. Coz, in the end of the day, I love Gtk+.
2. Design all your UI in code is not the way forward either. I know I can do it. I HAVE done it a dozen times before. And I know that its a productivity killer. You disagree? Imagine iterating through your UI design 20 times a day, and a build taking 15+ minutes each. That is the biggest deterrent to refactoring your UI.

So, what could be an ideal solution:

1. Glade should generate the GResource xml definition also. Currently Glade is centered over a 'Gtk::Builder xml file'. Instead Glade should center on the 'GResource definition'. Glade should allow you to add multiple Gtk::Builder xml files into a 'GResource definition'.
2. Gtk::Builder should understand GResource URI in the xml (if it does not already)

After all that frustration, I resorted back to teaching my build system to tell the executable where the resources were. Now we know why old tricks dont die easy. Arghh.

FStival 2012, Software Freedom Day at Madurai

Another FStival. Another opportunity to talk about Free Software. Another bunch of lovely people. Another set of interactions. Another day full of new experiences. Awesomeness :)

I dont know how the rest of the (cough) 'speakers' treat presentation slides. To me, its just a bunch of reminders to keep me from losing track of what I am talking (which I happen to do a lot :-/). It really does not have any content in it. However, people keep asking for a copy of these presentation slides. So, well.. here it is, the 5+ year old presentation.

Local class awesomeoness

Context: There are these bunch of classes that implements an interface iA. The user of these classes needs to instantiate an object every time they want to use it. However, we dont want to teach the the user about how to instantiate an object. So, we decided to give the user a Factory object which implements an interface iF to create an object providing iA. This seemed super awesome until we figured that we would require more than a dozen Factory classes which vary only in the types and number of parameters sent to . So, hopped on to meta-programming and carved out a couple of templates. The pain still did not end. We still had to instantiate these templates, wrap them in a boost::shared_ptr and give them to the user. Attempts on templatising that turned out to be ugly and not so cool.

Eventually, "local classes" came to the rescue. So, here is a factory of factories :P

template 
RPCHandlerFactory *
_create_rpc_handler_factory (hlog::Logger::ptr_type logger, P1 p1_)
{
  class Factory : public RPCHandlerFactory
  {
  public:
    Factory (hlog::Logger::ptr_type logger, P1 p1)
      : m_Logger (logger),
        m_p1 (p1) { }

    RPCHandler::ptr_type operator() (RPCServer *server, rpcRequest_Ptr req)
    {
      RPCHandler::ptr_type ph (new T (m_Logger, server, req, m_p1));
      ph->set_this_ptr (ph);
      return ph;
    }

  private:
    hlog::Logger::ptr_type m_Logger;
    P1 m_p1;
  };

  return new Factory (logger, p1_);
}

template 
RPCHandlerFactory::ptr_type
create_rpc_handler_factory (hlog::Logger::ptr_type logger, P1 p1_)
{
  RPCHandlerFactory * pfactory = _create_rpc_handler_factory
    (logger, p1_);
  RPCHandlerFactory::ptr_type factory (pfactory);
  return factory;
}

And, creating a factory is like:

RPCHandlerFactory::ptr_type factory =
      create_rpc_handler_factory < rpcAHandler > (m_Logger, m_machine);

Now, we could have combined both the functions together. But there is this C++03 quirk which goes away with C++11.

Update-1:

The issue that wont allow combining the functions: http://stackoverflow.com/questions/742607/using-local-classes-with-stl-algorithms

Update-2:

Blogger ate the angle brackets in the instantiation. Fixed it. :)

Automated testing, refactor, costs and others

My colleagues are definitely not very thrilled about me jumping on them asking for test-cases. "Automated testing" has been this thing hanging around in office for a while. But lately it took new form and status, with me trying to enforce it.

We always DID test our code. We did it in our own primitive ways. Dumping data-structures, assertions, tracing logs, running through debuggers, etc. But there was always these corners that showed up when run on the field. In our line of work, we dont have the luxury of testing our code against the actual machine. The machine is a freaking 50 feet long one. We get to do that shizzle only when we go to the field for deployment. And, having to fix silly uninitialized "shared_ptr"s, in a noisy textile mill that feels like an oven, is no fun at all. It gets all the more frustrating without office comforts like tables and chairs. Now, this could be the silliest case for the need of automated testing. But, it is one of the strongest cases for us at the moment: "Not having to fix trivial things at the field". NO, this post is not to make a case for "automated testing". There are better and more convincing reasons for it on the Internet.

We never thought we could make that code testable. It was an interconnected mess beyond compare. We had a singleton global-state holding all the objects. Any object that wanted to talk to another simply fetched it from this global-state. This seemed cool in the start. But, when more developers came in (and left), this global-state turned out to be a can of worms. There were so many redundant things which we could not touch because somewhere, someone was using it in an unusual way. After a painful refactor implementing "Dependency Injection (DI)" and a little "Pimpl", to a significant part of the code, things changed. Clarity happened. We realised that most of the issues we had were because of bad OOP practices. The process of implementing DI exposed a whole lot of GRASP issues. Fixing them, automatically brought down the complexity of the whole thing.

This whole 'refactor' thingy has cost us quite a bit. Our delivery got thrown behind by a couple of weeks. However, it has proven to be worthwhile. Bringing in DI enabled us to mock objects easily. Now we get to generate input patterns which can be seen only in the field, otherwise. Increased build times are a bit upsetting.

The point is, do not fear the 'refactor'. Its like the sadhana to reach Nirvana :)

Time to love LaTeX again

Three documents a week may not be that big a deal to most people. But to me, it is hell. From keybindings for normal editing to taming templates to work nice, LibreOffice.org has made me cringe and cry at every corner. Yes, I am an old timer. Yes, I cannot unlearn my Emacs keystrokes. Yes, I hate to have to reformat whole files again because a template change will not affect documents in progress. The only reason I chose to use OpenOffice.org for work related documents was, I did not want to write documents for ever. I hoped to delegate that to someone at some point. But, in three years the situation had not changed and I dont see it changing for another year atleast.

So, its time to love LaTeX again folks :)

After half a day of refreshing on long forgotten LaTeX skills, and another day on creating a style file, PROFIT. And, best of all, I just need to change one line in the document to get  a PDF without the logo, etc. which is already on the letterhead.

The state of our educational system

Spare the rod and spoil the child..

A teacher was stabbed to death in the classroom of a private school here on Thursday, allegedly by a 15-year-old student who was upset at being repeatedly reprimanded by her for not doing well in studies. [read..]

I am so fcking glad and grateful to my parents and teachers for having used the rod whenever it was necessary. With stupid schemes like the "compulsory passing" system, the government is just worsening the situation.

spam spam spam.. :-/

So now, we have bots that read the content, understand and generate spam that looks almost real. Grrr....