Ferreteria/v0.6/clade/Sys/Events/InputRq/aux/InRqData/@thinking

• By default, this breaks up the input-processing into sensible chunks which can be overridden while minimally changing the overall logic.
• 2025/02/14 Ok, there's a problem with how we handle the input data. Things get muddled. I only noticed this because it was getting into a recursive loop with trying to process the input during setup -- we need to process after that. Also, why does QRaw() keep a QStr as a separate variable when it can just check InRq()->Input()?
• 2025/02/15 I think it needs to work like this (update from 2025-10-09): this actually did not quite make sense):
  • There are two kinds of data:
    • (1) values currently being set ("curr")
    • (2) values retained from being set earlier ("kept")
  • Each object for each of these holds an array where all the values are kept.
  • There will be one "kept" data-object, and a separate data-object for each "curr".
  • There will be different classes to provide setting-specific views into each array.
  • The same class can be used for both (but obviously we need a separate object for each).
  • The "curr" object can pull up a corresponding "kept" object as needed.
• 2025/03/08 ...and it seems like a good way to generalize this is that any InRqData object can point to another one as a set of defaults. Then we can add lookup functionality which reverts to the default if not found here. (In theory, we could then add additional layers of defaults if wanted, e.g. local installations might have instance-specific defaults.)