'show tree' does not render non-task checkboxes

[dimiarbre]

Please check that this issue hasn't been reported before.

• I searched previous Bug Reports didn't find any similar reports.

Steps to reproduce

1. Launch obsidian sandbox
2. Install tasks plugin
3. Set global filter to #task, and disable/re-enable the plugin as I couldn't reload the sandbox directly.
4. Create a "Testing note" note, and use the following content:

# Task query:
```tasks
filename includes Testing note
show tree
```

# Task definition
- [ ] #task Testing trees ➕ 2024-11-05
	- This is a sub-bullet 
	- [ ] This is a sub checkbox - it does not appear in the tree
	- [ ] #task This is a sub-task - it does appear in the tree

Expected Behavior

First of all, thanks a ton for the amazing plugin!
I think tree view is not yet 100% stable, but I really enjoy the idea as I already use tree structures when defining my tasks.

In this case, I expected to see non-task checkboxes rendered like bullet points currently are (see example in current behavior). Maybe the bullet points behavior is also bound to change, so this is not a priority, but I did not find any documentation/other reference to this behavior.

Current behaviour

Non-task Checkboxes simply do not appear in the query result. On the left is the source view. Right is the reading view, but the live preview mode also has the same behavior as the reading view.

Which Operating Systems are you using?

• Android
• iPhone/iPad
• Linux
• macOS
• Windows

Obsidian Version

1.7.5

Tasks Plugin Version

7.13.0

Checks

• I have tried it with all other plugins disabled and the error still occurs

Possible solution

No response

[claremacrae]

Hi, thanks for the feedback.

Really it never occurred to me that someone would have nested lines some of which matched the global filter and some did not.

The Tasks plugin basically just ignores task lines with no global filter.

Can you please give a real-world example of why you would mix by types of task line?

[dimiarbre]

Before tree view, I found that writing everything as a task was a bit tedious and would flood my view/queries, and I focused on having fewer, bigger tasks, where I would write subgoals using non-task checkboxes.

Concretely:

• #task A somewhat big task (the feature I need, experiments I should run,...)
  • smaller task that requires context of the bigger task to make sense
  • miscellaneous idea of things to try to achieve this task, not very thought through.
  • basic remark about this task

For example, I have:

• #task Look at Dirichlet partitionning results to see if I attacks scale well ➕ 2024-11-08 ⏳ 2024-11-11 📅 2024-11-11
  • #task Launch attack on Dirichlet partitionning. ➕ 2024-11-11 ⏳ 2024-11-08 📅 2024-11-08 ✅ 2024-11-08
    • Adapt the attack code
    • Test the code on the computing grid
    • Attacks seems to take more VRAM than expected.

And since I consider I was supposed to do all the subtasks on the same date as the parent task, I don't really bother with defining them as tasks, as otherwise, they would appear under my "task without a scheduled date" filter.
Before tree view they would also appear as standalone task, that cluttered the queries since there was no structure (a "Test the code" task does not give me any information)

To me, this seemed like my ideal workflow, and I naturally organized tasks like this before Tree view. Hence, Tree view seems to be perfect for this approach. The only issue I faced is those checkboxes not appearing in the queries.

I'll also try in the upcoming week to define everything as a task, see how it feels and to have a more objective idea of how this would work, since I never really tried it properly. At the very least, tree view gives me more option, and they deserve a more thorough investigation on this front.

[claremacrae]

Thank you very much. I look forward to hearing back about your experiments...
I'll leave the question label on, as a reminder for me to come back and check on progress...

[claremacrae]

Note to self: A summary is that the mixture of nested tasks with and without the global filter was a nice workaround for the absence of a tree view in Tasks - and so in and of itself, is not likely to be a pressing case for this issue to be addressed.

[claremacrae]

Just to note that the parent/child code is not designed to handle non-task checkboxes...

We have these classes:

• ListItem which is a pure list item, that does not have a [ ]. It does not have a way to store the extra info about [, ], and the character in between.
• Task which inherits ListItem and is a checkbox that is recognised by Tasks... That is, it has the global filter, if the user defined one.

This means it's going to be non-trivial to support this.

I'll leave it for another day or two, whilst I think about it some more. But my current inclination is to close this as 'not planned' for now, as a low priority...

[dimiarbre]

Thanks a lot for looking into it on your end!
I just wanted to give a quick feedback about my current setup.
After looking into converting every checkbox into tasks, I made the following observations:

• I often create a very quick list of checkboxes for various reasons (for instance, to write a set of parameters for experiments I have to do/that failed).
• I really like the option that automatically dates the done date when checking a box

Those two observations do not always combine well for me. For instance, this automatic date makes those somewhat random checkboxes appear in some of my queries (like my "done today" query).

I can think of some workarounds, but that would, I believe, also require significant changes to the current plugin (like having multiple types of tasks: one with tag #task and another without global filters/another tag, and being able to set parameters, such as automatic done date, separately for each and query those independently).

When I wrote this issue (and given the additional context you provided about the code), I assumed non-tasks checkboxes should simply behave like ListItem, because this was my expected behavior for tree view. But I completely understand that it is not that simple given the current code (I have a very limited knowledge of JS). Since this issue also probably arises from my use of Obsidian, I also understand that this is not a priority for the plugin.

From your explanation, my naive approach would have been to create a CheckboxItem class, inherited from ListItem, that only stores the missing [] information as well as what's in between the brackets, in addition to what ListItem does. I think it would also be possible to make Tasks inherit from this CheckboxItem.

Do you think, from your experience, that this is a feasible solution? If yes, I'll be making a note to try this solution on my end once I have time (should be in December), and if it works I'll try to open a PR. But as I have close to no experience in JS, this is possibly too naïve of a solution.

[claremacrae]

Sorry, can you please summarise the question succinctly?

[claremacrae]

Thanks a lot for looking into it on your end! I just wanted to give a quick feedback about my current setup. After looking into converting every checkbox into tasks, I made the following observations:

• I often create a very quick list of checkboxes for various reasons (for instance, to write a set of parameters for experiments I have to do/that failed).
• I really like the option that automatically dates the done date when checking a box

Those two observations do not always combine well for me. For instance, this automatic date makes those somewhat random checkboxes appear in some of my queries (like my "done today" query).

I can think of some workarounds, but that would, I believe, also require significant changes to the current plugin (like having multiple types of tasks: one with tag #task and another without global filters/another tag, and being able to set parameters, such as automatic done date, separately for each and query those independently).

There is already a Tasks mechanism for toggling tasks and not adding done-dates... Use a custom status with type NON_TASK:

• https://publish.obsidian.md/tasks/Getting+Started/Statuses/Status+Types#NON_TASK

When I wrote this issue (and given the additional context you provided about the code), I assumed non-tasks checkboxes should simply behave like ListItem, because this was my expected behavior for tree view. But I completely understand that it is not that simple given the current code (I have a very limited knowledge of JS). Since this issue also probably arises from my use of Obsidian, I also understand that this is not a priority for the plugin.

It doesn't arise from Obsidian, it arises from the current Tasks code.

From your explanation, my naive approach would have been to create a CheckboxItem class, inherited from ListItem, that only stores the missing [] information as well as what's in between the brackets, in addition to what ListItem does. I think it would also be possible to make Tasks inherit from this CheckboxItem.

That is a reasonable suggestion - this all comes down to tradeoffs - where do the two of us who work on Tasks chose to spend our time.

And for me, it's not just development time, it's user-support time and managing PRs, which themselves can take hours.

Do you think, from your experience, that this is a feasible solution? If yes, I'll be making a note to try this solution on my end once I have time (should be in December), and if it works I'll try to open a PR. But as I have close to no experience in JS, this is possibly too naïve of a solution.

I am not accepting many PRs these days - only from people who are already very familiar with Tasks code and my ways of working - just because otherwise they usually take too much time to shepherd through and maintain.

[claremacrae]

@dimiarbre For now I will leave this open, so that others may comment.

Because Tasks and Obsidian are so flexible, people use them in ways I had not considered - and sometimes in conflicting ways...

So based on this just one datapoint I would not yet change anything... and would encourage you to work within the confines of the existing Tasks capabilities.

But over time, I will collect more data about how people are using the Tasks plugin with nested tasks and list items, and we can decide what to do from there...

[dimiarbre]

I'll look into NON_TASKS, thanks for the pointer.
And I completely understand that you have better value for your time elsewhere than this issue, I'll leave it to your judgement.
Once again, thanks a lot for your time, and also for this incredible plugin!