How our settings system work?

Involved development of the OpenMW construction set.
User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: How our settings system work?

Post by sirherrbatka » 23 Aug 2015, 14:34

i imagine that we could pass additional information about those properties as vector of enums. But at the same time i think that this is probabbly not worth the effort.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: How our settings system work?

Post by Zini » 23 Aug 2015, 15:25

Yeah, it would be doable. With a lot of effort. But what for? The goals of the model design are to allow easy adding of new settings and ensure consistent view layout. Neither of these applies to the column filters. Let's not fall into the trap of over-designing things again. That's what killed off the current implementation.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: How our settings system work?

Post by sirherrbatka » 26 Aug 2015, 16:54

Ok, I was doing some research on that task in code. Seems to be rather simple. Though, despite of your usual, very precise description of problem I have few small questions.

First of:
"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)."

Current implementation does that, essentially. Initially i thought that you want to replace widget type (like Type_CheckBox) with true data type (like Type_Boolean) but later on you refer to data types with widget voculbary. I'm slightly confused on this topic. My current understanding is that i should not change this part (or changed by removing additonal types that are not needed, as well as get rid of the properties (that is: QList <QStringList> mProperties). Is that correct?

"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."
I assume that at this point it is pretty much ok to hardcode those special pages. We were discussing this earlier, if I'm correct.

I will take some notes on how to implement those changes and start working on actual code. Cleaning up model is what i should do as the first thing i think.

PS
This code seems to have memory leaks here and there. For instance connectors are never deleted after creations, virtual destructors are missing in few classes. Nothing serious since those are alocated IIRC once in opencs instance.

PPS
Do we need to change/extend connector class? It seems that we map widgets using string. Not sure how this coresponds to column filters.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: How our settings system work?

Post by Zini » 26 Aug 2015, 19:45

Current implementation does that, essentially. Initially i thought that you want to replace widget type (like Type_CheckBox) with true data type (like Type_Boolean) but later on you refer to data types with widget voculbary. I'm slightly confused on this topic. My current understanding is that i should not change this part (or changed by removing additonal types that are not needed, as well as get rid of the properties (that is: QList <QStringList> mProperties). Is that correct?
What you call them isn't really that important per se. But using data terminology (boolean) instead of widget terminology (check box) would certainly be clearer. There is also the case of combo box and radio buttons where we really only need one type, which would make widget terminology suboptimal. So if you don't mind renaming things the data terminology would certainly be better.

The whole property system is overkill IMO, mostly because the Setting class has way more data fields than it should have. So yes, removing it sounds generally like a good idea, but I have not looked into the specifics. Using a polymorphic approach (one subclass for each type) might be an option here, but I'll leave that decision to the implementor.
"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."
I assume that at this point it is pretty much ok to hardcode those special pages. We were discussing this earlier, if I'm correct.
Correct. That's not just okay, that is the whole point of the special pages. There will be only one of each, so there is no point in a more generic implementation that makes adding more of each easier and more consistent.
PPS
Do we need to change/extend connector class? It seems that we map widgets using string. Not sure how this coresponds to column filters.
The main point of the connector seems to be to support the resolution setting (if I understand it correctly). Maybe try to get rid of it and just add resolution as another data type, which is then displayed with the 3 widget approach we currently have?

Edit: Just so we are clear:
Current implementation does that, essentially.
It does that, but the current approach is utterly broken. That is actually the main point why a rewrite is needed. Currently the individual setting holds fixed layout information (width and stuff). Originally you had to specify these for every setting. My revised version is using default values. Both approaches are bullshit. These values shouldn't exist in the first place.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: How our settings system work?

Post by sirherrbatka » 26 Aug 2015, 20:07

It does that, but the current approach is utterly broken. That is actually the main point why a rewrite is needed. Currently the individual setting holds fixed layout information (width and stuff). Originally you had to specify these for every setting. My revised version is using default values. Both approaches are bullshit. These values shouldn't exist in the first place.
This actually doesn't sound like something really complicated to do. Widget creation and insertion is all done in just one place. There are places in model that require substential changes, and some others that seems to be nice to change as well BUT Isn't calling it "rewrite" a bit aggressive? Am I missing something?

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: How our settings system work?

Post by Zini » 27 Aug 2015, 08:14

Well, you are removing large parts and adding stuff too. I wouldn't expect too much code to stay unchanged. That is rewrite-ish. But let's not argue semantics here.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: How our settings system work?

Post by sirherrbatka » 27 Aug 2015, 16:32

No, there is no point in further discussion. I will start by removing properties. Not sure what is actually used here so i will simply remove it compeletly and see what will brake.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: How our settings system work?

Post by sirherrbatka » 02 Sep 2015, 16:58

Status update. I'm finally able to work. Great.

I'm currently removing properties. Some elements that are setted there are obviously not required (column span, multiline stuff etc.). Some should be simply a member field in the setting (like name). Some has purpose unknown to me at this point. Hopefully i'm poking this from the right end.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: How our settings system work?

Post by sirherrbatka » 09 Sep 2015, 16:33

I'm terribly sorry.

I don't think i have enough time to work on opencs. I feel terrible for letting you down and breaking my word, but this is how it is and I need to admit it.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: How our settings system work?

Post by Zini » 11 Sep 2015, 11:39

Well, shit happens. At least with this thread we have now a reasonable documentation about what needs to be done.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests