finite void
Right now, if you want to make something a checkbox you have to create a #newtag, a property, and then assign a checkbox to that property.
Instead, a checkbox should be a built-in feature, accessible from the slash command.
There are many reasons why people might wish to use checkboxes rather than a status. It is good for shopping or packing lists, or for sub-tasks, etc.
It would also look cleaner since there would be no need to display a tag next to each item.
crisp nebula
I have a property called 'checkbox’ that I use wherever there is a need to apply a generic checkbox to a tag or a node
finite void
I see. So you don't need to add the property to a #newtag to add it to a node. That does simplify it a little bit and remove the tag markers.
But I think this is a feature that would be popular enough among users that it would be even better to have it there by default and accessible by a slash command.
This approach still requires
/ add property
Define property
Define UI position
The first time you use it. Not very intuitive for new users. And accessing it later requires using the add property command and then selecting checkbox. Slash /checkbox would be as easy as /todo
odd flower
An alternative is to render [ ] as an open checkbox and [x] as a closed checkbox; this hasn't been properly implemented in logseq MD, but is common for many markdown applications
finite void
An alternative is to render `[ ]` as an open checkbox and `[x]` as a closed chec...
The DB version has built in checkbox properties already, it is just a matter of how to access them.
modern siren
In Tana we have Ctrl/Cmd + Enter to create a simple checkbox on any block/node while typing. Additionally, If you want to add it as Field/Property value you can also define it as we do now in Logseq DB.
odd flower
The DB version has built in checkbox properties already, it is just a matter of ...
The difference it that you sometimes just want a checkbox, which I thought this issue was about, but it might in fact be a separate issue. For example, if you have repeating checklists (groceries, procedures, ...), they might clutter queries and properties pages. There are quite many github issues and forum threads about people wanting checklist that are just checkboxes. But I agree that it might be a separate (and unrelated) issue
crisp nebula
The difference it that you sometimes _just want a checkbox_, which I thought thi...
For that, I use the checkbox property with type property on a tag called TiDo which is simply a checkbox tag. I will set a slash command to it later;
finite void
The difference it that you sometimes _just want a checkbox_, which I thought thi...
The problem is that in the MD version TODO is a task status. The checkbox property is a different thing, and won't show up unless you specifically query it. (It is not a status.) If you want to reuse them, that is a separate issue. There is no template support yet in the DB version, but I'm pretty sure there will be before they release it.
finite void
It turns out you can now type cmd+p and add a "simple checkbox" property without adding a tag. I did not know this! Listing this as solved.
crisp nebula
Be aware that there is a peculiar behavior with it when you bulk set properties using the type checkbox. You are forced to have them checked to apply the property to selected nodes.