Seqsee Diary

This post would never end in my dissertation; but it is a recent day of hacking I enjoyed, and a lot of good can come out of it.

What I did was simple: until now, I had coded the UI imperatively, and I merely shifted to a declarative style. Thus, I went from something like

$button_frame = $MW->Frame()->pack(-side => ‘top’);

$button_frame->Button(-text => ‘quit’, -command => sub { exit })

->pack(-side => ‘left’);

to something like:

[widgets]

button_frame MW Frame top

…

[buttons]

quit: exit

The main reason to do this was to make the UI more configurable and to get rid of lots of duplicate code inherent in an imperatively coded UI. However, a far nicer side effect has emerged. In the process of going to declarative style, I had to handle the special code I had cut to handle widgets I had specifically crafted for Seqsee. This made me start thinking about what these widgets were, and I realized that these are just views into the innards of Seqsee, and I could have arbitrarily many of them, even with overlapping functionality. Until now, I just had viewers for individual components of the program. I used one to visualize the stream, for instance. In this mindset, it did not make sense to have multiple viewers for the same component. Now under the new mindset “it’s just a view” that restriction is lifted. I am free to have as many different widgets as I fancy.

Here are just some potential widgets that would help me understand what the program is doing much much better.

• A strength visualizer that would let me compare how strong various components are. This would be crucial as the relative probability of choosing a particular object is strongly modulated by its strength. So having a good way to calculate strength is crucial, and checking if I indeed have a decent way to calculate requires a visualizer.
• A workspace activity visualizer, something that tells me whether the program is thinking that things are going well. Think of it as a temperature visualizer: it shall show me how the temperature has been changing over time. Several activities like destroying objects depend on this number.
• Any other as required when I get stuck and need to see what Seqsee is thinking.

There is also code duplication amongst the various widgets and I should eliminate these if I begin producing several widgets.

All I have been saying, briefly, is that the MVC pattern is often a very good idea, and it allows you the freedom to dream up strange V’s.

Being able to look at what is going on from different perspectives is crucial. Hey, for all I know, I might be able to work this into my dissertation!