John Darrington <j...@darrington.wattle.id.au> writes: > On Sat, Dec 17, 2011 at 09:28:52AM -0800, Ben Pfaff wrote: > John Darrington <j...@darrington.wattle.id.au> writes: > > > In order to make the output window properly respond to changes > > in style (eg. from gnome theme engines) we need to be able to > > dynamically set options AFTER the driver has been created. > > > > I thought this would be straightforward, but it seems not to be > > the case, because the parse_font, parse_dimension routeines etc. > > demand a default value, which has means it's not possible to set > > an indivual option, without also setting all the other options > > back to their default values. > > I see two simple possibilities: > > * Keep the original options around at the driver level. > Allow individual options to be set by modifying the > original options. > > * Don't add any support for setting options at the driver > level at all but instead just destroy the driver and > create a new one with a new, complete set of options > that has been adjusted as necessary. > > To me, the first option sounds simpler, and more efficient, because > in most cases the options won't change and when they do, it's likely > to be just a single option. > > But here lies the problem with the existing arrangement. It doesn't > allow one to set a single option. All the parse_option_* functions > take a default value, so if you don't pass it that option, it'll get > set back to the default. We don't want that. We want it left in its > current state.
I don't understand the problem yet. If we pass a particular set of options to a driver, then we'll get a particular configuration. If we need to change one option, then we can do that by updating the set of options slightly (just changing the one value) and then handing the driver the updated set of options. The default values should default the same way they did on the first try, right? (Is anything nondeterministic in play?) -- Ben Pfaff http://benpfaff.org _______________________________________________ pspp-dev mailing list pspp-dev@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-dev
