FreeOrion

Forums for the FreeOrion project
It is currently Thu Dec 14, 2017 12:23 am

All times are UTC




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Config options naming
PostPosted: Tue Oct 31, 2017 1:03 am 
Offline
Programmer

Joined: Sun Feb 14, 2016 12:08 am
Posts: 359
Working on changing config options to a common naming scheme.
(TLDR; rework config option names to a consistent style that supports procedural layout, see example at end of post)

Currently the style is all lower case with few underscores and no dashes.

Many of the flags which are not stored in config, were left untouched, such as render-simple.


During initial review, Marcel mentioned naming wrt the Option window.

I've tried to group the options under common parent nodes (delineated by a dot), based on their scope (e.g if it falls under the map window, it becomes a subset of ui.window.map).

Such groups do not align with their containing tab on the Options window (if they are present).

In the majority of cases the options end with a suffix to match the value type (.width / .shown / .path) to assist any potential transition to a procedurally generated options tabs.


Related to such a naming scheme is the --help output. Currently the output needs to be piped to another utility or file to be usable.

I've had a rough idea of allowing a description for a subset of an options nodes. (I've not looked into this idea in detail)

e.g. a stringtable description could be defined for both ui.window.production and ui.window (and then not defined for ui.window.production.fullscreen)

An option of ui.window.production.fullscreen.left_edge would fall under ui.window.production, which in turn falls under ui.window wrt --help

The help output would be changed to show the smallest set of groups requested, a simple --help might be:
Code:
Usage: --help group
setup  -  Options related to game setup values
ui.window  -  Options related to UI windows
misc  -  Miscellaneous ungrouped options


--help ui.window
Code:
ui.window.production  -  Production window settings
ui.window.research  -  Research window settings



A complaint raised by Geoff is many of the option names are difficult to remember.

Some rework is required to shorten the names while retaining common groupings, suggestions on scheme layout is appreciated.

e.g. possibly dropping the ui prefix, and switching to start with the config name:
ui.window.production.fullscreen.width -> production.window.fullscreen.width
ui.window.map.fleet.eta.shown -> map.fleet.eta.shown (note this is not fleet.eta.shown, as the setting is for displaying eta on the map)


Currently the top level nodes are:
audio
content
effects
logging
network
save
setup
ui
version
video

The ui children:
control
description
font
hotkeys
input
name
tooltip
window

(An outdated example config, which I will try to update later)

_________________
Any content posted should be considered licensed GNU GPL 2.0 and/or CC-BY-SA 3.0 as appropriate.


Top
 Profile  
 
PostPosted: Tue Oct 31, 2017 9:29 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12041
Location: Munich
dbenage-cx wrote:
A complaint raised by Geoff is many of the option names are difficult to remember.
The "complaint" was just that I'd have to remember something different from what I do now, eg. "--network.server.external.force" instead of "--force-external-server". It's a minor and personal (so not important) issue.
Quote:
e.g. possibly dropping the ui prefix, and switching to start with the config name:
ui.window.production.fullscreen.width -> production.window.fullscreen.width
ui.window.map.fleet.eta.shown -> map.fleet.eta.shown (note this is not fleet.eta.shown, as the setting is for displaying eta on the map)
I'd drop the window but keep the ui. so
ui.production.fullscreen.width and ui.map.fleet.eta.shown

ui.description.effects.shown -> ui.effects.descriptions.shown

For things like ui.window.map.system.selection_indicator.rpm, why do you still use _ as a separator instead of switching to . consistently? I find the _ more logical in many cases, but having to remember in each case whether a _ or a . is used is problematic, so standardizing on _ everywhere is probably better... But you've kept the _ in seemingly random places, somewhat defeating the purpose...


Top
 Profile  
 
PostPosted: Wed Nov 01, 2017 7:43 am 
Offline
Programmer

Joined: Sun Feb 14, 2016 12:08 am
Posts: 359
I updated the example config with recent changes (branch is not updated), I'll see if I can figure out incorporating a stylesheet for config.xml if readability is a concern.

The recent change removes window from ui.window.*, think a general "ui.windows" could cover the settings not specific to one window.

Incorporated hotkeys into name change, so the hotkey groups any related options (e.g. video.fullscreen.hotkey).
A side effect, the options tab for hotkeys was changed a bit to support any stringtable defined sections.

All of the underscored names were converted, with exception of the logging option for combat_log (logging macro would not currently support combat.log)
Some of these are not ideal, the worst case being the option to hide most of the map window panels/child windows, when displaying production window
ui.production.other_panels.removed -> ui.production.mappanels.removed


Top
 Profile  
 
PostPosted: Thu Nov 02, 2017 4:39 pm 
Offline
Programmer

Joined: Sun Feb 14, 2016 12:08 am
Posts: 359
Comparison of most options, should be easier to read (or import into spreadsheet).
This is based on options present in config.xml after brief play and then manually added old options.
Some options may be omitted, and old options could have typos.


Top
 Profile  
 
PostPosted: Thu Nov 02, 2017 6:56 pm 
Offline
Graphics
User avatar

Joined: Tue Jul 01, 2003 8:27 pm
Posts: 708
That looks a lot cleaner. Nice work.

_________________
If I provided any images, code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0.


Top
 Profile  
 
PostPosted: Thu Nov 02, 2017 10:47 pm 
Offline
Programmer

Joined: Sun Feb 14, 2016 12:08 am
Posts: 359
In hindsight, I should have just deleted the stringtables and matched the results from --help ... would have saved a bit of time and less error-prone.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: AhrefsBot and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group