Make the order of the tasks in the summaries stable

[ericzolf]

Regarding the workaround of #171, the worst thing is that the projects/tasks get re-ordered day after day, depending on what one started to work on each day. The order should rather be always the same, either alphanumerical or the order of the tasks as entered in tasks.txt.

Alphanumerical seems easier to implement but task-order gives more freedom to users, as they can influence it without having to name their tasks particularly (I don't care, I can do both).

Originally posted by @ericzolf in #171 (comment)

[ericzolf]

Knowing that I'm completely new to glade and gtimelog's code overall (but have my own Python project), I've started to look into this issue, as it gets on my nerves (good reason, right? 😏 ). Anyway, I planned to align my work with the options win.time-range resp. win.detail-level, and create my own win.sort-order option. They're all listed in src/gtimelog/menus.ui, which is fine and easy to understand, but time-range is also referenced in src/gtimelog/gtimelog.ui whereas detail-level is in src/gtimelog/data/org.gtimelog.gschema.xml (both are also referenced in src/gtimelog/main.py but different story).

Is this different handling wanted or historical, the two variables look similar to me? And to which variable should I best stick for my changes?

Side note: you can assign the issue to me but beware that it can take a bit of time and asking back for me to manage this one 🤷

For reference, development branch is master...ericzolf:gtimelog:ericzolf-sort-order-173

[ericzolf]

OK, I think I got it: detail-level is persistent whereas time-range isn't. Seeing that the usage of gsettings was introduced relatively late, I can only guess that time-range is a forgotten reminder of the old approach.

[mgedmin]

No, AFAIR this is intentional. The use of gsettings (as well as property bindings to make widgets react to menu items/settings changes) was all done during the port to GTK 3. I think I decided that the detail level needs to be persistent because it reflects user preferences, but time range is a temporary thing that you use for a bit before returning to daily task entry. It was a while ago, so I can't be sure I remember my motivations correctly.

The chronological order of tasks in summary views is also intentional, from even earlier times. I'm not sure I can articulate why it felt right to me to do it that way.

If task entry into Jira is your primary motivator for this, please consider whether https://github.com/ProgrammersOfVilnius/gtimelog2jira would make your life easier. (It does for me!)

[ericzolf]

OK, wrong logic but right decision: I'd like my new option to be sticky.

It's not Jira but another tool, which is going to change soon, and without known/reachable API 😞 but perhaps I can take some ideas to create my own report, but that would be more something for #171