-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need a standard for organizing dbar options in .conf file #4
Comments
I think I'm going to need an example to better understand this. |
This is what I was thinking, general:
order: [ clock, weather, load, mem, git, vol, song, ephemeral]
clock:
block:
clock_format: %Y-%m-%d %H:%M
i3bar:
min-width: 8888-88-88 88:88
weather:
block:
woeid: 2405641
units: f
i3bar:
separator: false
separator_block_width: 3 |
Oh I see. I like where you are going with this. I think we can do better by just reserving any of the member names in the i3bar format from being used by config options on the lowest objects. That way we won't have any namespace collisions and we won't have to make the config object too nested. Then we can automatically set the i3bar properties from the daemon so each generator won't have to worry about doing it themselves. |
Also, I think it would be a good idea to reserve the i3bar members on the |
plus |
Came up with a coupe of followups. Should the standard include prefix and suffix options for full_text and short_test? Say I want to include a memory module that returned a simple percentage of memory available. but I want to label it as Ram:. I can easily include a prefix_full entry in my i3-dstatus, I'm asking should there be a standard that we encourage people to use. general:
order: [ clock, weather, load, mem, git, vol, song, ephemeral]
color: #fdf6e3
align: center
clock:
clock_format: %Y-%m-%d %H:%M
min-width: 8888-88-88 88:88
weather:
woeid: 2405641
units: f
separator: false
separator_block_width: 3
prefix_full_text: FoCo Whose job will it be to apply the defaults from the general section? If it's the Aggreagators job, then we need to layout who gets precedence to apply their default. If it's the generators (and I think it should be) then we need to decide how we're going to get that data to the generator? {
"color": "#fdf6e3",
"align": "center",
"min-width": "8888-88-88 88:88",
"clock_format": "%Y-%m-%d %H:%M"
} OR {
"general": { "color": "#fdf6e3", "align": "center"} ,
"min-width": "8888-88-88 88:88",
"clock_format": "%Y-%m-%d %H:%M"
}
|
I do think there should be a standard on the config but I'm not exactly sure what it should be so I'm open to discussing ideas. Here are some of my ideas: Generators should always use the Underscores should be equivalent to dashes. Dashes should be preferred. Any key that is within the i3bar protocol should be set to that value when the block is shown. If the key is under For the actual application of the i3bar protocol keys, I think the aggregator should be responsible for applying the defaults simply because it removes code duplication across all of the generators. |
I've implemented this in 0ae97bd in the way I've described above. Example:
|
I'm cheating and making most of my settings default in the block_generators I'm working on, but this is how a simple conf file looks. ---
general:
order: [ git, mediaplayer, volume, memory, load, weather, clock ]
weather:
units: f
woeid: 2405641
git:
markup: pango |
I think this can be closed unless you have anything else to add |
I just ran into this situation and I immediately started trying to solve it, then I came here to look for a standard, and I didn't find one.
The problem is this, I have a weather summary that I like to get every 15 minutes, for me to correctly configure it in an open way, I have to pass the generator a woeid denoting the location for the report, and units of measurement for the temperature. I also want to be able to pass arguments to set dbar protocols settings. the question is how do we organize that data consistently in the ~/.i3-dstatus.conf file and not have to remember how this or that generator does things.
I propose that the option hash to have 2 sub hashes, named :i3bar, and :block where the former keeps the settings for various things for the i3bar return, and generator for any options needed by the generator like locations, formats, and units. this allows us to iterate over the 2 sub options and not have to worry about filtering this or that out, and it will make for a more understandable config file. It will be a bit larger and more verbose. but well structured and easy to understand content is the very hallmark of a good configuration file.
The text was updated successfully, but these errors were encountered: