I'm also interested. I made a similar question on this thread (the Second operation).
By the way, my script ConnectedCluster may be of your interest. It selects all the nodes connected with the selected node. So, assigning it to a hotkey, you don't need to open the connector and press "Go to", as you show in the video.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
excellent :) this is great. I hope I find the time to find a way to list those connectors in a list. Currently I play with scripts that put icons on the nodes to mark if they have incoming/outgoing connectors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The filter is designed to hide all items that don't meet the criteria. If you filter on selected nodes, then you are telling FP to hide all non selected nodes, so that includes the ancestors you want to show (which are not selected when you applied the filter). If you want to see them, you need to remove the filter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understood you, I think. If you apply a filter that hides some nodes, and then you later want to see those nodes, you need to remove the filter. It seemed in the video that you want to show those hidden nodes without removing the filter. That can't happen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well I want to keep the filtered nodes in view + add those ancestors. I mean, I could also follow a connector to make that node appear, so I was hoping I could also make ancestors appear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wait, maybe I did misunderstand. I think the problem here is that "ancestors" relates to nodes connected with edges, but not nodes connected with connectors. Connectors are best thought of as labels and do not imply any family relations. Does that explain the behavior that is confusing you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Both relation types are needed. An edge groups nodes that are similar. At least in my work. Connectors can related those nodes to anything. Even incoming/outgoing flows can have special meaning.
For my usecase connecteors are very very powerful. Their are the second half of Freeplanes heart :)
If you are interested in my usecase, check the video :)
The video in the first post shows an active "show ancestors" button, if I am not mistaken. Let me demonstrate again in this video. It starts with the "show ancestors" button being off.
Please submit a bug report including the map used in the video so that I can follow the steps given in the video to reproduce the issue on my computer.
Posting an issue in the discussion forum is not helpful enough.
Sharing a video without the map is not helpful enough.
Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Robert, it seems that you might not see why issues reported as videos are not sufficient for problem analysis. So let me try to explain it.
Videos leave many relevant details out and do not focus on other relevant details enough
You find some interesting edge cases where Freeplane does not behave as you expect it.
It does not mean that it never behaves as expected. It means that each and every detail might be relevant.
In order to check why Freeplane behaves as it does I need
- the map you use to demonstrate the problem,
- exact specification of the filters you use (by the way, you can save filters to file from the filter composer and share them),
- exact specification of all steps you perform like which node is selected, which user actions are taken, for example which mouse controls or menu item or hot keys are used,
- exact descriptions of what you expect, what you observe and which difference between the observations and the expectations you want me to investigate,
for example "after I activated filter condition wit options ... I expected so see nodes ... and ..., but only the first one was visible"
- sometimes your user specific settings might play a role.
Trying to guess all that stuff from the videos is a horror for me, even if you might see it in a different way.
Please respect my time and effort as well as time and effort of the community members. Submit proper bug reports because it makes tracking issues easier, provide written descriptions of your actions and try to be as detailed and specific as possible.
I hope my post was helpful for you to see that I am very willing to help and absolutely depending on the quality of user reports.
If writing bug reports in German instead of English is significantly easier for you, it is an option.
Regards,
Dimitry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To put it in german "Du rennst offene Türen ein" :) I develop since 12 years. I understand every word and your perspective.
.
.
You find some interesting edge cases where Freeplane does not behave as you expect it.
It does not mean that it never behaves as expected. It means that each and every detail might be relevant.
This thread was not about a bug. But from now on, I will treat each discussion as if it were a potential bug. And bugs need details of course. :) To me "Discussion" was more like "Help". And the help I got, was good :)
.
.
Trying to guess all that stuff from the videos is a horror for me, even if you might see it in a different way.
I understand. If you do not like videos in general let me know. Otherwise you will get all details that I can provide, because I will treat everything like a potential big, and therefpre provide utmost details.
.
.
exact specification of the filters you use (by the way, you can save filters to file from the filter composer and share them
Awesome. :)
Last edit: Robert STeiner 2021-10-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to be clear: it's not a bug. It's the expected behaviour, and I think it shouldn't be changed.
The behaviour is (I already described it here): when the user has a filter applied, if he, somehow, manages to select a node that is outside the filter, then this node (I will call it the Invited Node) also shows up, but without the descendants and ancestors (no matter what are the settings for the filter). After that, doing anything in the filter refreshes the filter, making the Invited Node disappear.
I think this is better than having the descendants and ancestors of the Invited Node showing up too, because it could create a problem of lots of undesired nodes appearing. I think it's better to give more flexibility for the user, by leaving this choice as independent of the choice for the descendants and ancestors on the original filter. And, as this is a very niche thing (yet), this is better left for scripts.
Now, I may be wrong, but I think that there is a simple script that solves some of the cases (like the one you showed in the video): select all the ancestors of the currently selected node. Notice that the trick is using selecting operation, and avoiding filtering operations, because it would refresh the filter and make the Invited Nodes disappear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the explanation, but if a user has a filter applied, shouldn't it be impossible for them to select a node outside the filter? Isn't that a bug or design error?
I understand that this behavior is useful for your current workflow, which I don't want to prevent, but the logic seems wrong, and it seems to me that FP should have users get around the filter with a script rather than by relying on a logical error in FP.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. I am thinking about a feature request . :) @dpolivaev , @euu
Here is a draft :) And it is only a draft, because I am still playing around and did not had time to think!!!!
Sceneario
"Ok... please show me were you at", asks my superior. This person is not used to mindmaps at all. And time is money. Now the user needs to filter down to relevant aspects of the map to avoid confusion. The information needed, are nodes connected through connectors. The map has a parent/child/matrix structure. The connectors fly through the whole map. This needs to look much more focused. So the user selects the starting branch and wants to go from there. Drilling through the connector works. But the connected node is not self explanatory. More details are needed. The user tries to expand to connected nodes.
Problem
"Invited nodes" cannot be expanded. The map needs to be shown in full. Many hunderts of nodes pop back into focus.
Workaround
Heavily using map overview. Allows fast navigation. But it is hard on the eye for users not familiar with the map.
Scripts. Only for experts.
Better filtering. This might be time consuming and not suitable for Adhoc reports.
Avoiding adhoc reports
Request
Drilling from one object to the next.
Drilling to the next level will show only those nodes on that level. The connected objects can be identified and be added to the filter one by one, if I am not mistaken
Last edit: Robert STeiner 2021-10-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Probably Freeplane could apply currently active "show ancestors" and "show descendants" filter flags to invited nodes. I would not add them to the filter, it means if you reapply filter or change the flags they would disappear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Feel free to make the request, but if the main use is for helping simplfy the display for when someone else is looking at your complicated Freeplane map on your computer as you walk them through parts of it, I would consider it extremely low priority. I cannot even estimate the rarity of such as scenario for the typical user.
Last edit: quickfold 2021-10-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Map to complicated
Hmmm I'd say it is not complicated at all. Classic related data objects. But I am very interested in alternative approaches, to achieve the same clarity.
Rare usage scenario
And I am kinda suprised. Freeplane is being advertised as a project management tool. Projects usually are split into many tasks, milestones, rules, risks...... etc. that are in relation. I see no other way, then relying on connectors. But I am interested in any other and clearer approach.
And those other people that use my map are the team members.
Maybe Freeplane is only for mimi projects? But I'd say it has functions to manage huge projects. :)
Last edit: Robert STeiner 2021-10-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks to @euu for excellent analysis and explanations.
I don't see any reasons to change this behavior because I think that people who use filters are smart enough to understand and accept some useful exceptions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
first of all I would like to ask you to always post your replies at the bottom of the thread because otherwise I can not easily see new points.
I am very excited about the use case video. This is just the best way to explain your needs in relation with you use cases.
If I got it right, you want to be able to see the ancestors and/or descendants of the connected nodes which you can open using the connector goto submenu when the corresponding filter options are enabled,. If it is what you need I am going to implement it. If it is not what you need, explain your needs, not try to suggest any solutions.
I hope I find the time to find a way to list those connectors in a list.
Do you already know the MapInsight addon? Unfortunately it's presenting some problems, but it can still be used. Maybe, it can teach interesting things about how to create scripts to use with connectors.
Currently I play with scripts that put icons on the nodes to mark if they have incoming/outgoing connectors.
Please, share this script.
Edo had an interesting idea to differentiate in and out. I think it's possible to do with a script, using setInclination.
If you are interested in my usecase, check the video :)
As you maps grows, you will probably find this trick useful to connect far away nodes.
Drilling from one object to the next.
Drilling to the next level will show only those nodes on that level.
So, you idea is to have buttons to navigate through the nodes excluded from the filter?
So, if the user sets the filter, and, after that, voluntarily makes an action of selecting a node outside the filter, I think this must be considered a voluntary choice to create an exception to the filter. If you are the owner of the party, you can let people in even if they don't comply to the dress code. Please, let FP be like a party instead of a bureaucratic department haha.
Feel free to make the request, but if the main use is for helping simplfy the display for when someone else is looking at your complicated Freeplane map on your computer as you walk them through parts of it, I would consider it extremely low priority. I cannot even estimate the rarity of such as scenario for the typical user.
Although I have personal interest in improvements of the usability of connectors, I also think it should be considered low priority.
Connectors are a feature with lots of potencial to be developed, and the latest trend of note taking apps with non hierarchical, bi directional linking, shows that there is a demand for that. But, I think it is still very small the number of people that search for FP looking for this. So, I think this should get less prioritization than the improvements aimed for users that seek for traditional mindmaps.
Dimitry
first of all I would like to ask you to always post your replies at the bottom of the thread because otherwise I can not easily see new points.
Maybe, this should be adopted as a general guideline in the forum? The reply system in this forum is indeed confusing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The map is filtered. And now I need to show the ancestors :) But how ? :)
I'm also interested. I made a similar question on this thread (the Second operation).
By the way, my script ConnectedCluster may be of your interest. It selects all the nodes connected with the selected node. So, assigning it to a hotkey, you don't need to open the connector and press "Go to", as you show in the video.
excellent :) this is great. I hope I find the time to find a way to list those connectors in a list. Currently I play with scripts that put icons on the nodes to mark if they have incoming/outgoing connectors.
The filter is designed to hide all items that don't meet the criteria. If you filter on selected nodes, then you are telling FP to hide all non selected nodes, so that includes the ancestors you want to show (which are not selected when you applied the filter). If you want to see them, you need to remove the filter.
Well... wrong wording from my side :). In the video
Now I want to show more nodes that were hidden. Nomatter how :)
and the nodes that I need, are those ancestors :)
I understood you, I think. If you apply a filter that hides some nodes, and then you later want to see those nodes, you need to remove the filter. It seemed in the video that you want to show those hidden nodes without removing the filter. That can't happen.
well I want to keep the filtered nodes in view + add those ancestors. I mean, I could also follow a connector to make that node appear, so I was hoping I could also make ancestors appear.
Wait, maybe I did misunderstand. I think the problem here is that "ancestors" relates to nodes connected with edges, but not nodes connected with connectors. Connectors are best thought of as labels and do not imply any family relations. Does that explain the behavior that is confusing you?
Both relation types are needed. An edge groups nodes that are similar. At least in my work. Connectors can related those nodes to anything. Even incoming/outgoing flows can have special meaning.
For my usecase connecteors are very very powerful. Their are the second half of Freeplanes heart :)
If you are interested in my usecase, check the video :)
Use Filter->Show ancestors,
also available in the toolbar
Using command search and typing "ancestors" would immediately give this hint
The video in the first post shows an active "show ancestors" button, if I am not mistaken. Let me demonstrate again in this video. It starts with the "show ancestors" button being off.
The screenshot in the first post hides that I was using the buttons...sry
Last edit: Robert STeiner 2021-10-02
Please submit a bug report including the map used in the video so that I can follow the steps given in the video to reproduce the issue on my computer.
Posting an issue in the discussion forum is not helpful enough.
Sharing a video without the map is not helpful enough.
Regards.
Robert, it seems that you might not see why issues reported as videos are not sufficient for problem analysis. So let me try to explain it.
Videos leave many relevant details out and do not focus on other relevant details enough
You find some interesting edge cases where Freeplane does not behave as you expect it.
It does not mean that it never behaves as expected. It means that each and every detail might be relevant.
In order to check why Freeplane behaves as it does I need
- the map you use to demonstrate the problem,
- exact specification of the filters you use (by the way, you can save filters to file from the filter composer and share them),
- exact specification of all steps you perform like which node is selected, which user actions are taken, for example which mouse controls or menu item or hot keys are used,
- exact descriptions of what you expect, what you observe and which difference between the observations and the expectations you want me to investigate,
for example "after I activated filter condition wit options ... I expected so see nodes ... and ..., but only the first one was visible"
- sometimes your user specific settings might play a role.
Trying to guess all that stuff from the videos is a horror for me, even if you might see it in a different way.
Please respect my time and effort as well as time and effort of the community members. Submit proper bug reports because it makes tracking issues easier, provide written descriptions of your actions and try to be as detailed and specific as possible.
I hope my post was helpful for you to see that I am very willing to help and absolutely depending on the quality of user reports.
If writing bug reports in German instead of English is significantly easier for you, it is an option.
Regards,
Dimitry
To put it in german "Du rennst offene Türen ein" :) I develop since 12 years. I understand every word and your perspective.
.
.
This thread was not about a bug. But from now on, I will treat each discussion as if it were a potential bug. And bugs need details of course. :) To me "Discussion" was more like "Help". And the help I got, was good :)
.
.
I understand. If you do not like videos in general let me know. Otherwise you will get all details that I can provide, because I will treat everything like a potential big, and therefpre provide utmost details.
.
.
Awesome. :)
Last edit: Robert STeiner 2021-10-05
Just to be clear: it's not a bug. It's the expected behaviour, and I think it shouldn't be changed.
The behaviour is (I already described it here): when the user has a filter applied, if he, somehow, manages to select a node that is outside the filter, then this node (I will call it the Invited Node) also shows up, but without the descendants and ancestors (no matter what are the settings for the filter). After that, doing anything in the filter refreshes the filter, making the Invited Node disappear.
I think this is better than having the descendants and ancestors of the Invited Node showing up too, because it could create a problem of lots of undesired nodes appearing. I think it's better to give more flexibility for the user, by leaving this choice as independent of the choice for the descendants and ancestors on the original filter. And, as this is a very niche thing (yet), this is better left for scripts.
Now, I may be wrong, but I think that there is a simple script that solves some of the cases (like the one you showed in the video): select all the ancestors of the currently selected node. Notice that the trick is using selecting operation, and avoiding filtering operations, because it would refresh the filter and make the Invited Nodes disappear.
Thanks for the explanation, but if a user has a filter applied, shouldn't it be impossible for them to select a node outside the filter? Isn't that a bug or design error?
I understand that this behavior is useful for your current workflow, which I don't want to prevent, but the logic seems wrong, and it seems to me that FP should have users get around the filter with a script rather than by relying on a logical error in FP.
I agree. I am thinking about a feature request . :) @dpolivaev , @euu
Here is a draft :) And it is only a draft, because I am still playing around and did not had time to think!!!!
Sceneario
"Ok... please show me were you at", asks my superior. This person is not used to mindmaps at all. And time is money. Now the user needs to filter down to relevant aspects of the map to avoid confusion. The information needed, are nodes connected through connectors. The map has a parent/child/matrix structure. The connectors fly through the whole map. This needs to look much more focused. So the user selects the starting branch and wants to go from there. Drilling through the connector works. But the connected node is not self explanatory. More details are needed. The user tries to expand to connected nodes.
Problem
"Invited nodes" cannot be expanded. The map needs to be shown in full. Many hunderts of nodes pop back into focus.
Workaround
Request
The connected objects can be identified and be added to the filter one by one, if I am not mistaken
Last edit: Robert STeiner 2021-10-05
Probably Freeplane could apply currently active "show ancestors" and "show descendants" filter flags to invited nodes. I would not add them to the filter, it means if you reapply filter or change the flags they would disappear.
Feel free to make the request, but if the main use is for helping simplfy the display for when someone else is looking at your complicated Freeplane map on your computer as you walk them through parts of it, I would consider it extremely low priority. I cannot even estimate the rarity of such as scenario for the typical user.
Last edit: quickfold 2021-10-08
Map to complicated
Hmmm I'd say it is not complicated at all. Classic related data objects. But I am very interested in alternative approaches, to achieve the same clarity.
Rare usage scenario
And I am kinda suprised. Freeplane is being advertised as a project management tool. Projects usually are split into many tasks, milestones, rules, risks...... etc. that are in relation. I see no other way, then relying on connectors. But I am interested in any other and clearer approach.
And those other people that use my map are the team members.
Maybe Freeplane is only for mimi projects? But I'd say it has functions to manage huge projects. :)
Last edit: Robert STeiner 2021-10-09
Many thanks to @euu for excellent analysis and explanations.
I don't see any reasons to change this behavior because I think that people who use filters are smart enough to understand and accept some useful exceptions.
Hello folks,
first of all I would like to ask you to always post your replies at the bottom of the thread because otherwise I can not easily see new points.
I am very excited about the use case video. This is just the best way to explain your needs in relation with you use cases.
If I got it right, you want to be able to see the ancestors and/or descendants of the connected nodes which you can open using the connector goto submenu when the corresponding filter options are enabled,. If it is what you need I am going to implement it. If it is not what you need, explain your needs, not try to suggest any solutions.
Regards,
Dimitry
@sourceesoul
Last edit: Dimitry Polivaev 2021-10-06
Robert
Do you already know the MapInsight addon? Unfortunately it's presenting some problems, but it can still be used. Maybe, it can teach interesting things about how to create scripts to use with connectors.
Please, share this script.
Edo had an interesting idea to differentiate in and out. I think it's possible to do with a script, using
setInclination.As you maps grows, you will probably find this trick useful to connect far away nodes.
So, you idea is to have buttons to navigate through the nodes excluded from the filter?
quickfold
First, let's remember the wise words of Dimitry: Freeplane is not about mathematical and logical perfection.
So, if the user sets the filter, and, after that, voluntarily makes an action of selecting a node outside the filter, I think this must be considered a voluntary choice to create an exception to the filter. If you are the owner of the party, you can let people in even if they don't comply to the dress code. Please, let FP be like a party instead of a bureaucratic department haha.
Although I have personal interest in improvements of the usability of connectors, I also think it should be considered low priority.
Connectors are a feature with lots of potencial to be developed, and the latest trend of note taking apps with non hierarchical, bi directional linking, shows that there is a demand for that. But, I think it is still very small the number of people that search for FP looking for this. So, I think this should get less prioritization than the improvements aimed for users that seek for traditional mindmaps.
Dimitry
Maybe, this should be adopted as a general guideline in the forum? The reply system in this forum is indeed confusing.