## Goal This PR creates the initial settings ui structure with the primary goal of making a settings UI that is - Comprehensive: All settings are available through the UI - Correct: Easy to understand the underlying JSON file from the UI - Intuitive - Easy to implement per setting so that UI is not a hindrance to future settings changes ### Structure The overall structure is settings layer -> data layer -> ui layer. The settings layer is the pre-existing settings definitions, that implement the `Settings` trait. The data layer is constructed from settings primarily through the `SettingsUi` trait, and it's associated derive macro. The data layer tracks the grouping of the settings, the json path of the settings, and a data representation of how to render the controls for the setting in the UI, that is either a marker value for the component to use (avoiding a dependency on the `ui` crate) or a custom render function. Abstracting the data layer from the ui layer allows crates depending on `settings` to implement their own UI without having to add additional UI dependencies, thus avoiding circular dependencies. In cases where custom UI is desired, and a creating a custom render function in the same crate is infeasible due to circular dependencies, the current solution is to implement a marker for the component in the `settings` crate, and then handle the rendering of that component in `settings_ui`. ### Foundation This PR creates a macro and a trait both called `SettingsUi`. The `SettingsUi` trait is added as a new trait bound on the `Settings` trait, this allows the type system to guarantee that all settings implement UI functionality. The macro is used to derived the trait for most types, and can be modified through attributes for unique cases as well. A derive-macro is used to generate the settings UI trait impl, allowing it the UI generation to be generated from the static information in our code base (`default.json`, Struct/Enum names, field names, `serde` attributes, etc). This allows the UI to be auto-generated for the most part, and ensures consistency across the UI. #### Immediate Follow ups - Add a new `SettingsPath` trait that will be a trait bound on `SettingsUi` and `Settings` - This trait will replace the `Settings::key` value to enable `SettingsUi` to infer the json path of it's derived type - Figure out how to render `Option<T> where T: SettingsUi` correctly - Handle `serde` attributes in the `SettingsUi` proc macro to correctly get json path from a type's field and identity Release Notes: - N/A --------- Co-authored-by: Ben Kunkle <ben@zed.dev>
77 lines
2.2 KiB
Rust
77 lines
2.2 KiB
Rust
use dap_types::SteppingGranularity;
|
|
use gpui::{App, Global};
|
|
use schemars::JsonSchema;
|
|
use serde::{Deserialize, Serialize};
|
|
use settings::{Settings, SettingsSources, SettingsUi};
|
|
|
|
#[derive(Copy, Clone, Debug, Serialize, Deserialize, JsonSchema, PartialEq, Eq, SettingsUi)]
|
|
#[serde(rename_all = "snake_case")]
|
|
pub enum DebugPanelDockPosition {
|
|
Left,
|
|
Bottom,
|
|
Right,
|
|
}
|
|
|
|
#[derive(Serialize, Deserialize, JsonSchema, Clone, Copy, SettingsUi)]
|
|
#[serde(default)]
|
|
#[settings_ui(group = "Debugger", path = "debugger")]
|
|
pub struct DebuggerSettings {
|
|
/// Determines the stepping granularity.
|
|
///
|
|
/// Default: line
|
|
#[settings_ui(skip)]
|
|
pub stepping_granularity: SteppingGranularity,
|
|
/// Whether the breakpoints should be reused across Zed sessions.
|
|
///
|
|
/// Default: true
|
|
pub save_breakpoints: bool,
|
|
/// Whether to show the debug button in the status bar.
|
|
///
|
|
/// Default: true
|
|
pub button: bool,
|
|
/// Time in milliseconds until timeout error when connecting to a TCP debug adapter
|
|
///
|
|
/// Default: 2000ms
|
|
pub timeout: u64,
|
|
/// Whether to log messages between active debug adapters and Zed
|
|
///
|
|
/// Default: true
|
|
pub log_dap_communications: bool,
|
|
/// Whether to format dap messages in when adding them to debug adapter logger
|
|
///
|
|
/// Default: true
|
|
pub format_dap_log_messages: bool,
|
|
/// The dock position of the debug panel
|
|
///
|
|
/// Default: Bottom
|
|
pub dock: DebugPanelDockPosition,
|
|
}
|
|
|
|
impl Default for DebuggerSettings {
|
|
fn default() -> Self {
|
|
Self {
|
|
button: true,
|
|
save_breakpoints: true,
|
|
stepping_granularity: SteppingGranularity::Line,
|
|
timeout: 2000,
|
|
log_dap_communications: true,
|
|
format_dap_log_messages: true,
|
|
dock: DebugPanelDockPosition::Bottom,
|
|
}
|
|
}
|
|
}
|
|
|
|
impl Settings for DebuggerSettings {
|
|
const KEY: Option<&'static str> = Some("debugger");
|
|
|
|
type FileContent = Self;
|
|
|
|
fn load(sources: SettingsSources<Self::FileContent>, _: &mut App) -> anyhow::Result<Self> {
|
|
sources.json_merge()
|
|
}
|
|
|
|
fn import_from_vscode(_vscode: &settings::VsCodeSettings, _current: &mut Self::FileContent) {}
|
|
}
|
|
|
|
impl Global for DebuggerSettings {}
|