Skip to content
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

Open
anithri opened this issue Mar 16, 2015 · 10 comments
Open

Need a standard for organizing dbar options in .conf file #4

anithri opened this issue Mar 16, 2015 · 10 comments

Comments

@anithri
Copy link
Contributor

anithri commented Mar 16, 2015

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.

@acrisci
Copy link
Member

acrisci commented Mar 16, 2015

I think I'm going to need an example to better understand this.

@anithri
Copy link
Contributor Author

anithri commented Mar 16, 2015

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

@acrisci
Copy link
Member

acrisci commented Mar 16, 2015

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.

@acrisci
Copy link
Member

acrisci commented Mar 16, 2015

Also, I think it would be a good idea to reserve the i3bar members on the general object as well. Then you could set global defaults from there, which can be overridden by the block level configuration.

@anithri
Copy link
Contributor Author

anithri commented Mar 17, 2015

version, stop_signal, cont_signal, click_events
full_text, short_text, color, min_width, align,
name, instance, urgent, separator,
separator_block_width

plus general at the top level

@anithri anithri closed this as completed Mar 17, 2015
@anithri
Copy link
Contributor Author

anithri commented Mar 18, 2015

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?
would it look like this? Taken from the above file

{
  "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"
}

@anithri anithri reopened this Mar 18, 2015
@acrisci
Copy link
Member

acrisci commented Mar 19, 2015

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 get_config method on the dbus object. This returns a json string for the given key in the config.

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 general, it should apply to all blocks by default, but that should be overridden by a specific block config. The generator should have the final say in the matter with what it sends to the aggregator with show_block.

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.

@acrisci
Copy link
Member

acrisci commented Mar 19, 2015

I've implemented this in 0ae97bd in the way I've described above.

Example:

general:
    separator: false
    separator_block_width: 36
disk:
    '/':
        separator: true
        separator_block_width: 7
focused-window:
    color: '#ffffff'

@anithri
Copy link
Contributor Author

anithri commented Apr 22, 2015

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

@anithri
Copy link
Contributor Author

anithri commented Apr 22, 2015

I think this can be closed unless you have anything else to add

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants