Modes - generic approach

[ilandikov]

As I have seen #1626 I gave some thought about "modes". In Tasks 1.24.0 there are:

• no mode eg nominal mode or call it whatever =)
• short mode
• explain which is actually a mode
• counter mode as an idea

If one thinks about the purpose of each mode - using them in any permutation among is pointless (as opposed to filter, grouper or sorter). Hence the mode's entity and shall be different from a filter, grouper or sorter - in a given query there should be only one mode.

Would you agree with this approach?

PS I'm not introducing this is as an issue since this is obviously 1/ breaking 2/ needs a significant effort. Maybe an idea for Tasks 2.0

[claremacrae]

Hi, I've changed the Category to Development.

For future reference: the old Ideas go in Issues/New Features now, please, not in Discussions, hence I just renamed Ideas here....

(I wish I could lock the Ideas category, but this would prevent adding comments to the existing Ideas..)

[claremacrae]

PS I'm not introducing this is as an issue since this is obviously 1/ breaking 2/ needs a significant effort. Maybe an idea for Tasks 2.0

Understood.

[claremacrae]

Can you please say why you think explain is a mode that cannot be used in conjunction with anything else?

After the explanation, it goes on to do the search, so it actually is already used in conjunction with short and 'normal' modes...

[claremacrae]

Have you seen #1632?

Adding Hybrid Short Mode in Layout - to allow a few requested fields to be displayed even in short mode

This makes me think that 'short mode' should hide all the field detail, and then people should be able to say 'show due' or whatever - so actually the two existing modes would then not be exclusive...

[ilandikov]

Have you seen #1632?

Adding Hybrid Short Mode in Layout - to allow a few requested fields to be displayed even in short mode

Yup, I agree with your conclusion there. But here I'd like to discuss modes and field rendering is different, more as a (layout) filter, which can be used together.

This makes me think that 'short mode' should hide all the field detail, and then people should be able to say 'show due' or whatever - so actually the two existing modes would then not be exclusive...

Maybe I wasn't explicit enough - modes shall be exclusive to each others but not to other entities like filters and/or layout commands. For instance in your example short mode is a mode, but show due is a layout command.

After the explanation, it goes on to do the search, so it actually is already used in conjunction with short and 'normal' modes...

I thought that explanation provides only the explanation, not the task list AND the explanation...

[claremacrae]

No explain does the search as normal, it just explains how it’s doing the search.

[ilandikov]

No explain does the search as normal, it just explains how it’s doing the search.

Ok then this discussion is not explain-relevant =)

[claremacrae]

I’m still missing the benefits of this, but will note that there is already a PR going on - #1519 IIRC - that changes the display code.

perhaps what I am missing is what actual benefits to users or developers any changes in this area might bring?

I do agree that the layout code is in need of refactoring away from its current enumeration-based approach, for maintainability of the code - but that is a totally different issue.

[claremacrae]

I’ve added a note in #1626 saying how I would implement it. No need for any new modes.

[ilandikov]

perhaps what I am missing is what actual benefits to users or developers any changes in this area might bring?

I thought that making a mode framework would benefit introductions of new mode as well as maintenance of the current ones

[claremacrae]

perhaps what I am missing is what actual benefits to users or developers any changes in this area might bring?

I thought that making a mode framework would benefit introductions of new mode as well as maintenance of the current ones

Oh yes, absolutely! Definitely. 100%.

But I wouldn't plan it up front. I would incrementally refactor the code and discover, from what remained at the end, if there were any missing abstractions.

That is how I ended up with the Field classes, for example. I didn't know they were there in advance. I refactored the pre-existing code and they sort of appeared...

And I wouldn't refactor the layout & mode code until the Grouping code has been refactored - that's a much lower-hanging fruit at the moment.