Refactoring of Options
Widelands has a lot of different options and quite a lot of these have not even a user interface to set them. Further there are two option menus (mainmenu and ingame) and both behave quite different and allow different options. And last but not least the config file saves all values in section [global] which leads to the hack in wlapplication.cc to mark each option as used manually.
So refactoring should consist of:
* DONE: Saving the options in fitting sections (sound, graphics, network, gameplay, chat, ...)
* DONE: Creating a tabbed options widget,
** TODO ... that can be used in the main menu and in game / in editor.
** TODO: A Boolean variable during initialization of that widget should disable options, that can't be changed in the situation (e.g. I am not sure if switching the resolution in game is working).
* DONE: Adding a option_checkbox widget, which combines a checkbox with a label. Using that widget will drastically smaller the amount of code for the options widget.
Links from Timowi for option arrays, that can be read out by the help function (command line) and the options menu:
* http://
* http://
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Low
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- Accepted for build20
- Implementation:
-
Good progress
- Milestone target:
-
build21-rc1
- Started by
- GunChleoc
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Timowi:
>
> What do you think about "auto-generation" the options (at least partly)? The current options code
> (options screen and command line) is hard to handle and inconsistent. Perhaps even use a
> external library to read command line parameters?
>
>The options screen, command line options and help could be generated out of configuration
> arrays. The --help (or --usage?) output can be generated out of this and command-line and
> options screen could use this. This would make it easier to add options and the different parts
> are always in sync.
Nasenbaer:
Sounds interesting at the first moment, but this would only be working for the checkbox options.
In fact I do not think, that there will be much more option additions in next time, so it's more work to do all the autogeneration stuff than adding one to three new options in the next year.
Of course my opinion :). So tell me, if you disagree.
Shevonar:
I tried to make a collection of all options and where they currently can be changed. I also tried to group them in fitting sections but some of them are discussible. Have a look at it here: http://
GunChleoc: Options have been redesigned in ui_fsmenu. What hasn't been done yet is to use the full set of options in the wui, and having multiple sections in the options file.
