You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A problem I've often had with GTG is that I work 100% of the time in "Workview" mode and never exit that workview because the performance iswas excruciatingly slow (issue #109). The problem with the workview means you have a "flat" view of only the actionable (sub)tasks; those that are not in the future and have no dependencies/children.
In life in general, the notion of a "project" is simply an outcome (or task) that has multiple actions (or subtasks) required to complete it. This makes intuitive sense, and is also officially confirmed in the GTD methodology here: https://gettingthingsdone.com/2017/05/managing-projects-with-gtd/
" Projects are defined as outcomes that will require more than one action step to complete and that you can mark off as finished in the next 12 months."
Now, I think/suspect that GTG historically has some semi-implemented-but-unused notion of "projects" somewhere in its codebase, because in ~/.local/share/gtg there is a file called "projects.xml" that is always pointing to the single instance of GTG's data. That's interesting, but I don't think we need to use it for what I'm proposing here in this ticket (it would rather be useful for higher-level notions like "sessions" (or profiles), which what requested in #215).
What I have in mind here is something simpler: automatic project detection and management, which we could nickname "micro projects". If you consider a project simply to be "a task that has multiple dependencies", then GTG (in some magical way that doesn't destroy performance) could simply detect (by asking liblarch?) which tasks have multiple children (whether on a single level, or multiple levels deep), and then either:
We display those "project" task names in the sidebar, under a "Projects" or "Micro-projects" or "Automatic projects" section, under the tags. And clicking (with double-click detection/prevention) one of those listed automatic "projects" would open the relevant task, allowing you to see its contents and its children (since the children are listed inside the contents anyway). Voilà!
Or we display them through a special view mode (a global "Projects" switch button in the headerbar?) instead of the sidebar. That mode would list those tasks and allow manipulating them normally. There are a couple of advantages to this approach:
You can filter with tags on top of it...
A contextual toolbar could allow batch folding/unfolding all the child tasks, and remember the state of that (so that someone can choose to always only see the global parent tasks instead of all the children, and unfold only when needed).
You can fit much more on the screen (both vertically and horizontally) than if you were to overload the tags sidebar with "projects"...
This would allow users to more easily keep track of projects without needing to "find" them manually.
The text was updated successfully, but these errors were encountered:
Lowering the difficulty because I think this is really not as complicated as it sounds; in the end, I think it would boil down to:
Adding a "Projects" tab between "Open" and "Actionable
When switching to that tab, asking liblarch to filter tasks to show tasks that have more than 3 children on the same level, whether done or not (let's just assume 3 is the magical number that defines a project; 1-2 would seem to not be enough), and to show both the parent and children, but only show the open (not done/dismissed) and actionable ones (not tasks with a startdate in the the future, or duedate set to "someday", etc)
Taking the selected sidebar tag/search into account
A problem I've often had with GTG is that I work 100% of the time in "Workview" mode and never exit that workview because the performance
iswas excruciatingly slow (issue #109). The problem with the workview means you have a "flat" view of only the actionable (sub)tasks; those that are not in the future and have no dependencies/children.In life in general, the notion of a "project" is simply an outcome (or task) that has multiple actions (or subtasks) required to complete it. This makes intuitive sense, and is also officially confirmed in the GTD methodology here: https://gettingthingsdone.com/2017/05/managing-projects-with-gtd/
Now, I think/suspect that GTG historically has some semi-implemented-but-unused notion of "projects" somewhere in its codebase, because in ~/.local/share/gtg there is a file called "projects.xml" that is always pointing to the single instance of GTG's data. That's interesting, but I don't think we need to use it for what I'm proposing here in this ticket (it would rather be useful for higher-level notions like "sessions" (or profiles), which what requested in #215).
What I have in mind here is something simpler: automatic project detection and management, which we could nickname "micro projects". If you consider a project simply to be "a task that has multiple dependencies", then GTG (in some magical way that doesn't destroy performance) could simply detect (by asking liblarch?) which tasks have multiple children (whether on a single level, or multiple levels deep), and then either:
This would allow users to more easily keep track of projects without needing to "find" them manually.
The text was updated successfully, but these errors were encountered: