Difference between revisions of "New setting structure"

From Armagetron
(Got to make a stub about this, but at least i finally started)
 
m (add blueprint link)
Line 1: Line 1:
 +
{{Blueprint|settings}}
 +
 
Currently, settings are put together in a "flat" manner, ie. related settings are sometimes not grouped together, which causes confusion and eats children. If that was not enough, admin commands are mixed in, too, and it's soon going to be a real mess when scripting/modules/other becomes usable. This is why I think commands should be put away from settings (and that's why I wont be talking about admin commands here) and that settings should be organized in a better way.
 
Currently, settings are put together in a "flat" manner, ie. related settings are sometimes not grouped together, which causes confusion and eats children. If that was not enough, admin commands are mixed in, too, and it's soon going to be a real mess when scripting/modules/other becomes usable. This is why I think commands should be put away from settings (and that's why I wont be talking about admin commands here) and that settings should be organized in a better way.
  

Revision as of 15:08, 21 September 2008

This wiki page has an associated Blueprint on launchpad.

Currently, settings are put together in a "flat" manner, ie. related settings are sometimes not grouped together, which causes confusion and eats children. If that was not enough, admin commands are mixed in, too, and it's soon going to be a real mess when scripting/modules/other becomes usable. This is why I think commands should be put away from settings (and that's why I wont be talking about admin commands here) and that settings should be organized in a better way.

Goals

  • Structured settings tree (Give the rim(flat!) a break! Hug a tree instead!)
  • Put a line between admin command and setting
  • Ghost settings (allowing a setting to be set BEFORE it gets declared)
  • nSettingItem backward compatibility

General concept overview

TODO