-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

...

...

The easiest fix would be to add a public interface to change the value of an option in a variables map, by making op[] return a non-const reference. I'm not sure if code should be added to call semantic -> notify automically.

Yep, I guess we need non-const-returning[] for sure. We probably should have variable_value overload operator=, and call semantic->notify.

Yes, this sounds cleanest.

Do you think disallowing assignements that change value type is OK? Say, if you try to assign int to value of type double, you get exception.

This sounds sensible to me.

...

...

2 find out the type of an option

This is not strictly necessary, but I'd be nice to e.g show a checkbox for bool options, a spin button for numeric options, and an entry field for other options. I currently infer the type by querying the Boost.Any that holds the option, potentially after applying the default value. This is not foolproof, however, because it fails for options that have no default value and that have not been set before.

Technically speaking, the value_semantic base class does not require an option to have any type at all. At the same time, in 100% of known cases the type for an option is known. Perhaps I can either add 'type' method to value_semantics that returns type_info* and may return NULL, or just make it return type_info& and demand that all options have a fixed type. Will either of those approaches work for you?

Either will work.

...

...

3 convert from an option value to some screen representation [...] One another approach is make variable_value record original tokens it was constructed from. This correlates with your point (1) above -- perhaphs after UI was changed, value_semantics->parse should be called to get new boost::any and the parsed tokens should be stored in variable_value.

Again, this sounds cleaner than my proposal.

...

...

4 find out what options in a po::options_description are members of what option groups

This is necessary to group the options in multiple tabs. Again, there are only private interfaces to access the information.

The problem here is that when you add one options_description to another options description, the original object is not retained, so it's not simple to have "parent pointer". It might be possible to have "parent group name" field in an option. Would that be too cumbersome to construct UI hierarchy grouping options by string parent name?

Putting the parent string into every option sounds unnecessarily complicated too me (from a user perspective). What about making options_description manage map of views in the main options vector, that is, something like map<parent_string,vector<option*> >. With an adequate public interface, my problem would be solvable in a strightforward way. With the interface changes described, a clean options window implementation seems to be possible. - -- - -ness- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF/84JvD/ijq9JWhsRAqmgAJ9i28pXZH/iO7/73xCsjOB2b9MJtACeMNkp FYAYuTktzPcevz76exgZFWA= =F50V -----END PGP SIGNATURE-----