How our settings system work?

[sirherrbatka]

I think that rewritting the whole thing is the right thing to do in situation like this. I will need a lot of time to finish it though (i have a full time job now). If that is not any issue, i will rewrite this. I really don't want to work around the current model, it just does not provide satisfaction to keep me going (we all need motivation for work). Providing consistent list of goals (besides ability to represent nested settings, which is obvious at this point) would be helpfull.

[Zini]

I assume with very long time you don't mean things like 6 months or more? I will do the write up either tomorrow or on Saturday. Shouldn't be to long. The whole thing is currently a lot more complex than it needs to be.

[sirherrbatka]

I'm glad to hear that.

Hopefully i will be able to do that in one month.

[Zini]

Alright then. First the overall design:

User settings are sorted into categories. We have a vertical panel on the left that lists all categories (a bit like a vertical tab bar). When a category item is selected, the right panel shows the corresponding page listing the settings for this category. Every change to the settings takes effect immediately. There is no Okay button (basically the GNOME approach).

On that level the view part of the current implementation is actually okay. The only thing missing are vertical scrollbars that pop up when the content of either panel does not fit.

On to the individual settings (and here comes the problem): A developer adding a new setting should only specify the name of the setting and the data type including required parameters like range for a numeric value (plus label and tooltips as applicable).
The view (the widgets) should be generated by an algorithm instead of manually adding widgets. The idea here is both saving the developer time and ensuring layout consistency. Think of the dialogue subviews. That is basically doing the same thing.

Here the current implementation fails. Originally it was doing the layout manually based on data stored on the model. I "fixed" it by using a global fixed size layout which mostly works but not always. Ideally we would want to work with Qt layouts instead of specifying fixed size values. This should also take care of varying string lengths (localisation) and varying window sizes (the settings window should be resizeable).

It should be possible to simplify the model part greatly. Stuff like the property system currently in use isn't really needed. And we can also cut down on the setting types. ListView, slider and dial are not needed. I doubt we need TextArea. I suggest that RadioButton and ComboBox are merged into a single data type (on the view side use a radiobutton widget for 3 or less options maybe and a combobox widget otherwise).
What we are missing though is a colour data type.

The system should be build in a way that it can support special categories/pages that are not build from individual settings. Prime example here is the column filter page. We will need to add a keybindings page at same point, but that shouldn't bother you now (unless you really want to bother with it).

Updates are send via Qt signals. But settings should also be queryable directly from a singleton-like class. The current implementation is doing that correctly. The signature of the signal may need refinement (not sure if the additional special pages can be handled with the current signature). We should avoid having more than one signal.

And that's the gist of it. Not all that complicated really. Let me know if you have any questions.

[sirherrbatka]

I think that what we really need to have richer experssion of setting types. Strings representing setting type seems to be not enough. What about constructing and passing struct instance instead? We can specify if this is singular setting, list of setting or categorized setting, and then tell if this is supposed to be boolean, string value and so one.

Is that reasonable approach?

[Zini]

Sounds more like a case for unions, which would probably blow up into our faces once we push them through the signal-slot-mechanism. Something like boost::any might be worth considering.

But actually pure strings (not even lists of strings like we currently have) seems to be the best option. From the perspective of reading settings / evaluating settings change signals the type isn't relevant. You don't go about checking if the type is bool and then if he value is false. You check if the value is false and that's it. All type information would do here is provide another check against bugs in the settings code, which is not very useful considering that it is done at runtime.

Even things like the column filters could probably be done with a comma separated list in a single string.

[sirherrbatka]

I was inprecise. What i ment is to change not actual string, but this:

Setting *shaders = createSetting (Type_CheckBox, "shaders", "Enable Shaders");

Type_CheckBox into few separate enums (for instance that would become Type_CheckBox, Type_Singular). But actually model part is also not so clear.

[Zini]

Okay. That makes more sense. I still don't see how structs could be used here. Making a createSetting function that takes a struct is big NO NO. We want to keep the process of creating new settings as simple and streamlined as possible. What I can see is a split into several create functions (createBooleanSetting, createIntegerSettng and so on).

What do you mean by Type_Singular?

[sirherrbatka]

Well, my current undertanding of the problem is that it does not allow to easily present complex settings (like in the case of the column filters). To solve this, I would want to split the type of the view widget into two parts. One showing if this should be just one single widget, a list of settings or a list with a additional dropbox (for instance, to select which filter user wants to alter). Type_Singular would be just one widget in a page.

[Zini]

Trying to push special settings like the column filters or the key bindings through the regular settings interface sounds problematic. The view for the column filters definitely needs to be custom build instead of automatically generated like regular settings pages. There are just too many special functions (e.g. new, delete, clone, rename) to build it from regular primitives. At least I do not see a way to do it without hugely blowing up the complexity of the primitives.