GijsTimmers / kotnetcli

An easy automated way to log in on Kotnet.
GNU General Public License v3.0
5 stars 4 forks source link

Configure colorama communicator via front-end yaml config file #91

Open GijsTimmers opened 8 years ago

GijsTimmers commented 8 years ago

Seems to be a built-in:

https://landscape.io/github/GijsTimmers/kotnetcli/14/modules/kotnetcli/communicator/fabriek.py#L50

We're probably better off using something else. Some suggestions:

jovanbulck commented 8 years ago

Ok, looking back, this constant should probably be defined in coloramac.py. A ColoramaCommunicator should then take an optional colorlist as an argument. If this argument is not present, fall back to THE_DEFAULT_COMMUNICATOR_COLORS.

Moreover, the way colors are now passed in the front-end -- via cli options -- is too complicated and not scalable. A better option would probably be to parse a yaml config file, if present. When creating a coloramacommunicator, the front-end could then pass on an optional color list to the fabriek.

GijsTimmers commented 8 years ago

A ColoramaCommunicator should then take an optional colorlist as an argument. If this argument is not present, fall back to THE_DEFAULT_COMMUNICATOR_COLORS.

Sounds good.

A better option would probably be to parse a yaml config file, if present.

Agreed. I will work on this.

GijsTimmers commented 8 years ago

I created a yaml config file. It's not yet used. Please import as follows:

with open("kotnetcli.conf", "r") as f:
    configuration = yaml.load(f)

print(configuration)
{'FAIL': 'red', 'style': 'bright', 'OK': 'green', 'institution': 'kuleuven', 'WAIT': 'yellow'}
jovanbulck commented 8 years ago

I created a yaml config file

Ok, looking good. For clarity, we might want to adhere to a hierarchical syntax for communicator-specific options. e.g.

## colorama communicator-specific options
coloramac.OK:    green
coloramac.WAIT: yellow
coloramac.FAIL:  red
coloramac.style:  bright
GijsTimmers commented 8 years ago

I see what you mean. A problem with your proposal is that a user who wants to change the colours does not necessarily know what colorama or even a Communicator is. I don't think every user looks at the source code as often as we do. In that case, OK = ... is easier than coloramac.OK = .... Maybe this will suit both the novice and the advanced user:

colors:
    OK:    green
    WAIT:  yellow
    FAIL:  red
In [7]: with open("kotnetcli.conf", "r") as f:
    opties = yaml.load(f)

In [8]: opties
Out[8]: 
{'colors': {'FAIL': 'red', 'OK': 'green', 'WAIT': 'yellow'},
 'institution': 'kuleuven',
 'style': 'bright'}
jovanbulck commented 8 years ago

Ok, apart from end-user convenience, we'll have to guard cohesion here. That is, ideally the front-end should not know too much about Communicators. That is why they are created through a Fabriek.

We might be able to use your idea of a colors key-value array in the yaml file as a generic mechanism to pass user-defined options on communicator creation. The front-end could simply pass the key-value array that belongs to the chosen communicator option to the Fabriek which then passes it on to the new Communicator object. The front-end does not "understand" the contents of this array, only passing it on...