Working on page search in #Sunstone browser. Nothing challenging here, it's just implementing a feature, but I figured I'd take a minute to post.

There's a design decision when it comes to a tabbed interface. Do you give each tab its own controls? This simplifies logic at the expense of additional memory. Or do you have one set of controls and switch a bunch of state every time you change tabs? Back when I was working on the Eva gemini browser I did the former, but in Sunstone I decided on the latter. Applying this to search, when changing tabs I'll have to check to see if that tab has a search op going. If it does, the search bar has to be set visible and the search entry text set to the correct search term. If it doesn't, the search bar has to be hidden. Other bits of state include the number of results and some checkbutton parameters such as whether to wrap the search and case sensitivity. None of this is hard, but it's easy to forget a step.

I've added a few features to Sunstone in the past few days without mentioning them. There is now an "about" page, implemented as an internal web page instead of a window. You can also now open the browser with a list of uri's as arguments, or send uri's to a running instance to be opened as new tabs. Nothing groundbreaking, just little bits that people expect to be present. Each little step brings the whole closer to something that's usable as a daily driver. I've been dogfooding it myself for a while now and chipping away at all of those little things. It does impress me that most people probably have no idea just how complex a program like a browser is, and that's without even getting into the rendering engine.

Having fun, anyway. I really missed this. My output really dropped off when I started university, and Sunstone is my chance to get back into some sort of groove.

1/2