(Preliminary) pull req - settings instead virtual_midnight and data_file

[standagh]

Hallo Marius.

I'm sending 2 preliminary pull requests. So you can see what I'm working on.

In this pull request I'm using settings instead virtual_midnight and data_file. Settings are availeble in TimeLog and TimeWindow classes. Inside the classes values are retrieved directly from settings.

Data_file is alse added as settings parameter. Resolved in constructor of settings or when settings are loaded from file.

What do you think about it. If there are many errors like PEP8/formatting, ignore them for now. Is this idea better than in later pull request?

[mgedmin]

I think the filename is more important and should be the 1st argument.

I intend to change the parser at some point to look for blank lines as an indication that the next day started, instead of doing complicated comparisons with virtual_midnight. This would perhaps even mean that you can use a TimeLog() without passing in settings, eventually, maybe.

[mgedmin]

I don't like this, but I find it difficult to articulate why.

For one, this is a huge diff that mixes several changes in a single commit.

Another thing, I want to reduce coupling, and by having TimeLog/TimeWindow use the Settings object that is full of GUI bits makes me sad. At one point I was thinking of splitting the Settings into non-GUI bits (virtual-midnight) and GUI bits (everything else), but the more I think of it, the more I become convincing that parsing a timelog.txt shouldn't need any configuration settings. I was always careful about writing blank lines to separate days, and if I changed the parser to take that into effect, it would no longer require virtual-midnight.

[standagh]

Hi Marius.

What I would like to have is some kind of global application object, that is available in application parts. Object that holds the state of the application and is passed to constructors of application parts. I think, the object Settings is good for it. So if there is a need to have some parameter available, some application state, it will be added into Settings and immediately available wherever needed.
That's why I also added data_file to Settings. In recent version data_file is received by Settings methods, but it's name is created dynamically - path+constant and later passed to methods as separate parameter. I think, data_file should be available as property of Settings. And if Settings is passed as parameter to constructors of application parts, data_file is right ahead available there. No need for separate method parameter.
The point, I'm trying to get to, is to add subcategories to GTimeLog in a way that will be optional - whether I want to use subcats or I don't should be easy to switch. But to make it working Settings available in parts of the application will make changes much easier (and not only this one).
For example if method invocation is changed - some parameter is added/removed, many test cases are invalid immediately. So if anybody wants to send some code where he wants to get some value from application Settings to wherever he needs it, he is forced to change method signatures and if he doesn't make appropriate change to many test cases what he gets? Test failures.

What case do I have to have data_file as parameter? Why to store it in a configuration file? I think data_file is just plain value, it should not be created dynamically. And I would like it to be in (my) configuration file. But I can imagine that you wont, and there may be more parameters that should be available during app runtime but not written into configuration file. I propose to have some "write filter". Sequence of parameter names, that should be written into file. If parameter is not on the list, it just won't be written.

Days splitting by blank line - I think it can work for reading/parsing data file and can be convenient to even have different "virtual midnight" for different days. I like the idea. But how gtimelog will know, when it should put/write blank line into data file? IMO this is the place where "virtual midnight" has to be available to application. What if "virtual midnight" will be used as default day separator for writing, but for reading parser will depends on blank line?

[mgedmin]

Sorry for responding late. I'm on vacation trying to deal with burnout, and am not feeling up to reading walls of text right now. I'll come back later.

[standagh]

Thanks for info. I consider gtimelog as free time project so when you find time to respond, respond.
Enjoy vacation. It's good to have some free days once in a while. Have a good time.

[mgedmin]

What I would like to have is some kind of global application object, that is available in application parts. Object that holds the state of the application and is passed to constructors of application parts.

Meanwhile I want a strict separation between the GTK+ GUI bits and the non-GUI bits that deal with data parsing/updating/analysis. I also want the data parsing/updating to be config-independent.

The point, I'm trying to get to, is to add subcategories to GTimeLog in a way that will be optional - whether I want to use subcats or I don't should be easy to switch.

Agreed: users who aren't interested shouldn't be forced to care.

But to make it working Settings available in parts of the application will make changes much easier (and not only this one).

Why? Parsing code shouldn't care. Updating code shouldn't care. Analysis might care (but I have a hunch multiple methods are better than a single method with options). Reporting will care.

It may make sense to extract a ReportSettings interface that contains all the options for reports, and then have the main Settings object extend it with all the other options. (Since Python doesn't have interfaces, I'm thinking of a ReportSettings class that has a bunch of attributes with comments but no .ini parsing/updating code, since it's not meant to be used separately.)

Days splitting by blank line - I think it can work for reading/parsing data file and can be convenient to even have different "virtual midnight" for different days.

That's in fact precisely my inspiration for this: I had a couple of long nights and had to change my virtual_midnight setting once ;-)

But how gtimelog will know, when it should put/write blank line into data file? IMO this is the place where "virtual midnight" has to be available to application. What if "virtual midnight" will be used as default day separator for writing, but for reading parser will depends on blank line?

That's precisely my plan. I'm also thinking about adding a .start_new_day() API to the TimeLog class, and keeping the "is it a new virtual day?" logic in the GUI. I want to make it possible to replace that logic with a "Start a new working day" button in the GUI, but this part of the plan is a bit fuzzy yet.