Use computed offset instead of hand-built array for access to struct swb_config members To access an arbitrary member of struct swb_config, we currently use the entries array in the struct, which contains pointers to the members of the struct in order. This has several disadvantages: * the entries array must be filled by hand for each instance; * structure instances cannot be copied in the normal way; * the swb_config_options array describing the possible config options must be kept in the same order as the members of the struct. A much better solution is to let the compiler compute the offset of structure members using the offsetof() macro and stick the results in the swb_config_options array; we can then access the member by adding the offset to the address of the structure instance. This also allows us to get rid of the entries array in struct swb_config and the swb_config_copy() function.
Fremantle: Prestart MicroB if appropriate when reconfiguring browser-switchboard If, in changing the browser-switchboard configuration, we go from a configuration where MicroB is not left running to one where it is, we should start MicroB in the background in order to make sure that the MicroB browser window comes up quickly when requested. Make a best-effort attempt at this in both the command-line utility and the GUI, refactoring to give a swb_reconfig() function that can be shared between the two along the way. Ideally, we'd also kill MicroB when making a config change in the other direction, but we don't have an easy way of knowing whether MicroB is actually in use and we don't want to kill MicroB if it's in use at the time.
Fremantle: Coexist with a running MicroB process; don't kill MicroB at end of session if MicroB is the default browser With commit aeb836f5... ("Tweak detection of com.nokia.osso_browser acquisition slightly"), it's almost possible to support opening a new window in an already-running MicroB. All we have to do is avoid invoking a new browser process in that case, so do that here. It also turns out to be possible to take back the com.nokia.osso_browser D-Bus name from MicroB without killing it, which is interesting to us because the need to kill MicroB is what necessitates the behavior changes we force on MicroB. On the other hand, if we choose to avoid killing MicroB, we lose the ability to have MicroB take over handling osso_browser requests while a MicroB window is open, and we waste memory for users who aren't using MicroB very often. Therefore, we take a compromise approach: if MicroB is set as the default browser, we don't bother killing MicroB when the last browser window closes (which simplifies the code considerably, since we no longer need to monitor MicroB while it's running, and also means that MicroB should behave as it does when browser-switchboard isn't running). Otherwise, we act as before (watch the running MicroB and kill it when the last browser window closes, with the behavior changes this requires). For control freaks, there's also a new autostart_microb config option which allows you to override this heuristic. Setting autostart_microb to 0 forces us to kill MicroB even when MicroB is the configured default browser, and setting it to 1 forces us to leave MicroB running even when MicroB isn't the default.
Clean up configuration again Commit ec8b58af... ("Refactor configuration") still has too much boilerplate code and leaves too many places that have to be modified to add a new config option. To fix this, add a new array of config options with name and type of information stored, and then add an array of pointers to the elements of struct swb_config with indices matching the list of config options to struct swb_config. This consolidates all the work needed to add new config options to config.h and config.c, and allows us to replace the boilerplate code with loops over the array of config options.
Refactor configuration Most of the code for loading configuration from the config file was being duplicated between the UI and the main browser-switchboard code; also, the forthcoming command-line configuration tool should share the code for loading and saving configuration with the UI. Therefore, move code for loading and saving configuration information into functions generic enough to be shared between the UIs and browser-switchboard.