Friday, February 18, 2011

Research, Research, Research!

Unfortunately, not much in the way of source code development in the last week. When I decided to switch to Glade to design the UI, that naturally required a lot of reading to bring me up to speed. Unfortunately, Glade is not well documented, and the documentation for using it with Perl is even worse. So, after some time of reading some sporadic, and often ancient, blog posts from geeks around the world, I decided to switch to something more uniform.

Joe Dougherty, a fellow RCOS member, spends a lot of time hyping Qt. As it turns out, with good reason. It's kind of a lot like Glade, with a drag and drop widget style interface, except all the documentation is one place, and it's actually good. So I'm going to play around with it and see what it produces.

Of course, Qt is an interface for C++ programs. So, the obvious question is, how does this affect (effect?) the work I've done in Perl already? Well, the answer to that question is, it doesn't, really. The Perl scripts interface directly with the Cisco routers to run their function and then terminate. So the Qt application will handle the user interaction events, and if the user wishes to execute one of Perl scripts, (for example, to save configurations) this can be called by going to File->Save, for example. The cool thing is that since Perl itself is basically one big C program, it is easy to call a Perl function from C. If Qt does prove to work out, I may invest some time in porting the Perl functions to C++. But that's a ways in the future at this point.

So I'm a little bit behind already (ugh!) but I'm looking forward to taking the long weekend to work on this and get back on to my schedule.

Also, I have improved the speed of the restore function (which loads configurations from a text file into the 11 devices) to the point where it is actually faster than a human manually performing the same task. Booyah!!

Friday, February 4, 2011

Glade!

I've discovered this thing called Glade. It's a Unix tool to speedily create GUI applications in the Gtk environment. This is a bit of a departure from previous versions of what I was doing, trying to use Perl's built-in GUI functionality to work my program. Glade, using Gtk, offers several advantages over the built-in Perl stuff:

1) Speedy, drag-and-drop interface. It's easy to create a widget-based GUI simply from dragging and dropping widgets on to the canvas. Whereas the built in Perl GUI module requires writing all the design code by hand (<-That is hellish, I've needed to do it in class and it does not look pretty), this alternative is actually much faster and I do not need to get hung up on little things like changing numbers in a multi-hundred line code file to make things look good.

2) One less thing to install. The Perl/Tk library is an extension to Perl which does not come installed with Perl by default, most of the time. Gtk, of course, is essential to Linux running the GNOME desktop, and is also easy to add to XFCE and KDE based distributions as well. So this will insure a greater degree of cross-distribution compatibility.

3) It looks better. Perl/Tk is a pain to get to look good, however, I was always of the opinion that if an application is functional, then looks should be secondary. But, as long as there is an option that looks better while retaining all the same functionality, I might as well go for it.

So of course, Glade does not write any actual code, it is just a design tool. So it is basically a front-end GUI which will be manipulated in the background by Perl scripts. The Gtk-widget based GUI's are similar to the ones built by native Perl applications, so this is all pretty familiar to me, I just need to read the documentation on the Gtk Perl modules so I know what functions do what. So it's a little bit of backtracking in development, but it's a new semester and I have new resolve to get this working.

So, to that end, I am setting a hard and fast goal to have the GUI working completely with Telnet operations within one week. Then I can focus on adding other bells and whistles that will really set apart the INMP from other programs.