If the used property is parent::, then the macro should be {{pagetree-from parent}} (this is under deprecation, but it is valid at the time of this writing).
I clarified my text above slightly: the narrow screenshot with children is of the parent page — you probably realized that, but I just want to make sure.
I changed the macro to {{pagetree-from parent}} but I still don’t get anything.
This is what I have in the config.edn:
;; added by PB from https://discuss.logseq.com/t/generate-explicit-hierarchy-out-of-properties/20635
:macros {:pagetree-from "[:div {:class pagetree, :data-treedirection from, :data-treeprop $1}]"
:pagetree-to "[:div {:class pagetree, :data-treedirection to, :data-treeprop $1}]"
}
- Each property is independent, and so are the respective trees.
- As humans we understand some properties to be complimentary to each other, but the system doesn’t.
- Your config.edn looks ok.
- Your example works for me, so there has to be some difference.
- If there is some text
Tree...:but no tree below, the issue is probably with the position of the properties. - If there is no output at all, should
Ctrl + Shift + ito check for any clues in the console.
- If there is some text
- Your other option is to create a new (empty) graph and start adding minimal info, checking the result of the macro as you go, until you find which change breaks it.
- Also make sure that:
- your app is up-to-date
- you have restarted Logseq after adding custom.js
- you have answered positively to the question about allowing custom.js to be executed
Success!! The problem was that I had copy/pasted only part of the custom.js. Copy/pasting the full code and restarting Logseq did the trick.
Note that it is actually {{pagetree-to children}} that works.
3 follow-up questions:
- in the tree there is also my Templates page, which has nothing to do with the book I am reading, Yahweh to Zion.
Looking at the templates page, there is this template:
Could be because of children:: that the Templates page is included in the book’s tree? If so, how could I avoid the Templates inclusion?
-
All children are sorted alphabetically, which is not the order of the book, even though on the parent page the children are shown in the order of the book. How can I get that sort order in the tree too?
-
Am I right when I say that for each book I read/project I am engaged in, I can put
{{pagetree-to children}}on the parent page to get a tree for each book/project?
The current code is light and generic, so none of the features that you ask has a positive answer at this time. But thank you for your feedback, this is what I am looking for. I will have to go through each one of the features and consider supporting it.
OK, clear. What there is, is already interesting. I love the fact that I can stay away from Namespaces — perhaps that is being narrow-minded, whatever — because I feel that if they are not used properly, they will sooner or later cause hassles/problems.
I’ll await the next stage, patiently 
BTW, I don’t know if you saw, but I advertised your system here.
1 Like
Big update, check the changelog.
Is it possible to use more than one property i.e. once the first hierarchy is evaluated, add more children by looking at the next property?
The algorithm can support endless combinations, but its input is currently limited by the syntax of macros. I don’t want to support a few scenarios and leave others out. If you have any idea for a generic-enough syntax, please share it. Meanwhile, you can get some results by editing the queries directly.
2 Likes
@alex Actually, could you provide something more specific as an example? I have come with some design and would like to ensure that it covers your case before implementing it.
@mentaloid sure, check this mockup for the query builder:
So something like {{pagetree from, nationality, author}} to create that hierarchy.
In my opinion this should be a feature of queries but I was curious if it was possible here too.
1 Like
I wish somebody could make a video about how to utilize it for some complex hierarchy topics.
I looked at the mockup:
- There you propose a single filter-sort-group query, which:
- is a bottom-up approach (hierarchy-wise)
- has no surprises (thus no discoveries either)
- operates like this:
- extracts some items (there books)
- imposes some structure on them, which is:
- regular
- in position: properties have fixed layers
- top nationality, bottom authorship, birthday on authors only
- in participation: e.g. a nation without books doesn’t appear
- in position: properties have fixed layers
- limited
- in size: the exact number of layers is predefined
- in info: the reader should already know what each layer represents
- regular
- This is not a genuine tree.
- unless if we abstract nationality and authorship to e.g. origin
- but then more results may appear and of less rigid structure
- unless if we abstract nationality and authorship to e.g. origin
- In contrast, a genuine tree:
- is a top-down approach (hierarchy-wise)
- operates like this:
- begins from some root
- spreads out in irregular forms
In my approach I implement a generalized graph traversal (like you said on this occasion), fed on every step by multiple predefined parameterized queries, operating on a level above them, to provide an unlimited partial structure of the graph itself, potentially discovering emerged relationships (e.g. “items authored after the birth of nationalities”, which may be books, but not strictly). Therefore, this is more than a tree, it is a cascade. It should still be possible to cover your scenario, but should:
- define some queries that are more targeted, in order to avoid unwanted results
- implement some syntax that needs parsing, e.g.:
{{pagecascade top strict-from nationality ; flat strict-from nationality ; flat strict-from author }}
I’m looking into it.
2 Likes
If you share some complex hierarchy topic, I may prepare some guide.
I don’t have particular topic in mind but I struggle to create some hierarchy of information, todos, ideas. Todo’s are connected to many ideas, ideas are connected to many todo’s.
For me complex hierarchy issue is when I try to manage my todo’s. I have different areas of interest like cooking, home, work, productivity, learning English, reading books, etc. I noticed that traditional tree of documents is not enough to create hierarchy, but tags are also not enough. I created #todo and as a subpage #todo/now #todo/next. But I also want to have #work/todo #productivity/todo pages. So, #todo/next page and #work/todo are different and separate pages. And another layer of information is differentiation between ideas and physical things. Increasing productivity is an idea, connected to self-improvement. Should I have another page: self-improvement? While learn how to use Logseq is connected to idea: productivity, and todo. It is and activity.
Good solution for me would be to have ability to see different trees based on properties, so that the same page could have different places in different trees: ideas tree, activities tree, physical objects tree (book about productivity is a physical object to buy), etc. the same page: “now” could appear as todo/now and productivity/now depending on what tree I display. And productivity page could be at different levels of hierarchy depending on tree displayed:
/ideas/self-improvement/productivity/software/logseq
todo/now/productivity
productivity/now
physical_objects/books/room2/cupboard3/productivity/author/title
physical_objects/room2/books/cupboard3/productivity/author/title
This way naming pages like this: productivity/now would be not necessary because properties would manage hierarchy.
I’d like to be able to switch easily between different tree views to have easy access to them, for example from panel icon.
It would be like virtual trees not physical pages trees.
I visualize my information rather like multidimensional connections not like a tree but this would be to difficult to achieve as a way of navigation in a program.
https://images.wallpapersden.com/image/download/molecules-atoms-chemistry_aGhmapSZmpqtpaSklGhtaWWtZ2ZrZQ.jpg
The best solution would be to be able to create hierarchies dynamically by drag and drop to some virtual hierarchy space.
Actually we should stop call it hierarchy (unless someone wants to treat it like that) and call it “connections views”.
Without a particular example, it is difficult to give particular advice.
This is an issue beyond this thread. Consider opening a separate one.
It would really help to put some order in the terminology itself:
- TODOs and ideas are information themselves.
- TODOs may have sub-TODOs, but that’s all about their hierarchy (see lower).
- There are two types of ideas:
- Specific ideas that you come with: These are like TODOs.
- Abstract ideas that pre-exist: These are the best material for multiple hierarchies.
Unless you mean the same connection inverted, only one direction should be valid.
Libraries (e.g. of books) know that very well. Fixed hierarchies remain useful, but they are very limited. The solution is graphs.
This won’t work well, because now and next change dynamically.
These should not be pages, but queries that filter your TODOs.
Now you are on topic, as far as this thread is concerned.
I get “Access denied” when trying to open that link.
This is again beyond this thread.
Overall, consider this approach:
- Think about the possible virtual trees that you would like to generate.
- For each one of them, find a property that describes the relationship among its nodes (e.g. type, category, container, subtopics, sections, etc.)
- TODOs are not nodes, but leaves. A TODO:
- may appear almost anywhere in your pages
- doesn’t have pages as children
- TODOs are not nodes, but leaves. A TODO:
- Use those properties consistently while creating your pages.
- Use one macro for each tree, built around its defining property.
If you decide to try that approach, we may use it as a point of reference.
No. Queries results can’t be sorted manually. I want to have todo pages because I don’t use to do option. I know that something is todo when I have it on todo page and I use references from text to todo page. When there is a reference on todo page it means I must do something about it.
I added direct link to jpg.
Use one macro for each tree, built around its defining property.
I am new to Logseq and I wish there was a video about it, about creating macros. I will customize it.
If possible, please use your own properties and show how to write and run macros to display trees. And how to create an easy access to them. I don’t have so many data in Logseq yet. It will be easier for me to use properties in a meaningful way if I know what can be utilized for.
I found only one video about properties
How to use properties and templates in Logseq by OneStutteringMind, but it doesn’t cover the topic in depth.
Currently, I can only clear up how to use the single macro for this thread:
- A macro is defined only once, by providing its name and output. For the trees, you only need to copy the following line and paste it inside the configuration file
config.edn(found in the first page of Logseq’s Settings), inside sectionmacros{}.
:pagetree "<div class='kit pagetree' data-kit='pagetree' data-node-prep='$1' data-node-prop='$2' data-leaf-prep='$3' data-leaf-prop='$4'>pagetree</div>"
- A defined macro is called as many times as you need, by opening double curly braces in a note, and writing inside the name of the macro (here
pagetree) followed by the desired parameters (called arguments), like this:
{{pagetree arg1, arg2, ... }}
Make sure each time to replace the part arg1, arg2, ... with a comma-separated series of the actual arguments (i.e. the desired tree’s characteristic property, preceded by its type), like in the examples provided in the OP:
{{pagetree to, children}}
{{pagetree from, broader, is, refs}}
2 Likes
Wow, thank you for your valuable work. I have to try this out!
Hi, thank you for sharing this neat trick.
From the example below (taken from one of the examples), I would sometimes only want to show the pagetree where parent:: [[man1]], so that the tree would look like the following:
boy1
girl2
Would this be doable with the current code?
boy1.md
parent:: [[man1]]
boy2.md
parent:: [[man2]]
girl1.md
parent:: [[man2]]
girl2.md
parent:: [[man1]]
grandmother1.md
children:: [[man1]], [[woman1]]
grandmother2.md
children:: [[man2]], [[woman2]]
man1.md
parent:: [[grandfather1]]
man2.md
parent:: [[grandfather2]]
woman1.md
parent:: [[grandfather1]]
children:: [[boy2]], [[girl1]]
woman2.md
parent:: [[grandfather2]]
children:: [[boy1]], [[girl2]]
EDIT: The motivation for this question is I would like to keep the parent and child property all throughout my graph for linking pages.