Add a TreeOptions struct for easy configurability

[way-cooler]

Add a TreeOptions struct for easy configurability

[SnirkImmington]

Why not just list all the options in the struct, and allow Lua IPC methods to construct one from the init file? We could have a FromJson implementation if you wanted IPC clients to be able to reset the tree options (which I don't think would be worth it).

[Timidger]

For reseting the tree options a better solution would to just have that happen during in-place restart. Yeah a struct with just the bare options would be fine, though I want to ensure that the option struct is there from the beginning after reading the options from the config file, because there may be no sane default for a configuration option.

[Timidger]

Cause what I'm thinking is something like this:

// This can all be in the tree initialization, which will be called from callbacks after compositor is initialized 
// options from init file loaded into registry
let fullscreen_request_option: bool = registry.get('ignore_client_fullscreen_request')
    .unwrap_or_else(false);
// more options from the registry
let tree_option = TreeOption::builder().fullscreen_request(fullscreen_request_option).some_other_option(5).build();
// Then construct the tree and pass it these options. The tree exposes it so that people can modify it via a Tree command

And then for the TreeOption I was thinking some macro like the following to make it easy to add methods to the builder:

tree_options! {
    fullscreen_request, String, required;
    // this will wrap some_other_option in an `Option` automatically, whenever you get it there's the chance it's not there.
    some_other_option, u32, optional;
}

[SnirkImmington]

Given #91, we have to figure out how to move our API/registry over to d-bus. Tree settings could be an object in our dbus path, for example. We will need similar structures in many places - layout, background, window decorations, themes, window rules, IPC, etc. We should figure out how we should design those systems before switching.

[Timidger]

Right, but the way that this data is transferred shouldn't change how it's represented in the tree code. I.E Tree will be reading some options struct that will be updated externally, and on each redraw will consult it to know how to draw/what to draw/how to organize the layout. It is possible to work concurrently on this, but if you think this is blocked by that please feel free to instead use the "blocked" tag or to consider moving it to a trello board if you think it's too long-term.