So I guess I favor this MP over the alternative, mostly because this one is more straightforward to reason (from a user's perspective) about what is available for use.
In light of the proposed plan, the following is more of a comment; but I'm concerned that we're exposing too much of our internal composition scheduling with the functions that remain exposed. (It would be good for mir's ease-of-use to be able to reuse MultiThreadedCompositor)
nits:
#1
31 +namespace compositor{ class Compositor; }
spacing
#2
148 + /// \return the graphics display options.
151 + /// \return the graphics platform options.
In light of the other mentions of 'options' in this header, we should drop 'options' off the end of these comments
#3
detail::ServerAddConfigurationOptions
AdditionalConfigurationOptions or NonstandardConfigurationOptions seems like a stronger name.
#4
OptionType::null seems more like OptionType::bool to me.
So I guess I favor this MP over the alternative, mostly because this one is more straightforward to reason (from a user's perspective) about what is available for use.
In light of the proposed plan, the following is more of a comment; but I'm concerned that we're exposing too much of our internal composition scheduling with the functions that remain exposed. (It would be good for mir's ease-of-use to be able to reuse MultiThreadedCo mpositor)
nits:
#1
31 +namespace compositor{ class Compositor; }
spacing
#2
148 + /// \return the graphics display options.
151 + /// \return the graphics platform options.
In light of the other mentions of 'options' in this header, we should drop 'options' off the end of these comments
#3 :ServerAddConfi gurationOptions gurationOptions or NonstandardConf igurationOption s seems like a stronger name.
detail:
AdditionalConfi
#4
OptionType::null seems more like OptionType::bool to me.